[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

Re: [xsl] schema-1 (was something about keys, a long while ago)

---

---

Hi Elliotte,

> 1. PSVI aware APIs basically don't exist today. The best we can
> reasonably expect to do with schemas today is to get a simple
> boolean answer about an instance document, valid or invalid, and
> maybe have some default attribute values applied. Any technology
> that tries to build on top of PSVI and especially types is going to
> have major problems, simply due to the immaturity of the tools.

I agree completely that the burden on the vendors of XSLT processors
is going to be massive if they have to write their own
schema-validating parsers to fulfil XSLT requirements. That's why I'd
like to see the requirement for schema support being optional.

However, I think I'd argue that APIs should be designed to support the
application(s) that use the API rather than the other way around.
Identifying the kind of access that XPath requires from a PSVI will
help API designers to come up with an API that can support XPath. If
XPath doesn't state what it needs from the PSVI, then the APIs might
well turn out not to support (easily) the access that XPath requires.

Take the DOM as an example of an API that was designed without
reference to XPath. I'd naturally defer to those who've actually
implemented an XSLT processor, but the DOM view of a document is
different in a few interesting areas from the XPath view (e.g. CDATA
sections) and, from what I gather, the DOM interface to an XSLT
processor is not necessarily the interface that XSLT processors use
when they are doing all the parsing themselves (i.e. when you use them
from the command line). In big integrated XML applications such as
MSXML, I'm not convinced they use any kind of standard interface
internally during a normal transformation in any case.

In addition, while the APIs may not be around, the infoset items and
properties are very well described within the XML Schema Recs. So we
do already know what kind of information a schema-validating parser
should make available to an XPath processor, even if we don't know
precisely what the method names are.

So, yes, there are going to be problems, but the problems are going to
be about doing the implementation, not about defining how XPath should
work with XML Schemas. *As long as* it is not *required* for an XSLT
processor to use the PSVI, then it shouldn't slow down implementation
of the other stuff in XSLT 2.0.

> 2. There are lot of requirements in the XSLT 2.0 requirements that
> are independent of schemas and the PSVI. These are useful things to
> add, and can be implemented today.
>
> 3. There are lot of requirements in the XSLT 2.0 requirements that
> are dependent on schemas and the PSVI. These are also useful things
> to add, but cannot be implemented today.

I'm not sure what the reasoning is behind the 'can' and 'cannot'. I am
sure that there will be some other aspects of the XSLT 2.0
requirements that will take time and effort to implement; yes, the XML
Schema validation is a large part (which is why I think it should be
optional) but however much we admire Mike we can't realistically
expect him to implement everything in a fictional XSLT 2.0 WD by the
end of the day (although of course he will have had some prior warning
about what it will need to do).

> 4. The community does not have a lot of experience with PSVI-based
> systems yet. Anything we design today is likely to contain
> significant flaws that will only be obvious in hindsight.

I agree with that to a degree. However, I think that this argument is
applicable, to a greater or lesser extent, to every change that will
be made to XPath 2.0 and XSLT 2.0, (though I agree that we
particularly lack experience with XML Schemas).

There are two aspects, I think:

 - lacking experience with using XML Schemas and therefore being
   unsure what requirements have the highest priority
 - not knowing whether a particular syntax/data model will be
   sufficient to handle those requirements

Against the first, we do have some experience with other types of
'schema language' (in its broadest sense), most notably DTDs. The XSL
WG can either take a minimalist approach (only make available
information for which there is a proven requirement, which might, as
you suggest, be an empty set) or go for the whole bundle (follow the
PSVI descriptions, make all the information available and let users
decide which they need to use in particular stylesheets).

The second aspect is exactly what is faced whenever anyone writes a
Spec, and we can only counter it by trying it out, thinking up use
cases, getting early implementations and so on.

Also, is it not equally likely that trying to design the 'rest' of
XPath/XSLT 2.0 without factoring in XML Schema to the equation is
likely to result in a design that cannot later be adapted to include
XML Schema information? Take, for example, the fact that XPath 1.0
numbers don't match up with any of the numeric XML Schema data types
(it's closest to xs:double, but doesn't allow exponents), or the fact
that XPath 1.0 doesn't have the concept of 'sequences'.

My final argument against your proposal is simply that it's probably
'too late' in the process for the requirements to be rewritten to the
extent of cutting out everything to do with XML Schema. Given that
assumption (which might be wrong), I think our energies would be
better directed at trying to make the XML Schema support that it will
have as good as possible, rather than arguing about whether or not it
should be there in the first place.

Cheers,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list

---