Re: Inheritance in XML
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@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...)
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format