[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Inheritance in XML

  • From: matthew@p... (Matthew Gertner)
  • To: <xml-dev@i...>
  • Date: Tue, 21 Apr 1998 09:48:12 +0200

invoice inheritance

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

>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:
>and you will need to change that to:
>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.



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


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.

Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.