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

[Liam R E Quin <liam@w3.org>]

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.

Yes.

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

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

-- 
Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/