RE: Abbreviated Location Paths...

Guy_Murphy@xxxxxxxxxx [mailto:Guy_Murphy@xxxxxxxxxx] wrote
> 
> Does anybody else find the abbreviated location paths less 
> clear in XSLT than the verbose form? (The abbriviated form looks more 
> verbose to me).
> 
My first impression is that the long forms are much more systematic than the
short forms we are used to: they are therefore more comprehensible and also
more extensible. But they are also very verbose!

I can't say I'm happy with the compromise of including both forms. That's
always a bad design choice: twice as much work for the implementor, twice as
many pages in the manual, twice the learning curve for users, larger and
slower executables, twice the number of bugs. It also suggests a lack of
clarity in the design objectives.

My general assessment of this draft is slight disappointment. There are many
improvements to both the language and its description, but there are still a
lot of gaps in both, and no sign yet that this will imminently be a stable
spec which I can risk real customer projects on. Some major uncertainties
expressed in editorial notes (e.g. admitting a lack of committee consensus
on allowing apply-templates with no "select" attribute) are still there from
the previous draft, and the stated intention to converge with XPointer
creates another great raft of uncertainty. 

Some of the new features (e.g. variables and expressions) are very welcome
but very imprecisely defined. There are even some syntactic ambiguities,
e.g. the hyphen vs. minus distinction.

If I was Microsoft I'd be reluctant to move forward to this spec as there
will clearly be more changes. I think that increases the risk that the
Microsoft dialect currently in the field will become the de facto standard.
(Some of us remember how ANSI had to unwind all their improvements to SQL
and make it compatible with IBM's DB2 product...)

Mike Kay


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