RE: xml:href, xml:rel and xml:type
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format