> Lars Martin wrote:
(to clarify Jonathan Borden wrote this and Lars Martin forwarded it to the
list).
> > this is just something I find useful for the type of database,
repository,
> > document, whatever operations we need to perform. The "select" is a
select,
> > no more, no less, so it does work on NodeLists, or sets, assuming that
is
> > what the select returns.
> >
> > That's why "update-or-insert" otherwise you can easily do an
if-then-else
> > inside of a for-each. This operation obviates the need for an explicit
loop.
>
> By specifying the query language in this way, it implies that the XML
> repository needs to be implemented in a specific way.
I don't follow. Suppose you can have at most one data element having a
particular constraint. You wish to either insert the element or replace the
current one if it exists. How does this constrain the repository?
> In particular,
> the server would have to expose the entire repository as a single
> virtualized document.
Is this true? Lets generalize beyond XPath into XPointer which is
defined as a URI fragment identifier, or forget that and use virtual maps,
given the URI:
http://example.org/whatever/servlet/another/path/foo
perhaps
http://example.org/whatever/servlet/another
is the document and
/path/foo
is an XPath, so in fact use of XPaths in paricular and URIs in general ought
not constrain the underlying data format.
>
> Our goal should be to create a query language that is incredibly simple,
> that is easily implemented,
agreed.
>..and that does not force an implementor into
> exposing their data in any other way than they already had.
what do you mean by 'expose', do we require that the data be exposed as
XML? what if the data is binary, is this within our scope?
>I am
> willing to bet quite a bit that Software AG, Excelon Corp, Openlink
> Software, Microsoft, and Oracle will all pose the same argument.
Ok. but then what in particular are we to offer that, for example, is not
already offered by say Quilt? It was my thought that we might define common
interfaces for accessing XML data, my first thought is that this might be a
DOM or SAX interface, and provide common specifications for interfaces to
contexts, access control etc. From my readings, I see proposals for a number
of query languages, but not so many for update languages, so we thought this
might be a fruitful place to start.
Jonathan Borden
The Open Healthcare Group
http://www.openhealth.org
------------------------------------------------------------------
Post a message: mailto:[EMAIL PROTECTED]
Unsubscribe: mailto:[EMAIL PROTECTED]
Contact adminstrator: mailto:[EMAIL PROTECTED]
Read archived messages: http://www.xmldb.org/
------------------------------------------------------------------
