Sign in to follow this  
Sneftel

Abstract prototypes in XML (with XML Schema)

Recommended Posts

Sneftel    1788
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 this post


Link to post
Share on other sites
mrcriminy    100
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 this post


Link to post
Share on other sites
Sneftel    1788
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 this post


Link to post
Share on other sites
ToohrVyk    1596
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 this post


Link to post
Share on other sites
Sneftel    1788
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 this post


Link to post
Share on other sites
SiCrane    11839
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 this post


Link to post
Share on other sites
psamty10    148
Quote:
Original post by mrcriminy
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.


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 this post


Link to post
Share on other sites
Sneftel    1788
Quote:
Original post by SiCrane
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.

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 this post


Link to post
Share on other sites
psamty10    148
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>


Share this post


Link to post
Share on other sites
Sneftel    1788
When it comes to inheritance, XSD apparently punts. Its own schema doesn't have anything special to ensure well-formedness: one can make an XSD which validates but leaves out required tags (because you might be pulling them in from a base type). <complexType>, for instance, need not have any child content to validate.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this