RE: optional, but at least one required

It's interesting to note that the xsl:analyze-string instruction in XSLT 2.0
has the content model (a|b|ab) and we got into quite a mess trying to
describe this clearly in English! (One of our readers claimed - vigorouly -
that the phrase "both elements are optional" was ambiguous.) 
 
In the schema we chose to model it simply as (a?b?) - there's no real need
in XSLT for the schema to describe all possible constraints because the
stylesheet processor is going to have to perform further checks anyway. I
think it's worth remembering that this is true of nearly all documents -
there will always be rules that can't be expressed in a grammar-based schema
language, and there's no law that says when you write a schema it has to
capture every conceivable constraint.
 
In this particular case, though, I don't think that writing (ab?|b) is
particularly obscure.
 
Michael Kay
http://www.saxonica.com/


  _____  

From: xmlschema-dev-request@w3.org [mailto:xmlschema-dev-request@w3.org] On
Behalf Of Marie Bilde Rasmussen
Sent: 11 October 2007 10:20
To: Pete Cordell
Cc: Virginia Wiswell; xmlschema-dev@w3.org
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" <  <mailto:vwiswell@verizon.net>
vwiswell@verizon.net>
To: "Pete Cordell" <petexmldev@tech-know-ware.com>; "Virginia Wiswell"
<  <mailto:vwiswell@verizon.net> 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/  <http://www.codalogic.com/lmx/> 
=============================================