RE: [xml-dev] xml:href, xml:rel and xml:type

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

Hi Liam,

Me again :-).

> 
> >   If the advertisement
> > in the @xml:type does not match one of the client's 
> capabilities, no 
> > request to that xml:href URI will ever be made, saving the network 
> > bandwidth, and the server the effort of replying to a 
> request it cannot honour.
> 
> But you don't know in advance. The xml:type is just going to 
> be wrong most of the time.

It's advisory.  If it's important, it's not going to be wrong.  
Browsers seem to only care about the @rel="stylesheet" bit, and don't
parse @type.  So you can leave it out in that case.  But if that 
bit of metadata was used to disambiguate xslt from css requests, for example,
it would be more important to the author to get and keep right.  That's
what it's for: to help drive client state. 

I will admit that there's not much literature available from google on
the use of this attribute.  I will do a bit more digging.


> 
> > > I'm personally interested in typed links, where the types are 
> > > rhetorical in nature - e.g. "supports", "disagrees", or express 
> > > other relationships.
> > 
> > This is the relationship of the referenced resource to the current 
> > client state, and is supposed to be stored in @xml:rel, which is 
> > similar to atom:link@rel or html:link@rel.  *I* think you 
> need _both_ 
> > @xml:rel and @xml:type to qualify as a typed link.
> We'll have to agree to differ.

Seems that we agree on 2/3 attributes so far ;-).  I will keep working
on that third one...

> 
> [...]
> > However, without the advertisement found in @xml:type, no 
> such crawler 
> > is practical, because you would have to crawl _everything_ to 
> > determine what is/is not a document you can analyze.
> 
> You have to do that anyway if you want to be complete.
> 
> Suppose you are interested in SVG images. So you don't crawl 
> to an XML DocBook document. But the illustrations in that 
> DocBook document were in SVG. So you lose.
> 
> [...]
> > > The client can *always* send an Accept header saying they 
> prefer PNG 
> > > to SVG. (content negotiation is of course different from "HTTP 
> > > OPTIONS")
> > 
> > Yes.  But again, the advertisement in the metadata is a hint to the 
> > client of what to enter into negotiation with.
> 
> When you write the document you don't know what formats the 
> client will prefer, unless you write for only one piece of software.
> 
> So the document is the wrong place for it.

OK, one can produce an image index by crawling html pages and
finding linked images; text/html is a rich source of links to image/*.
image/svg is a usually a separate media type from text/html,
but it is encompassed and overshadowed by text/html when it is produced in-line.

If you crawled an xml-based media type, you would likely need the xml:type
hint to help you out, in particular where the @xml:rel was not a differentiator,
see the discussion of <link rel="stylesheet".../> above.

> 
> 
> [...]
> 
> > > Is the problem the namespace declaration? There was talk 
> about that 
> > > a year or two ago on xml-dev, about reforming namespaces, but 
> > > there's too much XML 1.0 inertia to make it easy.
> > 
> > Yes, it is one of the problems.  But I don't think it is the 
> > declaration so much as the fact that users have to declare it and 
> > clients have to verify that it matches.  The xml:href, xml:rel and 
> > xml:type _strings_ can be found without understanding namespaces, I 
> > think.  Maybe I'm trying to skirt around the issue of 
> namespaces, but 
> > I think using the implicit xml namespace is appropriate because web 
> > hyperlinking is a top priority use case for xml.
> 
> I think that's very subjective - I'd rather add xml:include 
> and xsi:type myself. But that was why I wrote the 
> "unobtrusive namespace" stuff, so you could have (in effect) 
> a predeclared list of namespces. It didn't fly, though.

OK, I reflected on this a bit, and I just read the "Automatic Namespaces" paper
you gave at Balissage 2009 (sorry!).

First, the problem with having links in some arbitrary namespace is that they can be
syntactically re-assigned ie. xlink: could just as easily read linkinglanguage:,
or an empty string.  So links can't be easily recognized.  Since xml: can not be reassigned,
xml:href always means xml:href, and xml: always has to be present.  So links 
will always be recognised.

Automatic namespaces don't change the fact that the href can be in any
namespace as defined by the profile in the xml:ns reference document.

BTW I think the concept of automatic namespaces is compatible with the concept
of a 'profile' link relation, which is being promoted by Erik Wilde over
on rest-discuss.
http://dret.typepad.com/dretblog/2012/03/resource-profiles.html

While Erik's proposal is for a link relation 'profile' which has an associated URI
which is abstract (ie. not necessarily dereferenceable), your automatic namespaces xml:ns
reference actually associates an xml file describing the profile of an xml file
encoded according to a similar concept.

xml:ns="http://example.org/myautons.xml";

would map nicely to

<link xml:rel="profile" xml:href="http://example.org/myautons"; xml:type="application/xml;type=autonamespace"/>
<link xml:rel="profile" xml:href="http://example.org/myautons"; xml:type="application/json;type=autonamespace"/>

I think the notion of a profile, and the notion of automatic namespaces both need to
consider the MIME media type with a bit more priority.  In other words,
the concept of a profile and that of automatic namespaces are
working in the same space as the role of MIME media type.  The MIME media
type needs to be known to an application in order to process files of that
media type.  Just like an application must be built to process UTF-8 characters
instead of US-ASCII,  an application must be written to process text/html
with in-line svg. Whether there are namespace prefixes or not is a programming
detail, and one which I as an xslt programmer have been happy to live with.
HTML/js programmers, not so much!  But the point remains that it is the
media type that is the final descriptor of the expected content, regardless
of the namespaces involved.  And having a link to a profile from within the
target document is too late a la either of the above equivalent examples - 
it needs to be advertised and negotiated prior to pulling in the document, 
otherwise you get wasted bandwidth etc.  See REST.


> 
> 
> > > Hmm, I have not seen atom:link in use outside atom, I'd be 
> > > interested to learn more about that and see examples.
> > 
> > 
> https://developers.google.com/kml/documentation/kmlreference#atomlink
> > http://www.rssboard.org/rss-profile#namespace-elements-atom-link
> 
> The kml one is interesting, are you suggesting Google Earth 
> uses atom in some way?

Not very well, IMHO.  For example, it does not use atom:link@rel="next",
which would be a nice feature for paging data RESTfully.

> 
> The rssboard one is just atom and rss, which is where atom started ;)

I guess it came full circle, adding standardized links to RSS.  The point
is there is a great need for that standardization.


> you're in Ottawa I'm only 3½ hours' drive away :-)

Well if you're getting the same snow we're getting today, you have my sympathy!

Cheers,
Peter