Restricting a type by using an attribute on the element using the type?

[Arndt Jonasson]

This is a modelling style question, I think.

I am working with a somewhat XML Schema-like formalism which defines
the structure of an instance document, supplying a number of built-in
types (a very light-weight Schema).

One of the built-in types is called "ref", and its defined values are
location paths to other elements in the instance document.

An example:

<spec xmlns:types="urn:example:mytypes.1">
<e name="top">
<e name="a" type="types:int" minOccurs="0"/>
<e name="elts">
<e name="e1" type="types:int"/>
<e name="e2" type="types:string"/>
<e name="e3" type="types:ref"/>
</e>
</e>
</spec>

This is a valid instance of the above:

<top>
<a>3</a>
<elts>
<e1>1</e1>
<e2>earth</e2>
<e3>/top/a</e3>
</elts>
</top>

My question deals with how best to specify additional parameters of
the
"ref" type. One thing I'd like to be able to say is "the element
pointed
to by the location path must actually exist", respectively "does not
have to exist" (elements can be created and destroyed in runtime).

This can be expressed with an attribute to the <e/element:

<e name="e3" type="types:ref" must_exist="true"/>

My question is: is this a proper way of doing it? It seems slightly
peculiar to supply the general </eelement with an attribute which
will only be valid for one particular value of another attribute.

(Of course I can make a "types:ref_must_exists" type, but there will
be more complicated ways to restrict the type.)

[Boris Kolpackov]

Hi Arndt,

"Arndt Jonasson" <ar************@gmail.comwrites:

My question deals with how best to specify additional parameters of
the
"ref" type. One thing I'd like to be able to say is "the element
pointed
to by the location path must actually exist", respectively "does not
have to exist" (elements can be created and destroyed in runtime).

This can be expressed with an attribute to the <e/element:

<e name="e3" type="types:ref" must_exist="true"/>

My question is: is this a proper way of doing it? It seems slightly
peculiar to supply the general </eelement with an attribute which
will only be valid for one particular value of another attribute.

(Of course I can make a "types:ref_must_exists" type, but there will
be more complicated ways to restrict the type.)

Your must_exist attribute is changing the ref type, not the element
so it naturally belongs to the type definition. XML Schema does this
by allowing you to create a new type that restrict the original. In
your case it could look like so:
<t name="my_t">
<r base="types:ref" must_exist="true"/>
</t>

<e name="e3" type="my_t"/>

You could have several attributes/elements like must_exist that
change different aspects of different types.
hth,
-boris

--
Boris Kolpackov
Code Synthesis Tools CC
http://www.codesynthesis.com
Open-Source, Cross-Platform C++ XML Data Binding

[Arndt Jonasson]

On Feb 9, 6:04 pm, Boris Kolpackov <[e-mail]:

Hi Arndt,

"Arndt Jonasson" <[e-mail]:

My question deals with how best to specify additional parameters of
the
"ref" type. One thing I'd like to be able to say is "the element
pointed
to by the location path must actually exist", respectively "does not
have to exist" (elements can be created and destroyed in runtime).

This can be expressed with an attribute to the <e/element:

<e name="e3" type="types:ref" must_exist="true"/>

My question is: is this a proper way of doing it? It seems slightly
peculiar to supply the general </eelement with an attribute which
will only be valid for one particular value of another attribute.

(Of course I can make a "types:ref_must_exists" type, but there will
be more complicated ways to restrict the type.)

Your must_exist attribute is changing the ref type, not the element
so it naturally belongs to the type definition. XML Schema does this
by allowing you to create a new type that restrict the original. In
your case it could look like so:

<t name="my_t">
<r base="types:ref" must_exist="true"/>
</t>

<e name="e3" type="my_t"/>

You could have several attributes/elements like must_exist that
change different aspects of different types.

Creating a subtype feels conceptually cleaner, but since this is text
that humans are supposed to write, I think the users may feel that it
gets unnecessarily cluttered with having to create subtypes which
are only used once.

Thank you for your answer.