Comments on XSL Draft

[ray@xxxxxxxxxxxxxxx]

Hi all,
  I'm sorry I have to post a message like this as my de-lurk, but
the new XSL draft has really disappointed me. I'm sure there will be quite
a few people seconding what I'm about to say.

My main disappointment has to do with the new template mechanism which
introduces yet another syntax/grammar standard, and one that is
confusing and ambiguous. I don't understand why it was introduced.

Back in March, I demoed a small XSL editing app I wrote to XML devday
sat XML98 that which sat on top of docproc.  The reason the app was so
simple to write was because the previous XSL spec was written in XML,
so all parsing and tree manipulations were done as pure XML. The same
code that I used for the XML editor was also used for the XSL editor
with a subclass and some minor changes.  I could even use an XSL style
sheet to *style* XSL stylesheets, kinda like JAVADOC.

Simple, elegant, and even easy to read when indented, but not terse. 

In my opinion, the new XSL selector/rule syntax fails to head the
design principle requirements listed in the draft:


1) Terseness in XSL markup is of minimal importance
  
   Thus, inventing a new syntax to make templates more compact is
   a violation.

2) XSL should be expressed in XML syntax
   
   The templates pack significant syntax/semantics into a new grammar
   which sits inside of an attribute. I feel this is a design principle
   violation too. Such a complicated data structure should be in XML.

3) XSL should leverage other recommendations and standards including XML, ...

   XSL fails to leverage XML fully. XSL fails to leverage CSS or XPointer.
   If you wanted to a use a more concise grammar for the template attribute,
   why invent a new one when CSS selector syntax or a modification of
   Xpointer syntax would fit the bill nicely? (sure, the '>' operator of
   CSS selectors needs to be escaped, not a big deal. You could always
   change it to '/' )

   By inventing a new (poorly designed IMHO grammar), and not leveraging
   XML, CSS, or XPointer,  it seems to me that you are introducing a
   steeper learning curve to those already familar with other W3C standards,
   and making more work for implementors.



4) XSL should support browsing, printing, and interactive editing and 
  design tools.

   IMHO, the new syntax makes it significantly harder to support these
goals. Existing code cannot be reused, new parsers have to be
rewritten, etc etc 

Besides violating the design principles, I feel that the template
language is poorly designed. It is not intuitive, and suffers from
inconsistency.

For example, many people will find CSS selector syntax naturally
intuitive when it comes to class or attribute matching. Square
brackets have traditionally denoted array access, and in many
ways, the CSS syntax makes elements look like associative arrays,
where attribute names are the keys.

This is not surprising since a hashmap is one of the most common
ways people implement attributes in object models.


Enter XSL template syntax. To test my theory that the syntax is
poorly designed, I showed it to a web developer friend who is
familar with many XML/CSS standards.

The 'chapter/section/title' example was intuitively obvious
after a second, because yes, the "folder/directory" metaphor of
trees is familar.

I then showed him 'para//changed'. The confusion began. '//' 
is the ancestor operator? Many people's first guess will be
that '//' means 'para/*/changed' , that is,
'changed' is the grandchild of 'para'

I then showed him how attributes work,

'list[attribute(ordered)="yes")]'

and positions

'item[first-of-type()]'

To a programmer, the '[]' operator seems to mean
"evaluate the following expression", and that
attribute() and first-of-type() are function
calls.

So what will someone think 

'book[excerpt]/author' 

means?

If the '[]' operator denotes expression evaluation, then is
book[excerpt] a shorthand for book[attribute(excerpt)] --
a syntactic sugar for attribute matches?

Nope, rather, book[excerpt] means that book has an
excerpt element as a child. Huh? Why? It's a hack to
make sibling matches work. This has several flaws:

1) why not be consistent and use book[has-child(excerpt)]
2) you can only qualify elements by name, so the following CSS
selector cannot be encoded

    excerpt[critique="yes"] + author

  Meaning "author tag, if and only if it has a sibling
           of type excerpt with a critique attribute having
           value yes"

3) Sibling matches will be much more rare than attribute matches,
so if you want to use syntactic sugar, provide a shortcut syntax for
attribute(), not a method for siblings.

4) It still doesn't make sense. If 'excerpt' is a child of book,
shouldn't it be on the other side of the '/', grouped with
'author'? This violates the "folder/directory" paradigm.

    Why not   'book/author[has-sibling(excerpt)]'

IMHO the XSL spec has a long long way to go before it is as
usable as CSS.  My recommendations:

1) abandon the new template mechanism
2) use XML syntax for syntactic structure
3) if you must provide a more concise mechanism, leverage
   CSS or XPointer with appropriate modifications
4) reinstate modes. XML+CSS is already very powerful and
useful, except it can't make multiple passes over a document
to render things like a table of contents. The removal
of "modes" from XSL makes this significantly harder. Why
would I use XSL if it can't do much better than CSS in this
regard?

5) drop the "if" tags. XSL is not Cold Fusion, PHP, etc.
   Leverage ECMAScript/DOM 

-Ray


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