Lists Home |
Date Index |
- From: David Wang <firstname.lastname@example.org>
- To: "Hunter, David" <email@example.com>
- Date: Tue, 15 Feb 2000 14:43:18 -0500
> With that in mind, what does this approach buy us over, say, simply using an
> XSLT stylesheet to transform from one document type to another?
It buys us a lot. As you noted, an XSLT stylesheet can indeed transform
one document type to another. It does this because the logic built into
the stylesheet knows to explicitly transform one element to another,
However, the stylesheet does not express this relation in an easily
accessible form, and it certainly does not preserve knowledge of
relations discovered by default. In fact, it will not be easy to
extract any such relation embedded in the logic of a stylesheet.
This is because XSLT inherently is a transformation language and does
not care about the relations it transforms; in fact, it won't even keep
it around if it finds it unless external logic is supplied in
Thus, what I am suggesting is to create a way to describe semantic
relations, apart from the actual processing parts (this is akin to
keeping the object model untied to specific implementations). This is a
way to get at the core of interoperability -- what does X mean in the
context of Y -- without being tied to a processing model? XSLT
certainly is not a good starting point for this, while XLink looks like
a good starting candidate.
And when one weighs in what something like XLink brings such as
out-of-line linking, where we can describe relationships without
touching the instance documents, it looks better. And, if you'd like,
it'd be possible for XSLT to use the results of this language for its
own purposes since a relation would be easy for XSLT to manipulate.
So the goal is to *express* relationships, and XSLT does not do that.
It can only capture relationships and as a side effect give a product
using the relationships, but it can't describe the relationships for
others to use.