[
Lists Home |
Date Index |
Thread Index
]
> > I'll try again: once you've defined an executable
> transformation (eg.
> > using XSLT), what useful job is there left for RDF/DAML/OWL to do?
>
> Probably none. But I wouldn't define an executable
> transformation in an
> XSLT program when I could define a declarative mapping in a
> single line of OWL.
>
There are many valid ways of doing transformations other than XSLT, and
I haven't followed the thread that led to this, so I'm not sure what
it's being compared with here, but there are a few assertions made here
that I think need to be picked up on.
> First, the XSLT is Turing complete. That means that if you
> send an agent
> onto the Web to find an XSLT that translates ebXML into BizTalk, you
> have no idea what computational resources you are committing
> to run the
> transformation it finds. You can't even kill the process with
> confidence
> when it runs in an "unreasonable amount of time" because
> perhaps it was
> just one second away from completing the task. So you set
> some arbitrary
> runtime limit and take your chances. I *believe* that the
> computational
> properties of semantic web reasoners are more predictable.
> But I am not
> a computational logician so I could be wrong on that.
I think there are very few technologies that allow this kind of
predictability. For example, SQL performance is pretty difficult to
predict even though (core) SQL is not computationally complete. In fact,
I think that you need to limit the expressive power of a technology very
severely indeed if you want this feature.
>
> Also, there are issues around security and analysis of
> Turing-complete
> programs versus declarative specifciations. And serious optimization
> issues! So overall, I see the OWL route as being more
> reliable, secure and performant.
Apart from denial-of-service risks, security has nothing to do with
Turing completeness, it's to do with the external resources that a an
executable has access to. From this point of view, XSLT is very clean.
It's also very clean from an optimization point of view, in that being
side-effect-free, it's very amenable to rewriting in the same way as
SQL. Of course, a language with less functionality will generally do the
same job faster than a language with more functionality.
>
> Second, the XSLT specification has weak support for handing
> off from one
> XSLT to another on a very granular (per-element) basis. Consider:
>
> Input:
>
> <some-ns:coffee>
> <some-ns:hot/>
> <your-ns:sweet/>
> </some-ns:coffee>
>
> Wished-for Output:
>
> <my-ns:drink>
> <my-ns:temperature>hot</my-ns>
> <my-ns:sugary/>
> </my-ns:drink>
>
> I need to be able to switch mapping specifications's midstream from
> some-ns->my-ns to your-ns->my-ns. I'm having a hard time
> envisioning how
> I would do this in XSLT, but I think it is standard in logic
> languages.
> (Prolog calls it unification, but I think the Prolog algorithm is
> probably more powerful than is needed for OWL)
I don't see the problem here. The apply-templates mechanism does exactly
this. It's quite straightforward to combine two push-style stylesheets
for different namespaces using xsl:import.
>
> Third, I've never heard of anybody composing XSLTs that were
> developed
> entirely independently except by building a pipeline where
> the document
> is processed by one and handed off to another.
I'm not sure why you are deprecating the pipeline approach, it's
extremely powerful.
But I have seen other approaches, e.g. in preparing W3C specs for
publication, we've recently combined a stylesheet that renders diff
markup with another that renders BNF, these were developed quite
independently of each other.
<snip/>
>
> Fourth, it is much easier to use OWL as it was intended to be
> used than
> to chain-gang XSLT into the job. XSLT is not even designed to be a
> "general-purpose transformation language" much less a
> semantic mapping
> language.
>
The XSLT 1.0 spec contains the statement that "XSLT is not intended as a
completely general-purpose transformation language". But is it true? I
have always surmised it was added at the end of a long and fruitless
discussion about the scope of the language, to represent some kind of
compromise between those who wanted the language to be general-purpose
and those who wanted it to be small (and/or to focus on rendering
applications). It's never been clear to me whether the idea was to
justify the inclusion of features that aren't general-purpose (like
attribute sets and xsl:number), or to justify the exclusion of features
that are general-purpose (like functions and regular expressions).
Either way, I regard it as a political statement (or perhaps a
historical one), not as a technical statement about properties of the
language.
Michael Kay
Software AG
home: Michael.H.Kay@ntlworld.com
work: Michael.Kay@softwareag.com
|
