Re: XML schema for representing objects (inheritance et al)

Hello Ishmael,

> I want constant static data members so that every instance of an
> object will have some basic information about that type of object.
> For exampe, like objects, each object _type_ has a UUID associated
> with it. Given some object in the XML file, I'd like to be able to
> find out what the UUID of its type is. I don't want to have this
> information cluttering the instance document. I've done this using
> "default" attributes. This is not ideal because the XML instance
> document must not be able to change this information - it's the same
> across every instance of an object.

Then I think that you want to use "fixed" rather than "default". A
"fixed" attribute (or element) value means that if the attribute
appears, it *must* have that particular value -- the instance is not
allowed to change it. Try, for example:

<xs:complexType name="t_Person-mid">
  <xs:complexContent>
    <xs:restriction base="_Object">
      <xs:sequence>
        <xs:element name="SomeField" type="xs:string"  maxOccurs="unbounded" />
      </xs:sequence>
      <xs:attribute name="my_UUID" type="xs:string" use="required" />
      <xs:attribute name="myType_UUID" type="xs:string"
                    fixed="4584bf3d-8ccc-4061-aa8a-7d98c4009b8a" />
    </xs:restriction>
  </xs:complexContent>
</xs:complexType>

> 1. Because I have to restrict the myType_UUID fields (so that they
>    are some particular value) I have to do a restriction "pass" in
>    addition to the extension one.  In the restriction, I have to
>    list _every_ field, even those I don't need to mess with.  (You
>    can imagine how bad this will get if objects need many fields,
>    and for my project, they most definitely will.)  Why even atempt
>    an OO solution if I have to do this?

Yes. It's a common observation that restrictions are hard to deal
with; I think that either you want to capture the relationships
between your complex types, such that having a type hierarchy is
important to you and you then have to be prepared to pay the cost of
that, or you don't actually care about the relationship in which case
there's no point using the OO features of XML Schema. It's up to you.

That said, you might find it easier to manage if you use named model
groups to hold those fields that you don't want to mess with. That way
they are only declared once, and any changes you make to the model
group will ripple through all the types.

I believe that the XML Schema WG is soliciting suggestions about how
to do restriction in a more elegant way in XML Schema 1.1. Perhaps if
you have some ideas you should send them to the comments list
www-xml-schema-comments@w3.org.

> 2. This is also a problem, because for some fields, I may want to
>    indicate a field's default or fixed value, that will remain that
>    field's default or fixed value, even if the class is inherited.
>    I then want an inheriting class to be able to re-define it to
>    optional, fixed, default - whatever it wants.

The only way you can redefine existing "fields" (attributes or
elements) is by restricting them, and when you restrict them you must
make them narrower -- everything that is valid against the restricted
type must be valid against the base type. So you can't take a required
"field" and make it optional, for example. Nor can you change the
value of a fixed "field". But you can make an optional "field"
required, and make a default value fixed. Perhaps if you gave an
example of what you wanted to do and why you can't do it we could find
some way around it.

> 2. As I said before, I have to use "default" values for those
>    UUIDs.  I'd prefer to use "fixed" (so they can't be changed in
>    an instance document,) but I get all kinds of errors when I
>    try to change it to fixed.

Oh. Without knowing what those errors are it's kinda difficult to know
what to suggest.

> 3. I'd like to define myType_UUID in "_Object" as "required", so that
>    an error is generated if any sub-classes don't define it.  But
>    then I get into problems when I change it from required to
>    "default."

I think what you're saying is that you want to get an error if you
don't override the inherited definition of the myType_UUID attribute
in derived types. This isn't the same as making the myType_UUID
attribute required -- a required attribute is one that has to appear
in the instance (and if it has to appear in the instance, then there's
no point specifying a default value, because defaults only come into
play when the attribute is missing). There is no way of forcing
particular attribute definitions to be overridden within the schema,
I'm afraid.

Cheers,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/

Received on Tuesday, 23 July 2002 05:07:34 UTC