Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


Re: optional, but at least one required

From: George Cristian Bina <george@---------.--->
To: Marie Bilde Rasmussen <mariebilderas@-----.--->
Date: 10/11/2007 5:24:00 PM
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
www.---.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@t...>:
>>
>> 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@v...>
>> To: "Pete Cordell" <petexmldev@t...>; "Virginia Wiswell"
>> <vwiswell@v...>
>> Cc: <xmlschema-dev@w...>
>> 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@t...> 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/
>> =============================================
>>
>>
>>
>>
> 

From mik


transparent
Print
Mail
Like It
Disclaimer
.

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.

.
.

transparent

transparent