[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: XML updates

I will try and batch up some comments, 
without too much old context . . .. 

> Lars: 
> There are a lot of papers about goals and requirements of an XML
> query language (e.g. http://www.w3.org./TR/xmlquery-req) and all
> of these papers say nothing about updates.

! That last sentence definitely deserves a !
It is extremely strange that all the specification effort
has gone into read-only queries, and none into updates
(except for actual implementations which have to provide something).
e.g. I went through the XQL spec, only to find page after page of 
primordial XPath syntax, but no mention of updates !

> Lars:
> This is highly comparable to the XUL (XML Update Language) specification
> defined by IBM and used in their XMLTreeDiff application. Is this spec
> still in use?

XUL is a bad choice of acronym, vs. the Mozilla UI language
(but maybe IBM were first ?). Don't know about TreeDiff status,
it's hard to tell what plans IBM has for anything on the alphaWorks site.

> > Mike:
> > It should be possible to devise a mapping from HTML forms 
> > to this fragment update syntax, similar to Donald Ball's
> > XMLForm:
> >
> >	http://www.webslingerz.com/balld/xmlform/README

> David:
> I took a look at it a few weeks ago, but I got the idea that the 
> project has been dropped?

> Lars:
> In the Cocoon-List are still messages about this project - so I don't
> that the XForm Project has been dropped.

There's an implementation, and I suppose Donald is using it at
Webslingerz (with a company name like that maybe he should have
called the project XMLFormz - to avoid confusion with so many other
XML form-based specifications). Also Jeremy Quinn has posted to the
Cocoon list with some follow-on requirements and proposals for form 

The good thing about specifying an XML format for the update,
is that it can be driven from an XML-aware client application,
which uses XML messages (i.e. HTTP with a text/xml message body)
a no-op servlet producer (see Cocoon ProducerFromRequest),
a 'standard' XML db query processor, and a return XML message 
with the result of the query, status info, or an exception
(similar to XML-RPC or SOAP).

Or there can be a binding to HTML form posts (a la XMLFormz),
for use with a conventional browser, with a de-mangling producer 
on the front-end of the servlet, the same XML db processor,
and an extra post-processor (probably XSL) to convert the 
query response into a valid HTML page for the browser.
The form would add some extra parameters to the query,
which are passed through the db processor, 
and used as arguments to the post-processor.

The only thing I'm not sure of, is how to leverage WebDAV.
It seems that in the long run (when all the browsers and 
servers are DAV-aware), any XML content system should use WebDAV ??
Maybe that's just an issue for some future metaphysics.

> > David:
> > Do you have an outline for infozone?
> Lars:
> In one sentence: XML Content Management System based on ozoneXML for the
> persistency layer and Cocoon for the (Web) publishing layer.

Sounds like perfect match. After surfing many possible technologies
and products, we have converged on a similar requirement.

> I hope that we come out with a web site or this project in the next few
> There you will find a lot of documentation, source packages and binaries.

Sounds good, I look forward to seeing it.