[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: RE: Why does my browser treat the XML Schema documentat a

  • 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

Re:  RE: Why does my browser treat the XML Schema documentat a
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]


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.