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

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

Liam,

> 
> On Thu, 2012-04-19 at 14:37 +0000, Rushforth, Peter wrote:
> > The point is, the media type advertisement that is present in 
> > @xml:type _tells_ the crawler, or any other client, if they will be 
> > able to understand what is at the other end of the @xml:href.
> 
> You can never assume that the result of fetching a resource 
> will be a particular representation format. You might 
> actually get anything back at all. For sure you might get 
> HTML 2 or HTML 4 as part of an HTTP 404 or 401 response, but 
> content negotiation means you might get image/jpeg instead.
> 
> Instead, it tells the client that the document author 
> _expected_ a particular type.
> 
> If we can agree that far maybe we can make progress on 
> understanding each other ;-)


@xml:type is embedded metadata, similar in concept the atom:link@type,
http://tools.ietf.org/html/rfc4287#section-4.2.7.3 and
html:link@type, and is less authoritative than message metadata in http,
as described here: http://www.w3.org/2001/tag/doc/mime-respect#media-type


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.

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

One of the interesting things about @xml:rel and @xml:type is that it constitutes
(part of) "media type design", along the lines of what Fielding talked about in
his famous rant:

"A REST API should spend almost all of its descriptive effort in defining the media type(s) used for representing resources and driving application state, or in defining extended relation names and/or hypertext-enabled mark-up for existing standard media types."
http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

The domain of design between @xml:rel and @xml:type is a very powerful one.
The art of XML document design is well understood by this crowd,
(ie. the other part of media type design).

I think there are some very important details here that could be improved
by @xml:rel, @xml:type and @xml:href, especially because the addition of
those attributes enable "hypertext-enabled mark-up for existing standard
media types"

In reference to Michael Kay's mention of normalization, I see
the factoring of meaning between the @xml:rel and @xml:type as a kind of 
"web normalization".  Put the stable meaning of resources in their (dynamic) context 
(say, an xml shoe :-)
into one or more tokens in the @xml:rel (eg. "other"), and the 
media type hierarchy into the @xml:type (eg. "application/xml;type=shoe)
Presto, semantic links.

> 
> >   One could write an ISO 19115:2003 crawler, for example, 
> and so long 
> > as the links were annotated with @xml:type, the crawler 
> could target 
> > that media type only, processing the elements in the way it 
> > understands them, doing whatever it needs to do to meet its goals 
> > (this might not be "search", in the google sense, for example).
> 
> Someone else would write a crawler that checked out all the 
> links and fond the 90% that you'd missed, e.g. when you go to 
> www.findmylover.com and you get an HTML page that asks for a 
> country, and then www.findmylover.com/?country=rohan returns 
> your geographical markup language.
> 
> It's dynamic, not static.

Again, the issue about authoritative metadata.

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.  Or else you are assuming that everything is
one or two media types, all of which you can process.  Clearly, that is
not the case with xml, beyond simple xml parsing.


> 
> 
> 
> > > Media type tells you what something is, not how to 
> process it. There 
> > > are lots of things you can do with an SVG image, for example, 
> > > besides simply rendering it.
> > 
> > Media type (@xml:type) tells you what the media type of the 
> advertised 
> > linked representation might be (not: _is_), so you know if 
> you should be able to process it.
> 
> When I wrote Media type I was referring to the label in the 
> returned HTTP header, which is authoritative.

Agreed.  But it is not the only place nor role for the media type metadata,
as described by the TAG reference above.

> 
> > An SVG image might be chosen over a png version so the client could 
> > edit the vectors, for example.  The media type advertisement allows 
> > clients to know if they can send an Accept header with a value 
> > supporting that use.
> 
> 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.

> 
> 
> [...]
> 
> > For sure, that is what the Accept header is for.  But the 
> html author 
> > uses the link to his own ends, and it sure isn't 
> constrained to html.
> > For xml, where everyone mints his own media type effectively, 
> > @xml:type is essential.
> 
> Maybe this is where I'm not following your argument.
> 
> Are you suggesting people would register individual 
> schemas/vocabularies with IANA themselves, or would use types like
>   application/x-mallard+xml ?

No, I think application/xml is top-level.  There does need to be
some way to continue to specify the document semantics, probably through
media type parameters (that seems to be the extensibility mechanism
that is provided).  If your media type gets important enough that
recognition as application/xml is not important, go ahead and register
application/x-mallard+xml.  IOW application/xml;type=mallard is
probably more appropriate for a domain specific vocabulary.  Clients
who understand type=mallard will quack like a duck, but browsers
and other xml-aware but mallard-unaware applications will just
display xml syntax coloring, or whatever their default behaviour might
be (because they'll ignore ;type=mallard, and request application/xml, 
if they follow the spec).


> 
> > Exactly.  Adding no-namespace-declaration hyperlinks is a 
> big win, IMHO.
> 
> 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.  

> 
> > xml:type isn't putting the media type into the link.  It's 
> advertising 
> > a representation format available from the URI. Very much link 
> > atom:link@type.  Why has atom:link grown beyond atom?  
> Because there 
> > is no equivalent thing in xml.
> 
> 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


> 
> Note that we (W3C) did reduce the barrier of XLink a little, 
> you only need one attribute now. And declaring an XLink 
> namespace seems no worse than declaring an atom one to me.

I agree that it is no worse, except for the complexity, not to mention
controversy (apparently, did not know of that before starting this
discussion) around xlink.  Again, having a specific domain standard
add linking to xml is not the right way to go - it needs to be
baked in.  And the namespace is also a slight barrier, per above comments.

> 
> [...]
> 
> > The biggest barrier to use of xml on the web is following 
> web service 
> > paradigms which don't use the web architecture to advantage.
> > And, not having hypertext there when you need it.
> 
> I wonder if we got 20 people in a room together we could get 
> agreement on "the biggest barrier"... :-)
Maybe not.  Not to worry.

> 
> Web services are rapidly moving to JSON.
Stop the bleeding!  Use REST+XML!

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


Cheers,
Peter