[
Lists Home |
Date Index |
Thread Index
]
Jonathan Robie wrote:
> I believe it is technically feasible to integrate XSLT and XQuery along
the
> lines suggested by James in:
>
> http://www.jclark.com/xml/construct.html
>
> However, I don't think it would be a good idea to try to do so before
> XQuery 1.0 is released. This is a cost-benefit decision for me. In the
rest
> of this message, it may sound like I don't like the idea James proposes,
> but that's not really true. I think it is an interesting proposal that
> should be considered in due time, but not placed on the critical path for
> XQuery 1.0. The proposal raises a large number of procedural and technical
> questions, and I think this should be freely explored over a period of
> time, not made into a new set of requirements for an existing standards
effort.
My priority would be that XSLT (2.0?) roughly be extended to have the same
capabilities as XQuery. I imagine this largely would come from using XPath
2.0, but as has been discussed, element construction would come from XSLT.
So I _imagine_ that such extensions (to XSLT) could be done with minimal
damage.
>
> Here is the problem that James says he is trying to solve:
>
> >Currently XSLT and XQuery use very similar syntaxes for element and
> >attribute construction.
I am unsure how important this is, primarily because XSLT is real XML and
XQuery sort of looks like XML from time to time, but clearly is not XML.
Attempts to make XQuery look more like real XML may simply add to the
confusion, and arguments, which already may exist. While I am not personally
opposed to the XQuery pseudo-XML syntax, I do appreciate and am sympathetic
to the arguments against it.
For example,
> >
> ><p>This is a <a href="{@ref}">link</a>.</p> works the same in both
> >XSLT and XQuery.
>
> There are actually many constructs which are similar, but different, in
> XSLT and XQuery, just as many of the features of Java and C++ are similar,
> but different. That does not necessarily mean that Java and C++ should be
> unified. There are compelling reasons to unify the path expression
> language. I am not yet convinced that there is an equally urgent need to
> unify element constructors, and if we did so, I would think that would
best
> be done as part of a deeper integration of the two languages altogether.
Perhaps the argument can be made not for unifying the 'surface syntax' of
XSLT and XQuery, but rather the underlying model. To the extend that the
XQuery formalism is a good model of XML, and incorporates, or references
good models of XML in general, one would wonder why XSLT 2.0 would need a
different formalism.
To use your example, this would be analogous to having C++ compile to the
Java VM, or essentially what MS has done with C#. Hence I say that the
proper comparison would be between C# and Java -- well assuming a whole lot
of extraneous issues related to MS and Sun didn't exist :-))
That said, if there are some simple changes which would unify the (non-XML)
attribute constructor _syntax_ that would be a Good Thing.
Jonathan
|
