Applying Restrictions to XML Attributes

[mnickel67]

Hi,

I'm still learning, so apologies if this is trivial...

Given the following XML snippet:

<Record>
<foo id="a">... </foo>
<foo id="b">....</foo>
<foo id="c">.....</foo>
</Record>

Is it possible to create an xsd file that enforces that within the
<Record> block there exists exactly three foo tags each containing a
different id value (from the enum a, b, and c )? My attempts to
define complexTypes for each of the foo elements has resulted in a
validation error indicating that the element foo needs to be defined
with a consistent type.

 

[Pavel Lepin]

I'm still learning, so apologies if this is trivial...

W3C's XML Schema Primer is a good, solid tutorial, if a bit
on the chewy side.

<Record>
<foo id="a">... </foo>
<foo id="b">....</foo>
<foo id="c">.....</foo>
</Record>

Is it possible to create an xsd file that enforces that
within the <Record> block there exists exactly three foo
tags each containing a different id value (from the enum
a, b, and c )?

It is possible.

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="data">
<xs:complexType>
<xs:sequence>
<xs:element ref="Record"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="Record">
<xs:complexType>
<xs:sequence>
<xs:element ref="foo" minOccurs="3" maxOccurs="3"/>
</xs:sequence>
</xs:complexType>
<xs:unique name="abc">
<xs:selector xpath="foo"/>
<xs:field xpath="@id"/>
</xs:unique>
</xs:element>
<xs:element name="foo">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute ref="id" use="required"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:attribute name="id">
<xs:simpleType>
<xs:restriction base="xs:string">
<xsattern value="(a|b|c)"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:schema>

Note that the fact that it is, indeed, possible doesn't yet
mean it's a good idea. My knee-jerk reaction would be to
redefine foo as three separate elements (foo-a, foo-b,
foo-c or something). Keep your grammars as simple as
possible, or you'll be in for a nasty surpise when you run
into unavoidable limitations of XML Schemata.

 

[usenet]

It is possible.
...
  <xs:element name="foo">
    <xs:complexType>
      <xs:simpleContent>
        <xs:extension base="xs:string">
          <xs:attribute ref="id" use="required"/>
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>
  </xs:element>
  <xs:attribute name="id">
    <xs:simpleType>
      <xs:restriction base="xs:string">
        <xsattern value="(a|b|c)"/>
      </xs:restriction>
    </xs:simpleType>
  </xs:attribute>
</xs:schema>
...

I don't know what other peoples' opinions are, but in general I think
I would avoid doing a ref to an attribute. My reasoninig is that in
XML documents attributes are generally unqualified (although there are
numerous exceptions to this such as xml:lang etc.). If an XML
namespace is present, then globally defined attributes are namespace
qualified. Agreed, this schema does not define a targetNamespace, so
the issue doesn't arise; at the moment.

However, if as the schema is evolved it's decided to give it a target
namespace, then the attribute will become qualified. This could
potentially make it difficult to migrate any existing XML instances.
For example, as we all know, a simple way to make an XML instance
namespace qualified is to use the default namespace (xmlns="foo"), and
that could potentially be a simple localized fix. But unqualified
attributes always belong to no namespace, so this wouldn't fix the
attributes, and a more detailed fix-up would be required.

Just my thought - and I'd interested to hear others!

Pete Cordell
Codalogic
Visit http://www.codalogic.com/lmx/ for XML C++ data binding

 

[Pavel Lepin]

in

I don't know what other peoples' opinions are, but in
general I think I would avoid doing a ref to an attribute.
My reasoninig is that in XML documents attributes are
generally unqualified (although there are numerous
exceptions to this such as xml:lang etc.). If an XML
namespace is present, then globally defined attributes
are namespace qualified. Agreed, this schema does not
define a targetNamespace, so the issue doesn't arise; at
the moment.

Ah well, I don't really have an opinion. I simply don't
tinker all that much with schemata, so I'm a bit in the
dark as to what the corresponding best practices are. In
this case I defined the attribute separately without even
thinking twice about this (or the consequences).

However, if as the schema is evolved it's decided to give
it a target namespace, then the attribute will become
qualified. This could potentially make it difficult to
migrate any existing XML instances.

Makes sense to me. However, I believe that all newly
developed schemata should be namespaced from the start. In
that case, the issue would have been immediately obvious
anyway.

Just my thought - and I'd interested to hear others!

Having thought about it for some five-ten minutes I tend to
agree in general. Defining attributes separately and
referring to them in element definitions should probably be
avoided, unless there's a very good reason for this (like,
some sort of meta-information present on many different
elements: but in that case it makes perfect sense to
namespace the attribute as well, so there).

 

[usenet]

in
<[email protected]>:
Having thought about it for some five-ten minutes I tend to
agree in general. Defining attributes separately and
referring to them in element definitions should probably be
avoided, unless there's a very good reason for this (like,
some sort of meta-information present on many different
elements: but in that case it makes perfect sense to
namespace the attribute as well, so there).

Makes sense to me. Nice to know my ramblings occasionally make sense!

Cheers,

Pete Cordell
Codalogic
Visit http://www.codalogic.com/lmx/ for XML C++ data binding