OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] XLINK support in browsers

[ Lists Home | Date Index | Thread Index ]

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.



News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS