Altova Mailing List Archives

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

From: Liam R E Quin <liam@--.--->
To: "Rushforth, Peter" <Peter.Rushforth@-----------.--.-->
Date: 4/21/2012 7:47:00 AM
On Fri, 2012-04-20 at 13:06 +0000, Rushforth, Peter wrote:
> My understanding of content negotiation is that the client sends an Accept
> header with a list of weighted preferences.


>   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.

> > 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.

> 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.


> > 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.

> > Hmm, I have not seen atom:link in use outside atom, I'd be 
> > interested to learn more about that and see examples.

The kml one is interesting, are you suggesting Google Earth uses atom in
some way?

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

> > Sorry for a long reply.
> NP.  Just want to make sure you realize I am not a crank caller.

No, it's OK, and I am interested and listening. Heck, if you're in
Ottawa I'm only 3½ hours' drive away :-)


Liam Quin - XML Activity Lead, W3C,
Pictures from old books:


XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address:
Or unsubscribe: xml-dev-unsubscribe@l...
subscribe: xml-dev-subscribe@l...
List archive:
List Guidelines:


These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.