Re: [Qexo-general] Re: Kava + Xerces

[Joseph Coffland]

On Tue, 24 Feb 2004 14:37:57 -0800, "Per Bothner" <address@hidden> said:
> > Basically, we need to implement the Schema datatype system.  I have
> > looked around.
> 
> It seems like Xerces2-J has a representation of Schema types.  What
> Qexo could do is to have some wrapper classes around the Xerces
> classes that can plug in instead of gnu.kawa.xml.NodeType and
> related classes.  But I'd have to look at this more closely.
It should have an implementation somewhere.  Qexo needs more than just
PSVI.  It needs to be able to check if some string matches a given
type.  That code should be in Xerces somewhere.  I don't know how 
accessible it is.  It probably also needs type coercion.  This implies
a more sophisticated type system than Xerces provides.

> > There has been talk about making it possible to update documents in
> > XQuery.
> 
> I see 3 different things this can mean:
> (1) Easier ways to modify a document and create a modified document.
> XSLT is one approach.  This of course is purely functional and not
> a real "update", but it can serve many of the needs of update.
> (2) Modify a node tree (DOM) in place.  In Qexo, that would be
> modifying a NodeTree.
> (3) Modify an XML file or an XML dataset stored in a database, in place.
> This presumably means not invalidating existing document/node IDs,
> which may be difficult.  This goal is very much database-driven.
I'm only concerned with (2).

> It's not that easy.  First of course you're changing the fact that
> XQuery is a pure side-effect-free language.  Second you have to be
> careful about node identity.  Remember that in:
>    let $x := <a/> return (<b>{$x}</b>, $x)
> the <a/> is *copied* - the <a/> child of <b> is not the same node
> as $x.  If you're going to allow operations that modify a node you
> have to be careful to define what nodes are modified and how.
Why?  I'm not so sure that XQuery has the same risks, as far as
side affects go, as scheme.  For example you cannot pass functions
as first class objects in XQuery.  I think this eliminates most of
the danger.

> Obviously there is a lot of demand for "update" functionality in
> XQuery, but this demand is I think primarily for people wanting
> "XML databases", which is not I think where Qexo's current strengths
> lie.  I don't want to discourage you, and I'd love to see experiements
> with updates, but "production-strength" updating is a hard problem.
> But maybe we can make something useful even if updates are not initially
> "production-strength."
I really don't know why so many people confuse XML with databases.  Sure
there are some similarities.  Relational DBs won over tree formats along
time ago.  Calling XML a DB is like calling the STL a DB.  Sure the STL
data structures can be view as databases.  To me XML is more useful as
a standardized data structure serialization.  Software uses
data-structures
all the time with out thinking about it in terms of a DB.

Also, I think XQuery should not be a XML DB language even if
that was its first intention.  There is a need for a general XML
manipulation
language and XQuery is the best thing out there right now.  The main
reason being that in XQuery you can define functions and XSLT you cannot.
 FLOWR
expressions are the weakest part of XQuery.  You could do the same thing
with more flexibility if you had standalone 'let' and 'foreach'
expressions.  There is no need for 'where' because XPath can filter data
already.  'sortby' could be implemented as a function.  And as far as
'return' goes I'm find with some expressions having NULL value.  SQL is
a find DB language.  Why can't I just say 'let x := <expr>' on its own. 
All
you need is a scoping mechanism.

One way to solve (3) is to attach event listeners to XML Nodes that are
in a DB.
Events are part of the DOM 2.0 spec.  I have implemented this before. 
These
event could be used to keep the DB in sync transparently.

Ok, now that I'm finished ranting.  I would be perfectly happy with just
(2).


Joseph
-- 
  Joseph Coffland
  address@hidden