RE: [xml-dev] RE: Why does my browser treat the XML Schema documentat a

["Rushforth, Peter" <Peter.Rushforth@NRCan-RNCan.gc.ca>]

Hi David,

> On 10/09/2012 13:49, Rushforth, Peter wrote:
> > But in general, the client needs a hint regarding what to 
> negotiate for, and this
> > is what @rel and @type are for.
> 
> In the context of the web in general and this thread in particular. 
> that's wildly misleading. The overwhelming majority of links 
> on the web 
> have no such hints.
> 
> The original question refered to referencing teh schema 
> directly in the 
> browser location bar (where there is no markup) or 
> equivalently from a 
> link such as in the archives of this list where it will be an html a 
> link, again with no type information.

The original question was:

"Why does my browser treat the XML Schema document at that URL as an XML document?"

The heart of the question is: why doesn't my browser know that an .xsd file on my system
is an XML document yet when accessing an .xsd resource on the web, it appears to?

(Part of) the answer is that file extensions mean something to operating systems 
and nothing on the web.  That question was well answered by others.

However, the larger question is about how the web browser "knows" a resource is of
a certain type.  The means to request and receive the type of a web message is 
media types, and content negotiation, and yes, links.  Almost all links occur in
context, and are often negotiated based on that context.

And they do come with hints for content negotiation, although not always explicit,
and in the case of XML, usually not @href,@rel etc.

For example, @xsi:schemaLocation tells the _client_ that it should negotiate with a
preference for application/xml.

<foo xsi:schemaLocation="http://www.w3.org/2001/xml.xsd";>

and   

<foo href="http://www.w3.org/2001/xml.xsd"; type="application/xml" rel="schema">

seem equivalent to me, in that they both provide hints to the client. The latter
construction is more explicit, IMHO.



> 
> >  However, most 'properly configured web servers' would
> > provide an html representation and an xml representation, 
> and not use the xml-stylesheet trick.
> 
> 
> That is a rather judgemental comment. You appear to be saying the w3c 
> web server is not properly configured?

I apologize, I didn't pick the words or the example, nor think twice about using
them.  There are always operational reasons for configuring a server one way 
or another.  Web architecture is very flexible and does not forbid you doing it your way.

What I wanted to point out though, is that the resource being described (the namespace)
is represented by another resource having a different format, and that this
situation can be handled naturally in web architecture by serving the resource 
in different formats.

> 
> In fact while serving different representations at the same URI and 
> relying on content negotiation to send the right one has some uses in 
> restricted circumstances, it also has many drawbacks, notably 
> it makes 
> it very hard to talk about the URL (or to be sure what you 
> will get if 
> you request it). 

You can be sure if you request it with Accept: application/foo that, if it is available
in that format, you will receive it in that format.  

Obviously, servers have a preferred format in the absence of a requested format,
and browsers are somewhat hard-coded to prefer html, so you are right in the restricted 
circumstance of a browser, that it is sometimes useful for a 'view-source' type of experience.  
When you access an XML (application/xml) representation with a browser (which
doesn't have an xml-stylesheet PI), you get the default stylesheet rendering of that resource, 
as you described to me in another thread. 

But, XML is designed to be consumed by programs apart from browsers.  

> Also I don't know why you should call using 
> one of the 
> more consistently implemented w3c recommendations "a hack".

Well, I didn't, I called it sleight of hand, a neat trick.  But it is somewhat
limited, as the XML simply ends up as HTML, and you have to use XSLT 1.0.  And because of
the workarounds required to achieve desired results on different browsers (where this
thread ended up), I suggest a more mainstream way to achieve HTML representation of an 'XML'
resource is to serve it as HTML in the first place, using content negotiation, 
so you are not locked in to older techniques like this.

Cheers,
Peter