Re: optional, but at least one required

Hi Marie,

I can't offer much other than to agree!  The approach does quickly suffer 
from a combinatorial type explosion!  (Or maybe a linear explosion if there 
is such a thing!)

FWIW - From my understanding, I think a Relax NG solution might look a bit 
better, but not dramatically so.  It would still have to enumerate all the 
various patterns.  (I'm sure someone will correct me if I'm wrong.)

XSD1.1 is looking at adding an xs:assert schema directive that includes a 
set of xpath expressions that a construct (sequence/choice/etc.) must 
satisfy.  I would be interested to know how complicated such an expression 
for this use-case would be if anyone cared to submit an example.

Pete.
=============================================
Pete Cordell
Codalogic
for XML Schema to C++ data binding visit
 http://www.codalogic.com/lmx/
=============================================
----- Original Message ----- 
From: "Marie Bilde Rasmussen" <mariebilderas@gmail.com>
To: "Pete Cordell" <petexmldev@tech-know-ware.com>
Cc: "Virginia Wiswell" <vwiswell@verizon.net>; <xmlschema-dev@w3.org>
Sent: Thursday, October 11, 2007 10:19 AM
Subject: Re: optional, but at least one required


> 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 10:25:50 UTC