Re: Dependencies between attributes and elements

On 7 Aug 2007, at 04:07 , Joćo Cruz Morais wrote:

>
> Thanks for your answer Michael, I think I'll deal with the document
> structure with XSD and do the remaining validation in my java app.
> One more thing though:
>
> Right now I'm using an element called int-vector to specify a list of
> int values. Is it possible to make that element go away and replace it
> for a generic one, with an attribute specifying the vector type? In
> other words is it possible to establish a relationship between the
> value of an element attribute and his children?
> Example:
>
> <vector type="int">
>   <value>2</value> <!-- if not int throws a error -->
> </vector>

If you mean "in 1.0", then the answers already given by
Andy Den Tandt and Michael Kay are on the mark.

If you mean "in 1.1, will I be able to ...", then the answer is
no, yes (at the cost of a little indirection), and maybe.

No, in the sense that there is no mechanism in 1.1 (any more than
in 1.0) that allows you to declare a 'vector' element with a magic
'type' attribute such that each 'value' element appearing as a child
of 'vector' will be typed using whatever type is named in the 'type'
attribute.

Yes, in the sense that in 1.1 you should be able to write a set
of type declarations like these:

  <complexType name="anySimpleType_vector">
   <sequence minOccurs="0" maxOccurs="unbounded">
    <element name="value" type="anySimpleType"/>
   </sequence>
   <attribute name="type" type="NMTOKEN"/>
</complexType>
<complexType name="int_vector">
   <sequence minOccurs="0" maxOccurs="unbounded">
    <element name="value" type="int"/>
   </sequence>
   <attribute name="type" type="NMTOKEN"/>
</complexType>
<complexType name="dec_vector">
   <sequence minOccurs="0" maxOccurs="unbounded">
    <element name="value" type="decimal"/>
   </sequence>
   <attribute name="type" type="NMTOKEN"/>
</complexType>
<complexType name="date_vector">
   <sequence minOccurs="0" maxOccurs="unbounded">
    <element name="value" type="date"/>
   </sequence>
   <attribute name="type" type="NMTOKEN"/>
</complexType>
<complexType name="NMTOKEN_vector">
   <sequence minOccurs="0" maxOccurs="unbounded">
    <element name="value" type="NMTOKEN"/>
   </sequence>
   <attribute name="type" type="NMTOKEN"/>
</complexType>
<!--* ... etc., one vector type for each type of vector *-->

and then declare the 'vector' element using conditional
type assignment depending on the value of its 'type'
attribute.

<element name="vector" type="tns:anySimpleType_vector">
   <alternative test="@type='int'" type="tns:int_vector"/>
   <alternative test="@type='dec'" type="tns:dec_vector"/>
   <alternative test="@type='date'" type="tns:date_vector"/>
   <alternative test="@type='NMTOKEN'" type="tns:NMTOKEN_vector"/>
</element>

Maybe, in the sense that it sounds as if what you really
would like to write is something like the following:

<element name="vector" type="tns:generic_vector"/>

<complexType name="generic_vector">
   <sequence minOccurs="0" maxOccurs="unbounded">
    <element name="value" type="anySimpleType">
     <alternative test="../@type='int'" type="int"/>
     <alternative test="../@type='dec'" type="decimal"/>
     <alternative test="../@type='date'" type="date"/>
     <alternative test="../@type='NMTOKEN'" type="NMTOKEN"/>
   </sequence>
   <attribute name="type" type="NMTOKEN"/>
</complexType>

This is logically consistent with the basics of conditional type
assignment as it's expected to appear (real soon now) in 1.1,
but the conditional assignment is in the element declaration
for the 'value' element instead of the declaration for 'vector'.
Since the 'type' attribute hasn't moved, the tests for conditional
typing now need to point up, at the 'type' attribute on the
parent 'vector' element.  As defined in current drafts of XSDL 1.1,
conditional type assignment doesn't allow the test expressions
to point to anything except attributes on the element being
declared.  (Or, more strictly, you can point to the parent, but
the XPath expression is evaluated against a data model instance
in which the element in question has no parent, so your pointing
won't do what you want.)

The Working Group is uncertain of where to draw the line on the
power of XPath expressions used for conditional type assignment;
if it's important for your use cases to be able to point upwards
in the tree -- or if it's important for you that the test
expressions NOT be able to point upwards in the tree! -- then
I urge you to read and comment on the next public working draft,
which will be published, as I say, real soon now.  (I can't
pre-announce it without running afoul of the W3C Communications
Team, so you won't find a specific date here.)  I don't guarantee
that the WG will do what you want, but I guarantee we'll consider
carefully any comment anyone makes. And real users (i.e. paying
customers) will be listened to carefully.

Since different people have different views on where to draw
the line, there may also be schema processors which provide
a non-conforming mode in which upward-pointing tests are handled
in the context of the full input tree, to save the effort of
pruning the tree.  Consult your supplier.

Of course, what you actually described in your posting would
require something more like this:

<element name="vector" type="tns:generic_vector"/>

<complexType name="generic_vector">
   <sequence minOccurs="0" maxOccurs="unbounded">
    <element name="vector" type="anySimpleType">
     <alternative test="../@type" type="exsdl:deref(../@type)"/>
    </element>
   </sequence>
   <attribute name="type" type="NMTOKEN"/>
</complexType>

Here, the value of the 'type' attribute on xsd:alternative
allows not just the QName of a type but any expression which
evaluates to a type.  And I've imagined an exsdl extension
library for XPath 2.0 which provides access to type definitions
by means of functions like exsdl:deref, which takes a QName
as argument and returns a type definition component as
result.

That would probably drive the makers of data binding tools crazy,
so I don't see it happening anytime soon as part of a spec.  But
there may be an analogy with generics and higher-order functions
that may be worth pursuing in experimental schema languages.

I hope this helps.

--C. M. Sperberg-McQueen
   World Wide Web Consortium

Received on Tuesday, 14 August 2007 18:19:18 UTC