OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: Real XML Site

[ Lists Home | Date Index | Thread Index ]
  • From: Paul Tchistopolskii <paul@qub.com>
  • To: "XML-Dev (E-mail)" <xml-dev@lists.xml.org>
  • Date: Wed, 13 Dec 2000 19:38:49 -0800


From: Eric van der Vlist 

> Tim Bray wrote:

> > Probably Dynabase, just like infoworld.com; it's the only product
> > I know of that serves HTML pages with the .xml extension (a practice
> > that seems more than a little weird to me). -T
> 
> Most of the XSLT servlets are doing so, at least in their basic
> configurations.
> 
> As Didier mentioned, the source document is really a XML document that
> is transformed on the server.

... And I agree with Tim. This *is* weird. ( And I was stupid. 
I'm blaming myself here, because Hiawatha also returns html result 
of server-side XSLT rendering when receving request for some.xml ).
 
But there is some twist with Hiawatha. 

Because most of links from outher space to my site are .html ( and because 
I'm trying to keep the legacy of my URLs so that people will not get 404 
from my site ever ), Hiawatha also got a URL rewriting layer.

I think in 'ideal world' URL rewriting should be a *practice* not 
the exception, so that just looking at some URI we can see 
what will be a mime-type of the response.... for example ... 
Well ... and maybe we can also get some other information 
from the URI ? I mean, for example, what protocol will 
be *acepted* by that URI ? Oh, no....

Let's face it.

URI is very important chunk of the information. I wish some day 
we'l get some *recommendations* for *possible* patterns to use 
in URIs. 

I'm talking about the soft *recommendations*. I'l be strongly 
against W3C *restricting* URI string in any way. 

But I feel some need in recommendations. For example, 
when I was hacking XT to understand  document( "/! sql request here" ), 
I got a feeling that the freedom with URIs is not actually good. For example, 
the "/! " signature was kind of unavoidable, because of some Java 
restrictions. I mean that some recommentations for 'custom' URIs 
will be more forgiving to the legacy code than others. 

Also I think that it was not so important when every server 
were HTTP and every content was HTML. 

The era of HTTP / HTML-only Web is gone. I think we should start thinking 
in terms of many protocols and many mime-types. 

> It can be seen as weird, but not more that serving HTML documents with
> .php or .asp extensions since in this case it's also the result and not
> the source that is sent to the browser.

I think this practice exists only because there is no simple and clear 
URL-rewriting layers in most of the HTTP servers I've seen.

I think situation is somehow similiar to HTML. What you ( and many 
others, including myself ) are saying : "URI is confuizing? Big deal - 
it works" , is in fact close to saying : "HTML is not well-formed?
Big deal - it works".

Rgds.Paul.

PS. Oh, gosh. It comes to the basics again. "What is URI" ? 
"Why namespaces are using URIs - is it really reasonable?"






 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS