Crazy idea

[Oren Ben-Kiki]

Paul Prescod <paul at prescod.net> wrote:
> This "stylesheet as schema" idea comes around every so often but I think
> that it has one major flaw: stylesheets cannot drive syntax directed
> editors.

Validation is one thing, and assisted construction is another. Related
issues, to be sure, but there is a lot of functionality you'd expect in
"assisted document construction" which simply does not belong in validation.
It is not at all clear to me that a specification for validation should
consider these issues. That said...

Stylesheets _can_ be used to assist construction, as in "transform an empty
node matching the following criteria into ...". The compromise I suggested -
that a "schema" stylesheet must be a no-op if applied twice - immediatly
suggests that such stylesheets would be very useful in assisted
construction. Just run the partial document through them, flag errors, and
repeat until all errors are gone and the user is happy.

> From a mathematical point of view, I don't think that XSchemas are much
> stronger than DTDs. The set of tag-based languages they can describe are
> pretty much the same.

The mathematical point of view is all well and good, but in practice
XSchemas meant to replace DTDs since they can do useful things DTD can't,
period. If we accept XSLT, we'll know for certain that whatever we throw at
it, it will be able to handle. With an XSchema type specification, there's
allways the worry that some case has not been covered, and we'd need
XSchema2.0 to make up for the lack.

> The XSLT set of languages would be radically
> different. What's the XSLT equivalent for this content model:
>
> ((a*,(b|c)+,d)+|(d,(b|c)*,d?)+)

This can be done in XSLT by converting the regexp into a series of 'choose'
statements. Admittedly, in this particular case, the result wouldn't be
pretty. If it turns out that this sort of constraints is common, we might
consider adding some extra ability into XSLT to make expressing them more
convenient.

> On the other hand there are constraints that XSLT could support that
> schemas probably could not.

And things which are trivial to express in XSLT which probably would be a
pain to express in a schema language (e.g., if the element has an 'a'
attribute with value 'v', it should not contain an 'e' sub-element).

I have no idea what the overall effect on real-world schemas would be. It
might be interesting to take some real world DTDs/XSchemas and convert them
to XSLT, as a test. Note that whoever does that gains the benefit of an
executable validation specification stronger then a DTD which runs today on
his XML system of choice.

Which brings up an interesting point: people who are interested in effective
validation can use the XSLT way today. It might be that some people have
already done so. Assume that it is a good way - that is, people get what
they need from it. Further assume that XSchema recommendation will take a
long time to finalize, and longer for implementations to become common,
while XSLT implementations are much more widespread. The expected result
would be that nobody would care about the XSchema recommendation in
practice, regardless of the W3C.

The only problem is that the W3C will, in the mean while, twist other
recommendations to be compatible with XSchemas. For example, specifying
three name spaces for XHTML - which brings us a full circle back to where we
started a week ago :-)

Have fun,

    Oren Ben-Kiki


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)