Inheritance in XML (was Re: Problems parsing XML)

[Paul Prescod]

Jeff Larson wrote:
> 
> Excel was perhaps a bad example, but in general I disagree because the DTD
> isn't enough to capture all of the various integrity constraints that may
> exist between elements representing components of a data structure.  It
> may be possible to represent some of these constraints through content
> models, but certainly not all of them.

That's right. That's why you also need more application-specific
schemata. That's also why you need documentation, just as you do for an
API.
 
> If the schema was all you needed, then there wouldn't be much point
> to the OO concept of the "setter" method.  You would just make all of
> your data members public, and tell everyone not to break the rules, however
> complicated those may be.  

The issues are not analogous. First, Java and C++ do not have a concept
of schema. Second, setter methods must control not just what a data
object's state is before and after a transaction, but also the steps
allowed to get from here to there. Schemata can only constrain
documents, not processes. Setter methods can say that you can only set
foo after you've set bar and so forth.

> Certainly there will be a few important and widely used data models around,

No, there will be *many* important and widely used data models around.
That is why XML is so exciting. Look at http://www.w3.org/TR . There are
new ones every week.

> especially for the representation of documents, and XML is perfect for this.
> The semantics of the data model will be well understood, enabling anyone
> with enough time on their hands to write dozens of tools that operate reliably
> upon the data.  To me though, this is still an API, my application isn't
> parsing the file, its poking at it through the "tool" which is where the
> semantics have been encapsulated.  

I don't understand this point. If I use Python's "print" statement to
directly write a CDF file or FrameMaker document, how am I going through
an API?

> However, lets say I'm the vendor of some relatively esoteric thing, and I
> need to design a file format to capture the state of my application.  Do
> I use XML?  Sure why not, but do I really gain anything from this?  The
> hackers with time on their hands are busy writing tools to edit RTF and
> DOOM levels, they don't care about my nuclear power plant application.
> Even if someone did decide to write a nifty utility that operates on my
> files, if they get it wrong, then Cleveland starts glowing, so I probably
> don't want their help anyway.

Most of us don't write nuclear plant software, and I don't think that
nuclear plant software is designed to be "third-party extensible" either
through APIs or data formats. 

If we're talking about replacing data formats, then we should talk about
the most popular data formats: 

 * Word docs/Excel spreadsheets (binary, hard to work with, hard to
parse), 
 * HTML (underpowered, inflexible), 
 * configuration files (different on every platform, too often ad hoc), 
 * page description languages (hard to validate, poorly specified)

And even formats that cannot realistically be replaced by XML can be
enhanced by it;

 * source code (literate structured programming)
 * zip files (XML manifests, directories, etc.)

> I'm not against XML, I think its a great thing, and we should encourage
> the vendors of major applications to support it, along with the copious
> DTD documentation that will be necessary to do anything useful with it.
> However, I think the notion that just storing my application data in
> XML will automatically make it more useful to the world is a bit presumptuous.

I think you are attacking a straw person. Certainly nobody knowledgable
would claim that XML automatically improves anything. Like every
technology it must be applied to the right set of problems.

On average, though, storing data in XML rather than whatever you would
have invented ad hoc will make that data easier to work with. It's
analogous to the situation of Unicode/UTF-8 giving people a character
encoding to build on rather than having them invent their own. Sometimes
it will still make sense to invent your own character or data encoding.
But more often, it will be easier for everybody to just use the
standard.

 Paul Prescod  - http://itrc.uwaterloo.ca/~papresco

"Journalism is good if you follow the rules. Don't allow the human 
rights groups to spoil your profession" 
    - Col. Godwin Ugbo of the  Nigerian military dictatorship

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)