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

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

Hi Liam, 

> On Tue, 2012-04-17 at 12:05 +0000, Rushforth, Peter wrote:
> [...]
> > Web crawlers, to take one example, can't crawl xml, because 
> there is 
> > no reliable static markup to identify links in all xml.
> 
> There's also no way to mark what's content, which elements 
> break phrases, how to make elements bold or italic, which 
> elements are titles, that Web crawlers need to generate 
> result snippets.

This is because its XML, and html crawlers don't speak an infinite
number of media types/vocabularies.  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.  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).


> >   The existence of xml:href solves that problem.
> > Unless they are Kreskin crawlers they won't know what to do 
> with the xml when they find it.
> > That is what @xml:type is there for.  While application/xml 
> does not 
> > tell you too much, there are sub sub media types, media type 
> > parameters etc to tell you how to process the 
> representation once you retrieve it.  Also, it does not have 
> to be xml :-).
> 
> 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.

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.  It's not authoritative, of course, because its metadata in a
representation, but it allows for potential efficiencies  eg not having
to send an OPTIONS to determine media type availability.

> Putting media types in static content is generally not a good 
> architecture. The remote Web server will send a media type as 
> an HTTP header and that is what should be used - it is 
> normative, authoritative. 
> This is why, in HTML, it's <a href="foo"> and not <a href="fo"
> type="text/html">
> 
> Indeed, different HTTP clients (browsers) might receive 
> different formats, depending on the Accept: HTTP headers they send.

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.

> 
> > 
> > Why is xml:lang needed for xml itself?  or xml:base for that matter?
> > Why is linking less important?
> 
> Where you start and stop is fairly arbitrary. We didn't do 
> xml:id in the first spec either.

Exactly.  Adding no-namespace-declaration hyperlinks is a big win, IMHO.
Take xml:base.  That attribute is in the same spirit as xml:href, I think,
except it describes *this* document, not *that* document.

> 
> Peter, the people you need to persuade here mostly fall into 
> two broad camps - (1) people happy with XML and namespaces 
> and who generally see little or no problem with XLink. XLink 
> already has the ability to describe the "state of the cilent" 
> as you call it, to specify link relationships (like the rel 
> attribute on "a" and "link" in HTML), and does not have the 
> Web-architecture-breakage of putting media types into links 
> ;-)... and 

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.  Nothing against xlink; use
it if it fits your needs.  The point is all of xml needs links
to other documents, and the barrier of xlink is too high.

(2) people who have no interest in using XML on 
> the Web today, and for whom the difference between xlink:href 
> and xml:href is like saying, buy a Jeep because the rear axle 
> leaf spring bushings are polyurethane whereas in a Toyota 
> they're aluminium.

> The biggest barrier to XML on the Web today is that when Aunt 
> Tillie tries it, and leaves quotes of her attribute values, 
> she gets a really confusing error message.
> 
> The next biggest is lack of architectural forms for search 
> crawlers and ad servers to use.
> 
> Without ads, and with strict syntax, we're not about to take 
> over the world.

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.

> We are limited in the ways we can change XML itself, although 
> we can change the layers above more easily.
It's the easy part that prevents interoperability on a grand 
scale.  Of course, XML is all about making certain things easy.
The other stuff, the really really really important stuff, should
come built in and fixed.

Cheers,
Peter