[
Lists Home |
Date Index |
Thread Index
]
> Lets take the XML Schema specification: you have some standard tags like "complexType, simpleType, complexContent"
As an option can we not take XML Schema and instead take something like, oh I don't know, maybe something like RelaxNG (for example, of course)? Would definitely make the analogy more plausible! :D
On Apr 1, 2005 7:58 PM, Razvan MIHAIU <mihaiu@mihaiu.name> wrote:
Michael Kay wrote:
What's wrong with XLINK ? At first sight it seems to be
quite powerful.
It's at the wrong place in the architecture. XML caught on because people
liked the idea of separating information content from presentation, and
XLink never recognized that. XML says you can use any names you like for
your objects and their properties, but XLink says you have to call your
relationships xlink:href.
XLINK is primarily about defining links between documents in a standard manner and not about defining relations (for example of type parent->child); only for extended links you can define relations between documents (I assume that you are speaking about the 'arcrole' attribute). If you wish to make 'linking' a standard you have to come up with some fixed element or attribute names. Please take into account that those attribute are in their own namespace so they should not cause any naming conflicts.
Honestly I do not understand your complain here: XLINK is a specification, so, like any standard it needs some fixed attribute or element name. The same goes for all the specifications. Lets take the XML Schema specification: you have some standard tags like "complexType, simpleType, complexContent" a.s.o. You could complain that XML Schema is useless because it forces you to use a certain set of tags.
In practice people are storing information in XML form, and using XSLT to
transform it into presentation formats like HTML and PDF (via XSL-FO). If
you do that, you can model your relationships any way you like, and give
them names that make sense. XLink just doesn't add value in that scenario.
XLINK *adds* a lot of value in that scenario. XLINK is about linking various types of documents in a powerful way. Extended links are much more powerful that the standard HTML linking mechanism. If you wish to transform your XML for presentation (for example in (X)HTML) you will just transform you XLINKS to standard (X)HTML anchors. You will loose a lot of power in this conversion. If, some other media has a more powerful linking mechanism then the conversion to that unnamed media will go much better.
I think that xlinks are welcomed in this scenario. Instead of having tens of ways of linking documents you will have just one. For this you could write one transformation for a certain format (lets say HTML) and it would be the end of story. For all the documents in the world using xlinks you could use just one transformation for a certain data format - e.g. (X)HTML. I do not see how that could be bad.
Again I see you mentioning the word "relationship" when referring to the XLINK specification. Perhaps by "relation" you mean "link". I underline that defining relations of type parent-child or of type container-element are not the main business of xlink. You have some way of specifying relations (using the role/arcrole attributes) but that is not central to the XLINK specification. Rejecting the whole xlink specification because of poor 'relation' support is not wise, because xlink was not build to address that problem in the first place. XLINK is pure and simple about defining links and it is here that is shines.
Regards,
Razvan
--
<M:D/>
:: M. David Peterson ::
XML & XML Transformations, C#, .NET, and Functional Languages Specialist
|
