[
Lists Home |
Date Index |
Thread Index
]
Michael Kay wrote:
>...
> 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.
SQL's performance depends on how the data is actually layed out on disk,
who else has accessed it recently, how it is indexed etc.
>>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.
DOS protection is part of security. XSLT is not as clean from a resource
point view as a simpler language because you can't analyze an XSLT to
see what resources it downloads. You can't grep for "localhost" because
it could use string concatenation to build that string. Nevertheless, I
agree that XSLT is MUCH easier to secure than most Turing-complete
programming languages.
> 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.
Exactly.
>>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.
Now how does a dum computer program, at runtime, find the namespace that
will map from some-ns to my-ns and your-ns to my-ns and then integrate
them with 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.
It's also very inefficient, data-lossy, coarse-grained and hard to
assemble dynamically. I'm not deprecating it as a publishing technique.
I'm saying it is a poor substitute for technologies designed to allow
granular declarative mapping and entailment.
> 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.
Do you think that someoen will write a computer program to combine
independely constructed stylesheets on a per-element level, based on
desired input and output elements?
>...
> 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.
I always presumed that it was James Clark's way of saying that the DSSSL
transformation language still does some things better than XSLT but
hardly anyone knows how to use the transformation language so that's
just speculation.
Paul Prescod
|
