[
Lists Home |
Date Index |
Thread Index
]
Hi David,
>> Since this is compile-time assessment of the expressions in the
>> stylesheet, I think that the answer is to not import a schema to
>> the stylesheet in the first place,
>
> Well yes, but that answer's the same as Jonathan's. If someone
> argues that supporting schema complex types, bloats the spec,
> complicates the use of the language, and provides lots of
> undesirable side effects. Being told that you can use Xpath/XSLT
> without using that feature is I suppose better than nothing, but
> hardly a justification for the schema complex type support being
> there in the first place.
I wasn't attempting to justify it. It appeared to me that you were
saying that Schematron would be unusable because of the support for
complex types; I was simply pointing out that it is still completely
usable. I agree with the other parts of your argument.
>> I can't see anything in the XSLT 2.0 WD that says that, during
>> compilation, it will access a particular instance document's schema
>> and use that to optimise queries.
>
> Neither could I actually, but this so far has been the only
> justification offered for the provision of strong typing based on
> schema complex types, so if it is Xquery only, what's it doing in
> Xpath?
Frankly, I don't know. There is a "should" requirement for XPath 2.0
to enable users to select elements or particular types (or belonging
to particular substitution groups). This is supported by the "instance
of" operator and "SequenceType checking" which isn't currently
specified completely. (If that was lightweight then it wouldn't be much
of a problem, but I have the horrible suspicion that SequenceType
checking is going to involve it's own validation model, as in the
XQuery Semantics document...) Perhaps there's something in that
requirement that entails strong typing based on schema complex types?
Statically checking and optimising path expressions based on the
complex type definitions in a schema doesn't seem to be on the
requirements for XPath 2.0, although there is a requirement that XSLT
2.0 "Could Improve Efficiency of Transformations on Large Documents".
I don't think that the kind of optimisations we're talking about would
have much effect there, however.
Or perhaps it's just that the WGs are trying to make XPath 2.0 as
large a subset of XQuery as they can.
Oh sorry, was that a rhetorical question?
>> If a processor substituted aaa/bbb for the empty sequence on the
>> assumption that the source document was completely valid, there
>> would be a rather strange situation where the data model contained
>> an element that was inaccessible from the stylesheet.
>
> You say it's strange, and I agree, but neither of us are on the WG,
> It's hard to understand how the argument that the type system allows
> compile time optimisation (if it is true) can fail to lead to this
> strange situation.
Well, it could lead instead to a complete refusal of the processor to
transform the document.
Cheers,
Jeni
---
Jeni Tennison
http://www.jenitennison.com/
|
