[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
Re: [xml-dev] RE: Why does my browser treat the XML Schema documentat a URL as an XML document?
- From: David Carlisle <davidc@nag.co.uk>
- To: "Rushforth, Peter" <Peter.Rushforth@NRCan-RNCan.gc.ca>
- Date: Tue, 11 Sep 2012 14:48:00 +0100
On 11/09/2012 14:09, Rushforth, Peter wrote:
> 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">
schemalocation takes pairs of URI (namespace and location), but I know
what you mean.
>
> and
>
> <foo href="http://www.w3.org/2001/xml.xsd" type="application/xml"
> rel="schema">
>
but the point is that this isn't foo in some arbitrary namespace, it is
<a> in html and that doesn't give any way of specifying the request
type. You would seem to prefer that links are explicitly typed but on
the web they are not in almost all cases. Both <a href.. and <img src=
leave it up to the browser/server to figure out the mime type to be used
they do not use document markup to control that.
> seem equivalent to me, in that they both provide hints to the client.
> The latter construction is more explicit, IMHO.
Since the last is an example of an unspecified markup language it is
equivalent to whatever you say it is equivalent to.
>
>
>
>>
>>> 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)
The resource isn't the namespace but a XSD schema. There could be
(although in this case probably are not) many schema associated with the
same namespace. There are multiple versions of xhtml for example
1.0 strict, 1.0 transitional, ... xhtml5, ... so multiple schema each
served from different URI but all for the namespace
http://www.w3.org/1999/xhtml
> 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 this case the namespace and a schema are clearly two different things
so having different URI is a good thing. But even when they are more
plausibly different representations of the same resource viewing them as
distinct resources at different URI has many advantages.
Probably you never care whether you get png or gif image so putting both
at the same URI and allowing the browser to take whichever works well,
but if you put (say) a json and xml and text representation at the same
URI and leave it to content negotiation to pick whichever, then you
can't for example have a simple web page linking to all three and let
the (human) reader decide which to follow. More or less _everything_ is
more complicated if you do that.
>
>>
>> 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.
Yes quite, so an atom reader can just get atom for example but as noted
above you can't make a simple web page that says
get the html version from <a href=""> here </a> and the json version
from <a href=""> here </a>
unless you put the two versions at different URI.
Note that while html's a element does have a type attribute it may not
be used for the purpose of making two distinct links in this case. It
essentially has no effect whatsoever.
http://www.w3.org/TR/html5/links.html#attr-hyperlink-type
says
> User agents must not consider the type attribute authoritative — upon
> fetching the resource, user agents must not use metadata included in
> the link to the resource to determine its type
In other words if you put an xml and html version of the schema at the
same URI it is virtually impossible to link to the schema from a web
page as the browser will always take the html version.
>
> 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.
Yes but this thread was specifically about browser behaviour and you
answer didn't address that at all since it referred to the use of rel
and type attributes which would not change the behaviour of links within
a browser.
>
>> 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.
true, sorry.
> But it is somewhat limited, as the XML simply ends up as HTML,
well not really: the point is that you get the original xml, the schema
document you can use. If the server just served an html representation
of it then if you needed the schema document you would have to make
another http request and go back and get it.
> 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.
But that suggestion is not relevant to the context of this thread, ie
browsers, as within a web page you have no way to link to the schema and
a html representation of the schema if they are served from the same URI.
>
> Cheers, Peter
>
>
David
________________________________________________________________________
The Numerical Algorithms Group Ltd is a company registered in England
and Wales with company number 1249803. The registered office is:
Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.
This e-mail has been scanned for all viruses by Star. The service is
powered by MessageLabs.
________________________________________________________________________
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]