Inheritance in XML

[Matthew Gertner]

Paul,

Thanks for your reply. I guess by now we have both thoroughly digested each
other's point of view. I'll just make a couple of additional comments:

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

5% was your figure...

>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.

This is fair enough. In the end it all boils down to how useful you think a
given mechanism will be, since hindsight will only be available down the
road. So we move from a technical to a quasi-religious type of discussion.

>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.

ABCs can have public class members... Anyway, the Java approach is certainly
better.

>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.

This is where the whole discussion started. In OO programming, you have to
design your derived classes so as not to break the base class's behavior.

>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.

Okay, I don't agree at all with this assertion, but as I said earlier, it
all boils down to a judgement call.

Cheers,

Matthew



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)