[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: "OO" Schemas (with examples!)
matt@v... wrote: > > The exceptions, like C++'s private inheritance, are at > the margins. In what language that you are aware of does inheritance > or subclassing not imply substitutability? I've been thinking a little further: I think that it is good to allow inheritance (attribute and content model sharing) without substitutability (the ability to plug elements of one type in for elements of another). But since inheritance is always a labour saving device, I can just avoid it when I don't want substitutability. This will encourage bad design in some cases (as it does in Java), but that's okay, we could add "private inheritance" later, as you could in Java. To make this concrete, consider these statements: <!ELEMENT A (EMPTY)> <!ATTLIST A ATTR CDATA #IMPLIED> <!ELEMENT B INHERITS-FROM A> <!ELEMENT C (A)> Questions: Inheritance: Does B have an ATTR attribute? Substitutability: Can a C contain a B? The answer to the former is probably "true" in a reasonable inheritance system for XML types. B got a property (the existance of an attribute) "for free" from A. This is a nice feature that eases maintenance and reduces code duplication. The answer to the latter is more complicated. If you say yes, then you are saying that inheritance implies substittuability, like Java, but unlike C++, Smalltalk, etc. If you say no, then you are saying that inheritance and substitutability are two different features and are more or less unrelated, except that they often work together. I am saying that I prefer the second answer, but if the first answer wins out then I can just avoid inheritance when I don't mean to imply substitutability, and just declare the attributes twice. Similarly, in Java I can build proxies to implement code reuse without inheritance. I can live with that. The really important thing is that substitutability should not require inheritance. Note that Java (C++, Smalltalk, etc.) do not make this mistake. In Java, substitutability can be defined with interfaces so that no particular implementation is required or implied. This is just as important for documents. We are very, very close to having a clear language for describing substitutability, but we must not get distracted by the (comparatively unimportant) issue of inheritance. Let's forget about inheritance for a second, get substitutability right, and we can go back and fiddle with code saving devices later! We must especially not confuse the two! Consider, for example, an element that wants to be substitutable for an HTML A element. Perhaps it is a special hypertext bibliography element that gets its URL from a child element named URL: <BIBLIO> <ISBN>...</ISBN> <PUBLISHER>...<PUBLISHER> <URL>http://....</URL> </BIBLIO> We can easily translate this to an A HREF element using XSL's transformation language: <A href="{URL}"> <B><xsl:process select="ISBN"/></B> <I><xsl:process select="PUBLISHER"/></I> </A> Thus, this: <BIBLIO> <ISBN>XXXXXX</ISBN> <PUBLISHER>Prentice Hall<PUBLISHER> <URL>http://....</URL> </BIBLIO> would become: <A href="http://...."> <B>XXXX</B> <I>Prentice Hall</I> </A> The implications of this for e-commerce and document interchange are be clear. You can define these "substituability mappings" into schemas created by other people, and just "plug in" elements named according to your own vocabulary. You can even use a schema to verify that anything that conforms to your vocabulary will come out of this mapping conforming to the containing application's schema. But note that I've done no "inheriting" here. My BIBLIO type got no property from the A type. In fact, it may have been invented completely independently. I can "impose" substitutability on a type from outside, just as I can in an OO language with a "proxy." The XSL rule is my proxy. I fear that these important features will get lost in the rush to "inheritance". So what I ask is that you recognize that a) substitutability without inheritance is at least as important as in in Java, b) as long as you are going to provide that, you might as well provide inheritance without substituatability and c) we need advanced kinds of substitutability such as the one described above. Paul Prescod - http://itrc.uwaterloo.ca/~papresco It's such a Bore Being always Poor LANGSTON HUGHES http://www.northshore.net/homepages/hope/engHughes.html 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
|