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

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

Hi Mike,

> 
> 
> On 13/04/2012 13:36, Rushforth, Peter wrote:
> >
> >
> > I am interested in RESTful applications, and in thinking about the 
> > space, I have come to think that XML, while wonderful for creating 
> > your own domain specific vocabulary, also suffers from that very 
> > strength:  too many re-inventions of the same thing 
> (because its so easy to reinvent) leads to no 
> standardization/interoperability at all.
> So why reinvent XLink?
> 
> I've always had the view that data models generally consist 
> of objects (elements), attributes, and relationships, and if 
> XML allows you to dream up your own names for your elements 
> and attributes then it should also allow you to use your own 
> name for your relationships. 

One of the ways that XML allows (forces?) us to model a relationship is with 
enclosing elements:

<factory><name>Willy Wonka's Chocolate Factory</name><location>England</location></factory>


> Why should we use the same name 
> for the relationship between a product and its manufacturer 
> as we use for the relationship between a factory and its 
> geographical location?

I'm not suggesting that.  I'm suggesting @xml:rel as a way of capturing
the name of the relationships:

<factory xml:href"http://example.com/willy-wonkas-chocolate-factory/location"; xml:rel="location" xml:type="application/xml">
<name>Willy Wonka's Chocolate Factory</name>
<products>
<product xml:href=""http://example.com/willy-wonkas-products/wonka-bar"; xml:rel="describedby" xml:type="application/xml"><name>Wonka Bar</name>
</products>
</factory

Note that the semantics of "@xml:type" are different from those of xlink:type.

But I don't think you meant that, I think you meant xlink made a mistake, 
don't push xml to do the same thing.

> 
> I think that's why XLink failed, and I don't see any 
> difference in your proposal.

I agree it's a little similar.  But I'm suggesting an 80/20 rule-based tweak to add
hypertext compatible with REST.  

1) no namespace declaration is required.
2) semantics of xml:href, xml:rel and xml:type are defined by external rfcs that work on the web.
3) it's 'inherited' by all of xml, I'm hoping in a backwards-compatible way. I'd like to hear 
what the incompatibilities might be.  I tried a stylesheet on an XML document using these attributes
and they seem to be copied by xsl:copy-of without complaint.  Where else should I look?

> 
> Now, data typing is another matter: it would be nice if 
> attributes containing dates, integers, or URIs were 
> recognizable as such without recourse to a schema. But 
> forcing all URIs to be called xlink:href is as crazy as 
> forcing all dates to be called date.

xml:lang ?  The value of this is in its static name.  Doesn't prevent you
from creating any amount of language-semantics-specific markup in your documents, using
your own nomenclature.

Although I guess that's where xlink ran into trouble, if I interpret David Carlisle's later
email: 

<snip>
Consider xhtml that came under a lot of pressure when it was being designed to use xlink links (which were being designed at the same time) but it would have meant that you could not use <img src="foo"/> it would have to be <img xlink:href="foo" xlinl:type="simple" xlink:show="embed"/> You could not go <a href="bar.html">.. had to go <a xlink:href="bar.html" type="simple">...
</snip>

Seems to me to be forcing the "xml" way of doing things on something that was already workable.
I would not do that, my opinion is there's nothing forcing people to use xml:lang etc, but
when they are built into tools, like xslt and xpath, it does improve the developer experience.

Cheers,
Peter