[
Lists Home |
Date Index |
Thread Index
]
Michael Kay wrote:
>...XQuery's primary usage
> scenario is searching XML databases, hence it's stronger on data than on
> documents, and it's designed to enable a lot of static optimization and
> type-checking.
>
> It would have been nicer if we could have come up with a single language
> suited to both tasks, rather than two languages with a 70% overlap in
> functionality; but I don't think it's the end of the world that we haven't
> achieved that. In fact, a bit of friendly competition sometimes does no
harm
> and can be in the users' interest in the long run.
>
I couldn't agree more. As I've said, one language is XML the other isn't,
fine. In order to ease the implementation of the non-XML parsing tasks e.g.
the "{$foo}" sorts of stuff, it would be convenient to unify this specific
syntax (e.g. used in attribute constructors). Since this is already
in -wide- use in XSLT 1.0, XQuery should adopt the XSLT syntax --for this
specific area-- if possible. What this means is that:
-- XQuery should normatively reference XPath 2.0 for the PathExpr grammar
production rather than duplicating it -- if at all possible. XQuery should
normatively reference as many productions in XPath 2.0 as possible for the
simple reason that XPath 1.0 is already in widespread use (this is all under
the general guideline of 'unify the non-XML syntax as much as possible'). So
y'all ought to be able to chop out a page or so of the REC which is always a
good thing (IMHO).
Jonathan
|
