Re: optional, but at least one required

While waiting for XML Schema 1.1 one can use Schematron embedded in XML 
schema. For instance test -> (a*, b*, c*) but with at least one element 
present can be written as:

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" 
xmlns:sch="http://purl.oclc.org/dsdl/schematron">
   <xs:element name="a"/>
   <xs:element name="b"/>
   <xs:element name="c"/>
   <xs:element name="test">
     <xs:annotation>
       <xs:appinfo>
         <sch:pattern id="atLeastOne">
           <sch:rule context="test">
             <sch:assert test="count(*)>0">At least one of a, b or c 
must appear inside test.</sch:assert>
           </sch:rule>
         </sch:pattern>
       </xs:appinfo>
     </xs:annotation>
     <xs:complexType>
       <xs:sequence>
         <xs:element ref="a" minOccurs="0" maxOccurs="unbounded"/>
         <xs:element ref="b" minOccurs="0" maxOccurs="unbounded"/>
         <xs:element ref="c" minOccurs="0" maxOccurs="unbounded"/>
       </xs:sequence>
     </xs:complexType>
   </xs:element>
</xs:schema>

Best Regards,
George
---------------------------------------------------------------------
George Cristian Bina - http://aboutxml.blogspot.com/
<oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger
http://www.oxygenxml.com


Marie Bilde Rasmussen wrote:
> This syntactic workaround used to avoid UPA violation: (ab*|b) used to
> express (a|ab|b) is the only way I know of  to solve the problem.
> 
> 
> 
> But I do think that schemas become harder to construct and very much harder
> to read and communicate about when reformulated like this.
> 
> 
> And, just as Virginia, I could use a constraint on a sequence- or
> choice-element, saying that "it should contain something" (i.e. at least one
> child element) to be valid, even though all the members were optional,
> something like
> 
> 
> 
> 
> My impression is that the negavtive impact on construction and readability
> grows very fast when the number of alternatives raises.
> 
> 
> 
> Consider the case where we must apply the same requirements to a larger
> number of elements. In my dictionary-data, I require, that entries for
> homonyms are sorted after their part of speech, e.g. common nouns before
> proper nouns before verbs before prepositions. There kan be 0, 1 or more
> entries of every type, but my homonyms-element must contain at least one
> entry. I would love to write:
> 
> 
> 
> <xsd:element name="homonyms">
> 
> <xsd:sequence>
> 
>       <xsd:element ref="commonNoun-entry minOccurs="0"
> maxOccurs="unbounded"/>
> 
>       <xsd:element ref="properNoun-entry minOccurs="0"
> maxOccurs="unbounded"/>
> 
>       <xsd:element ref="verb-entry minOccurs="0" maxOccurs="unbounded"/>
> 
>       <xsd:element ref="preposition-entry minOccurs="0"
> maxOccurs="unbounded"/>
> 
> </xsd:sequence>
> 
> </xsd:element>
> 
> 
> 
> and be able to express some "at least one entry"-constraint at the
> <xsd:sequence>-level
> 
> 
> 
> But I cannot do this, so I have to implement my rule this way:
> 
> 
> 
> <xsd:element name="homonyms">
> 
> <xsd:choice>
> 
> <xsd:sequence>
> 
>       <xsd:element ref="commonNoun-entry maxOccurs="unbounded"/>
> 
>       <xsd:element ref="properNoun-entry minOccurs="0"
> maxOccurs="unbounded"/>
> 
>       <xsd:element ref="verb-entry minOccurs="0" maxOccurs="unbounded"/>
> 
>       <xsd:element ref="preposition-entry minOccurs="0"
> maxOccurs="unbounded"/>
> 
> </xsd:sequence>
> 
> <xsd:sequence>
> 
>       <xsd:element ref="properNoun-entry maxOccurs="unbounded"/>
> 
>       <xsd:element ref="verb-entry minOccurs="0" maxOccurs="unbounded"/>
> 
>       <xsd:element ref="preposition-entry minOccurs="0"
> maxOccurs="unbounded"/>
> 
> </xsd:sequence>
> 
> <xsd:sequence>
> 
>       <xsd:element ref="verb-entry maxOccurs="unbounded"/>
> 
>       <xsd:element ref="preposition-entry minOccurs="0"
> maxOccurs="unbounded"/>
> 
> </xsd:sequence>
> 
> <xsd:sequence>
> 
>       <xsd:element ref="preposition-entry maxOccurs="unbounded"/>
> 
> </xsd:sequence>
> 
> </xsd:choice>
> 
> </xsd:element>
> 
> 
> 
> In real life, we have about 15 different kinds of entries, so you can
> imagine how overwhelming that part of the schema is.
> 
> 
> I guess some of you will now tell me to use Relax NG instead. Unfortunatley,
> I don't have that option. So I am not asking for an answer or solution,  I
> would just like to hear some opinions on the issues.
> 
> 
> -Marie
> 
> 
> 
> **********
> 
> Marie Bilde Rasmussen
> 
> editor, MA BSc
> 
> Gyldendal Publishers, Copenhagen (Denmark)
> 
> (dictionaries)
> 
> www.gyldendal.dk
> 
> **********
> 
> 
> 2007/10/11, Pete Cordell <petexmldev@tech-know-ware.com>:
>>
>> To be pedantic, removing the second <xsd:element ref="a"/> prevents the
>> Unique Particle Attribution violation for _a_.  We then need to work
>> around
>> this change by adding minOccurs="0" to element b so we allow what we want.
>>
>> :-),
>>
>> Pete.
>> ----- Original Message -----
>> From: "Virginia Wiswell" <vwiswell@verizon.net>
>> To: "Pete Cordell" <petexmldev@tech-know-ware.com>; "Virginia Wiswell"
>> <vwiswell@verizon.net>
>> Cc: <xmlschema-dev@w3.org>
>> Sent: Thursday, October 11, 2007 2:35 AM
>> Subject: Re: optional, but at least one required
>>
>>
>>> So the minOccurs="0" on element b prevents the Unique Particle
>> Attribution
>>> violation for b?
>>>
>>> This is perfect, Pete. Thanks so much for helping me out.
>>>
>>> On Wed, 10 Oct 2007 19:22:51 +0100
>>>  "Pete Cordell" <petexmldev@tech-know-ware.com> wrote:
>>>> Hi Virginia,
>>>>
>>>> Your schema should indeed yield a Unique Particle Attribution
>> violation.
>>>> The reason is that when a parser reads element a, it is not immediately
>>>> obvious whether it corresponds to the first definition of a or the
>>>> second.
>>>>
>>>> You can get around this by changing your schema to:
>>>>
>>>>  <xsd:element name="parent">
>>>>   <xsd:complexType>
>>>>    <xsd:choice>
>>>>      <xsd:sequence>
>>>>        <xsd:element ref="a"/>
>>>>        <xsd:element ref="b" minOccurs="0"/>
>>>>      </xsd:sequence>
>>>>      <xsd:element ref="b"/>
>>>>    </xsd:choice>
>>>>   </xsd:complexType>
>>>>  </xsd:element>
>>>>
>> --
>> =============================================
>> Pete Cordell
>> Codalogic
>> for XML Schema to C++ data binding visit
>> http://www.codalogic.com/lmx/
>> =============================================
>>
>>
>>
>>
>

Received on Thursday, 11 October 2007 11:26:37 UTC