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

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

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 ;-)

I'm personally interested in typed links, where the types are rhetorical
in nature - e.g. "supports", "disagrees", or express other
relationships.

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



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

> 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")


[...]

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

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

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

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.

[...]

> 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"... :-)

Web services are rapidly moving to JSON.

Sorry for a long reply.

Liam

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