Lists Home |
Date Index |
Mike Champion wrote:
> 1/8/2002 12:47:45 AM, "Jonathan Borden" <firstname.lastname@example.org> wrote:
>>What could possibly require _a year_ more work? specifics please.
> I think it's basically:
> - Unify the XSLT/XPath/XQuery data model. This may be more or less done
ok. so this isn't currently an issue.
> - Make sure that queries can be defined to return schema-valid results
Since XQuery allows a _function_ to declare its returned datatype, one can
always wrap the query in a function and hence satisfy schema-validity by
this mechanism (to the extent that schema-validity is equivalent to some XML
having such a datatype.
> - Sort out/Respond to feedback on the latest draft, including
> Strong typing as a requirement in XQuery; is there enough gain for the
typed stuff, so let's see whether a strongly typed language 'performs'
> The use of quasi-XML syntax in the XQuery element/attribute
Oh dear! Let's not debate _that_ for a whole year
> The XQueryX pure XML syntax -- is it needed? Should it be more
My vote: bag it (XQueryX is _really_ ugly) and use XSLT, perhaps XSLT 2.0
could be 'extended' to _allow_ strong datatyping, if this is essential.
> Updates - should they hold up the spec to put in updates.
This is the big issue, but from what I hear, Jonathan Robie is proposing:
1) XQuery sans Update goes to CR now
2) XQuery con Update is released in a 6 month time frame.
(BTW 6 months or more of CR may very well be approproiate -- I just want to
get people implementing and using XQuery which is one of the things that CR
is for, correct?)
> So, XQuery -- as currently defined -- could easily take a year or more to
> before they get to a Candidate Recommendation, especially if they add
> (as many are pleading).
Ahhhhhhhhh.... it could just as well take 10 years to arrive at complete
perfection and total consensus...
> My personal understanding is that "make sure that queries can be defined
> return schema-valid results" (aka strong typing) is the really central
> problem here.
Perhaps I am being naive, but cannot queries already be defined to return
strongly typed results (via the typed function mechanism), so what is the
big deal about this? And if there is some edge case where what I have
suggested is not appropriate, why do I care?
> So, what is to be done? Looking at recent history for inspiration ....
> The DOM "punt on the hard problems each iteration" strategy is out,
> type system can't be retrofitted.
Convince me that what is already present in terms of types is not adequate,
and that that argument is hence not a red herring.
One might present the argument that the DOM's current problems _arise_ from
its failure to specify an "infoset" prior to specifying an "API". XML itself
doesn't have that problem because its syntactic "infoset" are the EBNF
productions that properly describe XML (and are included in XML 1.0).
> The XLink "tweak it until people have learned to live without it" outcome
is one '
> possibility I worry about.
> The Schema "if it's too complex new specs will emerge that fork the
> scenario is another possibility, especially if XSLT is considered a "query
> The XSLT "the business world can't wait for the Recommendation, so
> the draft" scenario may be the best we can hope for, even though the draft
> be a tar baby for the early adopters. Is that more or less the "extreme
> programming" scenario?
No! The "extreme programming" scenario that I am looking at is having Murata
Makoto and James Clark relatively quickly (but thoughtfully) devising two
schema languages that get _quickly_ merged into a single, quickly developed,
For those who poo poo formalisms, both RELAX and TREX started with
formalisms, hence the ease with which the _surface syntaxes_ of RELAX and
TREX were merged. Similarly XQuery has started with a formalism, which gives
me some measure of confidence that purely syntactic issues can be sorted out
later. Of course that's just a theory.