Paul,

You are a getting at precisely the intuition that stands behind SOX.

When we started on SOX, our immediate goal was getting from XML to
application with as little programming time as possible.  I looked at
using a "DTD in instance syntax" simply because it was easier to
manipulate programmatically than a DTD.  

The first version I was handed was a 1-1 mapping from DTD constructs
to content models, and I rapidly realized it was hopeless because the
only mechanism for abstraction was Parameter Entities, and you could
(almost) never tell from the declaration what it was used for.  

So I declared that PEs had to go, and we created a second version
where, for each (reasonable) use of PEs there was an abstraction in
the Schema language.  From this I could actually start to generate
code.  

But it immediately became obvious that this code was almost useless
because my abstraction mechanism was still in the domain of XML, which
was of very little interest to the application programmer (at least in
terms of his job).

Fortunately my boss was a CORBA demigod from Sun and we argued
abstractions back and forth incessantly, and I finally realized what I
really needed was to be able to express domain level abstractions, a`
la objects.  Once I had that, it was a tight iteration to produce code
people would actually use.

I encapsulated this realization with the following analogy:

XML is to SGML as Basic is to PL/I, not as Java is to C++ (i.e., if
you take a big, complicated, unstructured thing and simplify it, you
still end up with an unstructured thing).

Matthew Fuchs
matt@veosystems.com (still)
now part of CommerceOne (gotta get a new sig)

Paul Prescod wrote:
> 
> "Borden, Jonathan" wrote:
> > 
> > > You are interacting with data through an interface that was designed to
> > > provide access to the abstract data model of a *serialization*. 
> 
> >         Really !? and I thought I was interacting with an interface designed to
> > represent the abstract data model of XML. 
> 
> Right. XML is a serialization. The DOM is an abstraction of a
> serialization. Not an abstraction over your data. If your "problem" is
> representing debit card bank accounts the proper abstraction over that is
> "bank account" or "currency account". The *wrong* abstraction is "elements
> and attributes."

...

> >         I'm not sure that the data is so much more complex than can be represented
> > by the DOM interfaces. 
> 
> XML is very simple. "All the world's data" is very complex. That's why we
> need XLink, RDF, HyTime and a bunch of other stuff. If your API to "your
> data" is simply the DOM then you are temporarily hiding its complexity
> behind a simple layer that can *NOT* express its "linkedness", its complex
> class relationships, is geographical 2D-ness etc. I don't know your data.
> I don't know what makes it complex but if your job is interesting it IS
> complex and the DOM does not help you to manage that complexity. We have
> 20 years of software engineering that DOES help us to manage that
> complexity and its most recurring message is "abstraction, abstraction,
> abstraction." Dumbing data down to a DOM is the opposite.
> 
> 
....
> >         Really? And what is a more intelligent abstract data model? 
> 
> Object orientation.
> 


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)