# Abstract prototypes in XML (with XML Schema)

This topic is 3560 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Let's say I'm defining a collection of shapes, and I want three blue boxes next to each other.
<shapes>
<box>
<color id="blue"/>
<pos x="0" y="0"/>
</box>
<box>
<color id="blue"/>
<pos x="1" y="0"/>
</box>
<box>
<color id="blue"/>
<pos x="2" y="0"/>
</box>
</shapes>


In my schema, I specify that the color and pos elements must be present in each box. So that's fine. Now let's say that I decide that I'm sick of specifying "blue" for each one. So I take a clue from prototype-based programming and do this:
<shapes>
<box name="bluebox" abstract="true">
<color id="blue"/>
</box>
<box inherits="bluebox">
<pos x="0" y="0"/>
</box>
<box inherits="bluebox">
<pos x="1" y="0"/>
</box>
<box inherits="bluebox">>
<pos x="2" y="0"/>
</box>
</shapes>


In this situation, I'm doing a few things: (1) I'm adding the ability to name boxes; (2) I'm adding the ability to make them abstract (in which case they don't need to declare all the required child tags); (3) I'm adding inheritance, allowing one definition to refer to another definition, inheriting (then perhaps overriding) its properties. Which is fine on the XML instance side. But on the schema side, my XSD has just gone from elegant ten-line happiness to one of two things: Ten lines of definition which no longer validate for any of my well-formedness rules, or fifty lines of terrifying ugliness which maybe validate a handful of them. Likewise, now my loading code has to do all sorts of extra reference fixup. It's not pretty. What I'd really, really like is some XML extension which allowed me to simply say "yeah, I'm allowing inheritance here" and still be able to use a nice-looking schema and maybe even get convenient loading. Does such a thing exist?

##### Share on other sites
It looks as if you are trying to fit an object oriented design into XML, which can't result in a pretty/easy validating XSD.

I would suggest something more similar to CSS, where your visual stylings aren't decided by your XML schema, and an attribute like color is specified by style rather than by entity.

In fact, both color and position are attributes of a box, and not structural entities within that box. Having pos and color entities complicates the integrity of your information and you run into issues with extending your XSD.

<style id="bluething">   <attribute name="color" value="blue"/></style><shapes>   <box style="bluething" pos="x,y"/>      <!-- uses a style defined elsewhere -->   <box pos="x,y"/>      <!-- uses default coloring -->   <box color="blue"/>      <!-- uses default positioning --></shapes>

##### Share on other sites
I'm not sure what you mean by "object oriented". "Inheritance" is a key word often associated with OO, but the sort of inheritance here is merely defaulted values.

I'm also not sure why you feel that making pos and color child elements, as opposed to attributes, complicates the integrity of the information. The schema is pretty simple:
<xs:element name="box">  <xs:complexType>    <xs:sequence>      <xs:element name="color" type="ColorType"/>      <xs:element name="pos" type="Vector3"/>    </xs:sequence>  </xs:complexType></xs:element>

Did you mean that it would be complicated in the situation with inheritance? In that case, I agree... that's sort of the crux of the problem.

I suppose I could just shoehorn everything into key/value "attribute" pairs like you've shown, but that would obviate a lot of the natural benefits of a structured representation like XML, and compromise data integrity (because I would be forced to allow defaults for each value, even where that did not make sense).

##### Share on other sites
I would probably reverse the relationship.

<shapes>  <color id="blue">    <pos x="0" y="0">      <box/>    </pos>    <pos x="1" y="0">      <box/>    </pos>    <pos x="2" y="0">      <box/>    </pos>  </color></shapes>

The schema would allow shapes/color/pos/box and shapes/pos/color/box paths.

##### Share on other sites
Huh, that's a really interesting approach. I really like the elegance of the inversion. I dunno about it for organization, though. In this situation, boxes may only be placed in the nest of their inherited-from "parent" (implicitly defined as a set of tags, of course). It's fine for the case of only two attributes, of course, but in a situation of declaring game entities, with dozens of attributes and hundreds of prototypes and non-abstract entities, it might get a little nightmarish. Also, I'm not sure how to use XML Schema to ensure that there's "at least one" color parent to each box, if box can appear as a child of color or pos.

##### Share on other sites
It occurs to me that XML Schema itself is an XML format that contains inheritance like the type you want to express. If you could find a XSD file for XSD files, you could see how that's expressed in XML Schema. However, I'm not aware of any such entity, so I'm not sure how useful this thought is.

##### Share on other sites
Quote:
 Original post by mrcriminyIt looks as if you are trying to fit an object oriented design into XML, which can't result in a pretty/easy validating XSD.

XML does OO design just fine (example below):
 <xsd:element name="Superclass">    <xsd:complexType>      <xsd:sequence>       ....      </xsd:sequence>    </xsd:complexType>  </xsd:element> <xsd:element name="Subclass">  <xsd:complexContent>      <xsd:extension base="com:Proper">        <xsd:sequence>        ....        </xsd:sequence>      </xsd:extension>  </xsd:complexContent> </ xsd:element>

What it doesn't do well is allow you to be terse. Verbosity is its middle name. I would suggest an authoring tool to do this bit.

##### Share on other sites
Quote:
 Original post by SiCraneIt occurs to me that XML Schema itself is an XML format that contains inheritance like the type you want to express. If you could find a XSD file for XSD files, you could see how that's expressed in XML Schema. However, I'm not aware of any such entity, so I'm not sure how useful this thought is.

Good point. I'll interrogate their XSD to see what's going on there.

I did have some wacky thoughts about using XSLT to transform a schema that doesn't support inheritance into one that does. I think that might be a bit too meta for a mere mortal such as myself, but hmmmm...

##### Share on other sites
You could have an element that contains a reference to an instance of itself.

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"            targetNamespace="http://xml.netbeans.org/schema/test"            xmlns:tns="http://xml.netbeans.org/schema/test"            elementFormDefault="qualified">    <xsd:complexType name="box">        <xsd:sequence>            <xsd:element name="prototype" type="tns:box"></xsd:element>            <xsd:element name="color" type="Color"/>            <xsd:element name="position" type="Point"/>        </xsd:sequence>    </xsd:complexType></xsd:schema>