M. David Peterson wrote:
> 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
Sure: Relanx NG for Relax NG fans :)) But then I would have to give
you some examples of Relax NG tags and, to my shame, I have to admit
that I have never use this technology (yet !).
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
|
