W3C home > Mailing lists > Public > xmlschema-dev@w3.org > November 2002

RE: Key/IDREF checking as a pattern fragment

From: Stuart Brown <sbrown@extenza.com>
Date: Fri, 29 Nov 2002 15:20:20 -0000
Message-ID: <41CBE3F57CE3D3118F2F00508B8BA22B0434104E@sbis-uk-1.uk.swetsblackwell.com>
To: "'Stefan Wachter'" <Stefan.Wachter@gmx.de>
Cc: "'xmlschema-dev@w3.org'" <xmlschema-dev@w3.org>

Sorry, maybe I wasn't clear: the doThis doThat doSomething was an example
only: any number of "dos" may occur in any order, and the order is
important; hence the choice group in the original element-based model.
Individual attributes will fail to permit repetition or ordering.

Stuart

> -----Original Message-----
> From: Stefan Wachter [mailto:Stefan.Wachter@gmx.de]
> Sent: 29 November 2002 15:15
> To: Stuart Brown
> Cc: xmlschema-dev@w3.org
> Subject: Re: Key/IDREF checking as a pattern fragment
> 
> 
> Why not using
> 
> <element doThis="DEF1" doThat="DEF2" doSomethingElse="DEF3"/>
> 
> ?
> 
> Your intention is not feasable.
> 
> --Stefan
> 
> > 
> > Hi there,
> > 
> > I have an element which, in its content, I wish to be able 
> to construct a
> > function sequence which references other elements.  I am 
> currently using
> > the
> > following construct:
> > 
> > <xsd:element name="def">
> >  <xsd:complexType>
> >   <xsd:attribute name="id" type="xsd:ID"/>
> >  </xsd:complexType>
> > </xsd:element>
> > 
> > <xsd:element name="implement">
> >  <xsd:complexType>
> >   <xsd:choice minOccurs="0" maxOccurs="unbounded">
> >    <xsd:element name="doThis">
> >     <xsd:complexType>
> >      <xsd:attribute name="use" type="xsd:IDREF"/>
> >     </xsd:complexType>
> >    </xsd:element>
> >    <xsd:element name="doThat">
> >     <xsd:complexType>
> >      <xsd:attribute name="use" type="xsd:IDREF"/>
> >     </xsd:complexType>
> >    </xsd:element>
> >    <xsd:element name="doSomethingElseEntirely">
> >     <xsd:complexType>
> >      <xsd:attribute name="use" type="xsd:IDREF"/>
> >     </xsd:complexType>
> >    </xsd:element>
> >   </xsd:choice>
> >  </xsd:complexType>
> > </xsd:element>
> > 
> > Which allows me the following example content:
> > 
> > <def id="DEF1"/>
> > <def id="DEF2"/>
> > <def id="DEF3"/>
> > <implement>
> >  <doThis use="DEF1"/>
> >  <doThat use="DEF2"/>
> >  <doSomethingElseEntirely use="DEF3"/>
> > </implement>
> > 
> > However, for the sake of brevity in my instance XML, I 
> would like to be
> > able
> > to concatenate the do* elements and represent them as an 
> attribute in the
> > <implement> element, something like the following:
> > 
> > <implement 
> do="doThis(DEF1),doThat(DEF2),doSomethingElseEntirely(DEF3)"/>
> > 
> > I can write a xsd:restriction pattern for the attribute 
> simple type as
> > follows:
> > 
> > <xsd:pattern
> >
> value="(doThis|doThat|doSomethingElseEntirely)\(\c+\)(,(doThis
> |doThat|doSome
> > thingElseEntirely)\(\c+\))*"/>
> > 
> > which (I hope) enforces the function names, the parens, and 
> a requirement
> > that the content of the parens by characters permitted by 
> xsd:NMTOKEN
> > only,
> > but (and I bet you saw this coming) is there any way that I 
> can enforce
> > the
> > parens contents to be IDREFs?  At the moment I am 
> contemplating either
> > leaving it with my clunky element sequence, or using the 
> above pattern and
> > providing additional Schematron (or sim.) validation for the key
> > validation.
> > 
> > Any suggestions would be gratefully received,
> > 
> > Stuart
> > 
> 
Received on Friday, 29 November 2002 10:25:50 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 11 January 2011 00:14:35 GMT