Re: [xsl] An interesting angle on types in XSLT 2.0?

Subject: Re: [xsl] An interesting angle on types in XSLT 2.0?
From: "Mike Haarman" <mhaarman@xxxxxxxxxxxxxxxxxx>
Date: Fri, 16 May 2003 11:23:39 -0500
----- Original Message ----- 
From: "Andrew Watt" <andrew@xxxxxxxxxxxxxx>

> Yet XML, viewed from the perspective of, for example, an HTML page author
> does just the same thing - it introduces a new class of errors. HTML, and
> SGML, allow omission of end tags, of quotes on attribute values etc. So XML
> introduces new classes of errors that are, not to put too fine a point on
> it, show stoppers for markup not written according to the rules.

This is the basis for much of the criticism, to be sure.  As you say, the
argument is a bit more nuanced than that.  For one thing browser windage, for
all its simplification of web authoring for newbies, remained a net loss for
ease-of-use when you consider portability over divergent implementations.  Not
even the most convicted HTML neanderthals want to go back to 4.1 transitional
when they see the evident value the additional constraints make possible in
terms of IDE functionality, processing ease, portability, etc.

As to tag minimization, who misses that when tag completion is so widely and
easily implemented?  Closing tags simplify human parsing of markup as much as
machine parsing.

The new class of errors available to stylesheet authors stem from lexical
validation of datatypes and I think a strong case can be made that some systems
will want to conceal this layer of complexity from their document-oriented
users.  This is not only possible, I think it will be relatively painless.

> Just as an improperly written XSLT 2.0 stylesheet may not run at all so an
> improperly written XHTML page may not display at all, while its looser HTML
> counterpart does.

Sloppy code is just sloppy and inhibits portability and legibility, sloppy data
can have positive value for many applications.  I may not want to fail; I may
want to find out what's wrong and inform the user.

> If a new class of errors introduced by XML is "good", why is a new class of
> errors introduced by types in XSLT 2.0 "bad"?

Not inherently bad, just a new range of considerations.  My concern has been to
see that certain simple and powerful idioms available to authors in the first
generation of tools remain reasonably simple and powerful in the next.  The
simple junk-in-junk-out filter, for example, or the browser-as-IDE model, should
still be available.

I do feel the WGs cast too wide a net when gathering requirements for 2.0; that
they made their job more difficult than it had to be; that the current trend
leads the drafts to look a bit like a specification for a verbose and crippled
Haskell.  Where is the demand for that!?

That said, I think the XSLT and XPath WGs have managed to strike a pretty good
balance.  It will be possible to ignore much of the complexity data-typing has
introduced and it will be straightforward to conceal that complexity where it
can't be ignored.  The idioms I have been concerned to preserve are no longer
the default behavior but I have learned that implementing them is not onerous.

If anyone cares, I am happy to announce myself an advocate for the new drafts.
My document-oriented brethren will cry apostacy, perhaps, but I've no desire to
cling to an error for the sake of a hobgoblin consistency.

The trends are real, the concerns are valid, but to my mind 2.0 is not a
heretical production in its current form.


Mike


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


Current Thread