[
Lists Home |
Date Index |
Thread Index
]
At 11:42 AM 1/5/2002 +0000, Sean McGrath wrote:
>At 18:43 04/01/2002 -0500, Jonathan Robie wrote:
>
>>2. It may be very interesting to think about the potential benefits of
>>integrating XSLT and XQuery. If there is a compelling benefit to
>>integrating the languages, we should consider doing so after the release
>>of XQuery 1.0.
>
>Doesn't doing so *after* the release of XQuery 1.0 just create a legacy
>problem and just make things worse
>for everyone (except possibly vendors who get a free churn)?
It's not clear to me that there is a compelling need for XSLT and XQuery to
be the same language, or that a unified language would be a better language
than the two individual languages are. Asking XQuery to integrate with XSLT
already creates a legacy problem that did not exist beforehand. XQuery was
designed with different design goals, and XSLT already exists.
It makes no sense to say at this point, after a WG has been designing a
language since 1999, that this language should not proceed because it must
be unified with a different language. A Working Group needs to be able to
say what is in scope and what is not in scope for its work, and integrating
XQuery with XSLT was never in scope.
>Why rush? Who is rushing and why? As a user, I want something small, simple to
>understand, that works. I don't mind if it does not unify the Universe
>into one cohesive theory. I'd like
>that but I can wait for it. If a bunch of smart people advise that we
>should re-visit some core
>data model issues before layering on more standards, so be it. In fact,
>I'd be delighted because
>it would show concern for the deep longevity we are all seeking in data
>standards.
I think that the data model issues and the type issues are of central
importance, and we need to make sure we have these nailed in XQuery 1.0.
For me, these are the highest priority. Note that the data model and type
system *are* shared by XPath 2.0, XQuery, and XSLT. This is important.
Making XQuery and XSLT the same language, on the other hand, does not seem
as important, especially if it imposes real compromises on either language.
I use both Java and C++, which have strong similarities and all kinds of
subtle differences, but I have never wanted the two languages to be unified.
>"Standards" should not be rushed. They should take as long as they take.
>Especially when
>they are as complex, far-reaching and require innovation as XQuery does.
I think that we should have clear criteria for when a standard is finished.
For instance, I think that multiple compatible, independently developed
implementations should be required, public comment should be adequately
addressed, etc. This is analogous to saying that a programming project
should plan to pass quality assurance. However, it is rarely said that a
programming project "should take as long as it takes". There should be
clear requirements, with criteria for determining whether the requirements
have been met, and a schedule should be developed for meeting those
requirements.
The cost of developing any standard should not be unbounded, and people
joining a standards effort should have some idea when their work can come
to fruition, so they can justify their time to the companies for which they
work. In general, a standards effort, like a programming project, should
resist having their scope and requirements redefined, especially in late
stages of their effort. It is hard to hit a moving target.
There are exceptions. The XML Query WG has already been cooperating with
the XSL WG to create a unified data model and to unify XPath 2.0 and
XQuery, and we are cooperating on the type system and grammar. I think that
cooperation has been important, slow work, but it is paying off. There were
clear reasons that this work should have been done before XQuery 1.0 was
released.
I do not see the same compelling need to unify the syntax of XSLT and
XQuery. They are different languages. The fact that two different languages
have different syntaxes does not bother me.
Jonathan
|
