RE: Namespaces, W3C XML Schema (was Re: ANN: SAX Filters forNamespaceProcessing)

["Fuchs, Matthew" <matthew.fuchs@commerceone.com>]

Facilitating the mapping from XML into OO languages was a major reason for
the inclusion of OO features (there was also the proven utility of these
concepts in domain modeling over the last 30+ years).  I'm glad to see
products like Castor or the XML-Schema Toolkit that indicate we did a
reasonable job.

The problem I found DOM views of XML was that they were too atomic.  In a
programming language (PL) I can address each sibling in a datastructure by
its unique name, while with DOM I need to do strange tree traversals.  And
the DOM is going to be much larger in memory footprint than equivalent
classes.  Also, in a PL inserts and updates are controlled by the type
system, and where there is strong typing, I can't even write the code to do
an invalid insert - it won't compile.  And so on.  So the typical PL view of
the data had many advantages.  That being said, there is no reason one can't
layer that kind of view of a document over the DOM, so one accesses the DOM
through interfaces that behave in the expected way (from a Java/C++
perspective) but maintain a DOM underneath.  Alex Milowski actually
suggested something along these lines a long time ago in the early days of
SOX.

And there's also no problem with allowing a strongly typed XPath view of
these trees - and extending it to be a generic means of accessing Java
Beans.  That gives you "the document is the data", but the language is still
Java/C++/C#/whatever.

Matthew

> -----Original Message-----
> From: Nicolas LEHUEN [mailto:nicolas.lehuen@ubicco.com]
> Sent: Wednesday, August 22, 2001 2:20 PM
> To: 'Michael Brennan '; ''Elliotte Rusty Harold' '; 'Xml-Dev '
> Subject: RE: Namespaces, W3C XML Schema (was Re: ANN: SAX Filters
> forNames paceProcessing)
> 
> 
> As I've seen during JavaOne 2001, people a fond of data 
> binding because it
> solves a very basic problem : you can't safely write business 
> processes
> involving business logic that directly manipulates XML 
> document with the
> current Java, C or C++ APIs. So, when you get an XML document 
> representing
> business data, it's better to bind it to an object model, 
> process the object
> model, then serialize the result back to XML.
> 
> Give people a schema language that enables them to define XML 
> datatypes as
> easily as they used to define C structs or Java or C++ classes, and a
> language in which you can easily use XPath expression as 
> rvalues or lvalues,
> while being constrained by the schema, and voilą - no more binding is
> required. The document *IS* the data.
> 
> -----Message d'origine-----
> De: Michael Brennan
> A: 'Elliotte Rusty Harold'; Xml-Dev
> Date: 22/08/01 22:42
> Objet: RE: Namespaces, W3C XML Schema (was Re: ANN: SAX Filters
> forNamespaceProcessing)
> 
> > From: Elliotte Rusty Harold [mailto:elharo@metalab.unc.edu]
> 
> <snip/>
> 
> > And witness all the people using these products NOT. I 
> > classify this stuff along with tree-based XML editors and 
> > binary variants of XML as something that gets reinvented 
> > several times a month without any actual market demand. 
> 
> I don't think I'd agree that there is no market demand for 
> data-binding
> tools. I think the complexity of XML Schema -- and the consequent
> complexity
> of tools that rely upon it -- is inhibiting more widespread adoption.
> 
> > On the other hand, over the last three years as I've taught 
> > developers about DTDs, almost invariably the first question 
> > is "How do I say that an element contains an int?" and the 
> > second question is usually ""How do I say that an element 
> > contains a year since 1969?" or some variant thereof. 
> 
> In other words, people want data-binding, but they want it to 
> be simple.
> 
> And it's really not clear to me why a language intended to 
> just support
> XML
> validation needs to layer such concepts as types and 
> inheritance on top
> of
> XML -- unless it is really intended to support data-binding.
> 
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
> 
> The list archives are at http://lists.xml.org/archives/xml-dev/
> 
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.xml.org/ob/adm.pl>
> 
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
> 
> The list archives are at http://lists.xml.org/archives/xml-dev/
> 
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.xml.org/ob/adm.pl>
>