Inheritance in XML

[Paul Prescod]

Matthew Gertner wrote:
> 
> Paul,
> 
> Let me try to explain at least what I am envisioning as far as the putative
> inheritance mechanism which I described is concerned. I am going to get
> myself into trouble by saying this, but SGML was an attempt to avoid doing
> 5% of what is necessary (i.e. to do everything), and this led 10 years down
> the line to the creation of XML. 

XML is supposed to do the most common 80% of what SGML does, not 5%,
fairly randomly chosen. 

> A very uncharitable view (which I would certainly not endorse :-) would be
> to say that you are setting the bar very high, and then rejecting ideas
> which at least one person in this list thinks would be of great value
> because they don't reach the level of functionality that you are imposing.

In my mind, I'm setting the bar at "solving a significant proportion of
problems of the same type." Adding 5% solutions incrementally is
*exactly* how we get back to where SGML is today. Many of SGML's less
used features seemed like they would be really useful, but turned out
not to be general enough to solve the problems people thought that they
would solve. XML should be the resting place of features that are well
understood and that everybody uses or that it is obvious that everyone
*will* use, because they solve so many problems at once that they can't
fail to be useful.
 
> It seems to me that your objection to this boils down to the fact that you
> also want to subtype without inheritance. 

And occasionally inherit without subtyping. 

> It's a hard, hard problem. On the other hand, C++ has gotten away with
> providing subtyping only through inheritance (you mentioned that it can but
> I can't figure out how - please enlighten), and it's still a pretty useful
> little language.

C++ provides subtyping without inheritance through abstract base classes
and pure virtual methods. I prefer Java's syntactically distinct
interfaces feature, but the C++ way works.
 
> What I was implying in my example about CML were 3 things: 1) The processor
> has access to the base DTD. 2) The processor has access to the derived DTD.
> 3) The processor knows about the inheritance (which is also a subtyping :-)
> mechanism being used. This would enable it to get at the content of the base
> element type without knowing what to do with the content of the derived
> element type. 

I wouldn't quite say that. The processor must know what to do with the
new nodes. It must either know to ignore the "extra" content of the
derived element type, or it must know to ignore the tags and process the
content, or halt and catch fire, or do something else. You are arguing
that it should always use the "ignore content" model, but we know from
HTML that this is often not appropriate.

> All I want is to be
> able to do is scoot over to the DTD repository site, check for a standard
> DTD for invoices, grab it, extend it with the two or three extra attributes
> and/or contained element types that I need and use it, while still being
> able to use any tools that are designed to work with the original invoice
> DTD. I truly believe that this is where XML will really start to fulfill its
> promise.

My assertion is that even in a document as simple as an invoice you are
going to come up against the limitations of this feature. The base DTD
will have a content model like:

(PARTNAME,PRICE)+

and you will need to change that to:

(DATE,DESCRIPTION,HOURS,AMOUNT)+

because that is how you do invoicing at your company. 

I assert that this sort of case is much more common than the simple case
where all you want to do is prefix or suffix an element and have that
content be ignored. This is especially the case when we move away from
invoices and into more flexible document types.

 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)