Re: [xml-dev] The use of XML syntax in XML Query

[Paul T <pault12@pacbell.net>]

----- Original Message -----
From: "James Clark" <jjc@jclark.com>

> construction in XQuery. If there was the political will, I believe XSLT
and
> XQuery element construction could be unified. Some time ago, before I
> dropped out of W3C activities, I wrote a short paper on this.  See:
>
>     http://www.jclark.com/xml/construct.html

To me the paper looks slightly self-contradicting.

(1)

"Advantages of XSLT syntax. XSLT is well-formed XML"
( and then explains why it is good to be well-formed XML)

At the end it says ( I don't  think that it is important that
it talks about some 'ABQL' , please correct me if I don't
understand something obvious )

(2)

"The logical conclusion would seem to be that we have one set of semantic
constructs. For each semantic construct, we have a syntax that uses elements
and one that uses characters (an XML and non-XML syntax). These can be
freely mixed. Constructs using element syntax can contain constructs using
non-element syntax and vice-versa without restriction."

This "can be freely mixed" actually says that
it would not be possible to leverage XML parser,
as-is ( by the way, this 'leveraging' is anyway
questionable, because XPath is not well-formed XML ,
so parsing the XSLT stylesheet anyway requires
writing some non-XML parser to parse XPath )

Anyway, even if forgeting about the XPath,  to me it
seems that (2) contradictis all the advantages,
listed in (1).

If there is a mix of XML and non-XML syntax -
then all the advantages of "XSLT is well-formed XML"
are *gone*.

Also I don't understand  what is the conclusion
of that paper. If it is 'we should go for a mix
of XML / non-XML syntaxes and that would imply
some non-XML-ish notation" - I agree with that
conclusion. If there is something else - what is that
'else' ?

Below I assume that because of (2), the conclusion is :
"yes for non-XML-ish notation, because it is the
right thing to do".

So, the 'right thing' implies writing some special parser
(which would  be similiar to XSLScript's parser.
XSLScript allows mixing  XSLT constructions,
written in XML syntax with XSLT constructions,
written in non-XML syntax.)

However, because I've spent some time
writing the prototype of that parser,
I just know that 'free-style' mixing of
XML-ish syntax with non-XML-ish
syntax is hard to design properly
( not to talk about the implementation ).
It is not like it is with XPath when
'non-XML syntax' part ( XPath )
is clearly separated from the
'XML syntax' part of XSLT.

Also, if the task is to make the mix applicable
to *both* XSLT *and* XQuery, that would
be more challenging task, because some
constructions, that would  be good for
XSLT,  may be bad for XQuery
and vise versa.

Also, no matter what is the task ( 'some new
notation  for XSLT' or 'some new  notation for both
XSML and XQuery' ) there would *always* be
some problem with escaping. I mean that we kinda have
some 'official' way to escape < with &lt;,
but there is no 'official' way for escaping,
say, '{' .

" could be used as a special token, but it makes
it 'not friendly to mixed content'. There are at least
2 possible ways of escaping,  one "mixed content
friendly" and another \based  ...  That
mixed notation is not obvious.

Also, if making the step from XML-ish syntax
of XSLT to some mix of non-XML-ish and
XML-ish syntax for XSLT and / or XQuery,
why stop there? If *any* agreement is reached
about, say, escaping, then the same agreement
could be applied to many other layers, which
are at the moment XML-only  (such as XSD,
for example.)

I'd love to hear what is the conclusion of
your paper. If it is : "let us try to re-visit
XSLT syntax to allow mix of XML / Non-XML
and then possibly try to synchronize
the mix with XQuery syntax" - I believe that
this is :

1. Possible.
2. Right thing to do on a long run.
3. Hard.
4. It would take relatively long time
to bring XSLT and XQuery in sync
with that 'common mixed notation'.
I estimate a long time, because of
the timing it took XSL FO to get in sync
with CSS, maybe things are now faster
in W3C - I don't know. Only insider can
estimate.
5. The effort is doomed,  if there is
no political will to get XQuery in sync
with XSLT.

Rgds.Paul.

PS. If  'mixed notation for XSLT / XQuery '
was not the conclusion of your paper,
I'm sorry for writing some stuff, it may be
irrelevant.

As an excuse, I should say that  (2) was the
only part of text, containing the word 'conclusion'
in it's body, and also it is located at the tail of
the document, so I decided that (2) is the
conclusion.