[
Lists Home |
Date Index |
Thread Index
]
No, I'm very aware of this, though a question non-member's actual clout
in the process considering everything I know about the group's inner
workings.
The fact is that even the grammar exposed by SiXDML (along with
associated suggestions for performing joins) is a better approach to
querying collections. It represents collections as tangible paths,
still leaving the flexibility of resolution to the vendor.
Just seems that for a language that is repeatedly said to be designed
with XML databases in mind, having only one very abstract tie to an
amorphous concept makes it minimally useful as a general manipulation
language for use by xml database developers.
This is an opportunity for the WG to eat W3C dog food, but do it for a
reason. Perhaps a requirement of the argument to the collection
function should be that the location must minimally yield a document
with an rdf list of associated resources, if the engine is capable of
producing such a list, which I'm inclined to believe that most will be.
--
Tom Bradford - Virtuoso Technology Evangelist
OpenLink Software: http://www.openlinksw.com/
Personal Web Log: http://www.tbradford.org/
Michael Kay wrote:
> This remark suggests that you weren't aware that the XQuery WG consists
> largely of vendors, and that all specifications are put out to public
> review, and get many comments from those vendors who aren't members of the
> WG themselves. (That's why it takes so long!)
>
> The collection() function is deliberately designed as a high-level
> abstraction that doesn't constrain the architecture of database products,
> since we know there is a lot of variety there to be accommodated. Hopefully
> there will be some convergence on naming and addressing schemes to be used
> in the collection URI, but the language design doesn't rely on that
> happening, and leaves room for vendor flexibility. That's the way it should
> be.
|
