RE: New/old pattern syntax, why can't we have both ?

Is Xpointer intended to solve the problem of patterns?  It seems to me that
patterns in XSL are much more complex than XPointers.  If XPointers could
be used then I would very much agree with using them instead of coming up
with another syntax.

Let's be practical here.  Software is already a complicated endeavor.  If
we come up with new syntax's for every problem we will end up with a "tower
of babel" effect.  Some people may enjoy contemplating new languages but we
get paid to build things which work.

The main value of XML is to allow us to express information in a common
format.  This means that with any XML parser I can read any XML document.
If I have to have a domain specific parser for each XML application then we
have thrown this away.

If Xpointer is sufficient then much of this goes away because we will
probably have an Xpointer parser available already (at least when XPointers
become widely used).
If they are not sufficient, then we should use base XML syntax.

What is the point of this new syntax?  It is more terse and "readable" when
looking at it raw?  Do we really expect that people will write XSL by hand.
This may be the case now because of the lack of tools, but it absolutely
will not be in the long run.  You will view XSL through some sort of
abstraction.  If this doesn't happen, then XSL is dead.  Normal users (and
this is the audience) are not programmers.

The idea of having two syntax's is even worse.  Then any implementing
software needs to understand two vocabularies.  If people want a more
readable and concise format then the stylesheet editor could provide a
translation.  The format stored in the file should be XML only.  This
attempt to make XSL easily editable in raw form is misguided.  That is the
purpose of an editor.  The XSL group should be promoting the use of
standard XML.

There is an analogy from my past.  When relational databases started to be
used, many programmers immediately started doing things like putting
multiple values into a field because they thought this was more efficient.
Unfortunately, this made the database unusable for analysis by normal
relational database tools.  I'm afraid that we are going to see the same
thing with XML.  Then XML will experience the backlash that relational
databases did early on.  Is the XSL group setting a good example of XML
usage?

Here is the most telling item from the new XSL spec.
<!-- Used for attribute values that are patterns.-->
<!ENTITY % pattern "CDATA">

>From the Spec's Design Principles:
-XSL should leverage other recommendations and standards, including XML,
XLL, DOM, HTML and ECMAScript.
-XSL should be expressed in XML syntax.
-XSL stylesheets should be human-readable and reasonably clear.
-Terseness in XSL markup is of minimal importance.


Repeat after me.  "Complexity baaaadddd, Simplicity Goooodddd." (apologies
to Mr. Orwell)

My apologies for sounding unappreciative of the group's work.  But I think
this issue is of critical importance.  I have to build an XSL processor.
This syntax makes that job at least twice as hard and really adds no
functionality.

-Mark






"James K. Tauber" <jtauber@xxxxxxxxxxx> on 08/19/98 09:31:20 AM

Please respond to xsl-list@xxxxxxxxxxxxxxxx

To:   xsl-list@xxxxxxxxxxxxxxxx
cc:    (bcc: Mark Overton/PTSLS)
Subject:  RE: New/old pattern syntax, why can't we have both ?




> Isn't this more work, not less, and still leaves the
> _very_ undesirable situation of having "non-XML" XML?

We already have a non-XML syntax for XPointers and I don't think anyone
would want to argue for an XML version of an XPointer.

My feeling on the issue is that a spec be developed for tree addressing
patterns that serves the needs of both XPointers and XSL patterns. Such a
spec could stand apart (but be normative to) both XLink and XSL.

James

--
James Tauber / jtauber@xxxxxxxxxxx      http://www.jtauber.com/
Lecturer and Associate Researcher
Electronic Commerce Network             ( http://www.xmlinfo.com/
Curtin Business School                  ( http://www.xmlsoftware.com/
Perth, Western Australia                ( http://www.schema.net/


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







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