wiki-archive/twiki/data/SDD/SchemaBugs10Beta2.txt,v

head	1.19;
access;
symbols;
locks; strict;
comment	@# @;


1.19
date	2009.11.25.03.14.36;	author GarryJolleyRogers;	state Exp;
branches;
next	1.18;

1.18
date	2009.11.20.02.45.29;	author LeeBelbin;	state Exp;
branches;
next	1.17;

1.17
date	2007.03.06.17.30.00;	author TWikiGuest;	state Exp;
branches;
next	1.16;

1.16
date	2006.05.08.10.12.28;	author GregorHagedorn;	state Exp;
branches;
next	1.15;

1.15
date	2004.09.16.13.52.55;	author JacobAsiedu;	state Exp;
branches;
next	1.14;

1.14
date	2004.09.16.13.05.28;	author GregorHagedorn;	state Exp;
branches;
next	1.13;

1.13
date	2004.09.16.11.49.59;	author JacobAsiedu;	state Exp;
branches;
next	1.12;

1.12
date	2004.09.16.10.31.00;	author JacobAsiedu;	state Exp;
branches;
next	1.11;

1.11
date	2004.09.16.08.18.00;	author GregorHagedorn;	state Exp;
branches;
next	1.10;

1.10
date	2004.09.15.22.56.00;	author JacobAsiedu;	state Exp;
branches;
next	1.9;

1.9
date	2004.09.15.17.37.00;	author JacobAsiedu;	state Exp;
branches;
next	1.8;

1.8
date	2004.09.12.18.29.14;	author GregorHagedorn;	state Exp;
branches;
next	1.7;

1.7
date	2004.09.12.11.54.00;	author GregorHagedorn;	state Exp;
branches;
next	1.6;

1.6
date	2004.09.08.14.45.00;	author GregorHagedorn;	state Exp;
branches;
next	1.5;

1.5
date	2004.09.02.09.15.00;	author GregorHagedorn;	state Exp;
branches;
next	1.4;

1.4
date	2004.09.01.15.00.23;	author GregorHagedorn;	state Exp;
branches;
next	1.3;

1.3
date	2004.09.01.13.29.34;	author JacobAsiedu;	state Exp;
branches;
next	1.2;

1.2
date	2004.09.01.12.13.29;	author JacobAsiedu;	state Exp;
branches;
next	1.1;

1.1
date	2004.09.01.09.46.55;	author GregorHagedorn;	state Exp;
branches;
next	;


desc
@none
@


1.19
log
@none
@
text
@%META:TOPICINFO{author="GarryJolleyRogers" date="1259118876" format="1.1" version="1.19"}%
%META:TOPICPARENT{name="SchemaDiscussion"}%
---+!! %TOPIC%

<h2>Conceptual bugs</h2>

As Jacob notes, the Publication element in Citation should be required. The next beta version released will incorporate this minor change.

-- [[Main.GregorHagedorn][Gregor Hagedorn]] - 08 Sep 2004

The character modifiers were present in Coded, but forgotten in the Natural language descriptions.

-- [[Main.GregorHagedorn][Gregor Hagedorn]] - 16 Sep 2004

---

<h2>Technical bugs</h2>

<strong>The changes and problems discussed below are quite important for implementations, but not for architectural/structural discussions. I believe those interested in "understanding" SDD can ignore the discussion below. (Gregor)</strong>

Jacob Asiedu writes: Xerces 2.6.2(the latest version), does not validate the SDD schema. The following are two errors I have come across so far. 

1. Fatal error when minOccurs is associated with a sequence. -- Gregor: This is a cosmetic issue. I believe that xmlspy is correct in allowing  optionality on sequences, but since it has no relation to programming, I never really used it seriously (this is one reason why we have a number of additional compositor elements rather than flatter structures!). If Xerxes has a problem with it, I will certainly avoid it. In the meantime in UBIF.xsd please change &lt;xs:sequence minOccurs="0"&gt; to &lt;xs:sequence&gt;.

2. Fatal error " derivation-ok-restriction.2.1.2: Error for type 'CreatorContributorRef'. An attribute use in this type has a type which is not validly derived from the type of the matching attribute use in the base type." -- Gregor: This may well be a true design error, since the xmlspy does not seem to correctly validate the restriction derivation - so it is my job to do it and I may have failed. Here it seems there is a problem with the fact that for enumeration types, union should be the opposite of restriction, but xerces gets caught somehow. "RichAgentRef" has a "role" attribute of type "AgentRoleEnum". "CreatorContributorRef" has role attribute of type "AgentCreatorContribRoleEnum". "RichAgentRef" is supertype of "CreatorContributorRef", and "AgentRoleEnum" is a superset of "AgentCreatorContribRoleEnum". So far all the requirements are fullfilled, it is impossible to create an instance document where "CreatorContributorRef" cannot be treated as its supertype. However, the enumerations are composed through union, whereas the complex types are xml-schema-restrictions. -- Jacob: It went away after I made the changes you requested (= delete the 'CreatorContributorRef' in the indirect case). -- Gregor: So it seems that Xerxes cannot deal with indirect unions - it can however understand a single union step as being valid in the restriction case. See also UBIF.AgentRoleEnumXerces262Problem!

3. "derivation-ok-restriction.2.1.1: Error for type 'Certainty'.  The attribute use 'ref' in this type has a 'use' value of 'optional', which is inconsistent with the value of 'required' in a matching attribute use in the base type." -- Comments Gregor: The type "Certainty" is a restriction of "CharacterModification", and in both cases in XML spy the attribute is required. So either Xerces or Spy has a bug here. Spy assumes that if nothing is said in a schema attribute in a restriction-derived type, that the information from the schema attribute in the base type applies, Xerxes assumes the default value for the attribute as defined for xml-schema (i.e. as if there would be no schema inheritance). I cannot tell which is correct. It does not hurt to add the inherited information in the restriction case explicitly to the schema, which should keep Xerces happy... (Note - we talk about the schema files here, this has no bearing on UBIF or SDD instance documents.)

4. "derivation-ok-restriction.2.1.2: Error for type 'MeasurementUnitRef'.  The attribute use 'ref' in this type has type 'anySimpleType', which is not validly derived from 'RelationID', the type of the matching attribute use
in the base type." -- Gregor: very similar to above, different interpretation and implementation of schema inheritance. Here it affects the type rather than the minOccurs. The same solution used above should work.

-- [[Main.GregorHagedorn][Gregor Hagedorn]] - 01 Sep 2004

5. Another error noted by Jacob is that the Sample/@@id and <nop>SampleRef (element "BasedOnSample") had no key/keyref identity constraints. These have been added, starting with "SDD 1.0 beta 3b". This improves validation, but otherwise does not change the schema.

6. Several other Xerces-related problems could be fixed in the file attached under CurrentSchemaVersion. However, a major problem with Xerces remains. It rejects repeated choice (i. e. a maxOccurs="unbounded" on a choice model), and I see not solution for this. We have been using this all the time in SDD and it seems strange that it surfaces only now. The cardinality constraints on choice are legal to my knowledge. They are supported in Altova XML spy, and see e.g. http://www.dcs.napier.ac.uk/~andrew/xml/xsd/x1q6-ans.htm and http://www.google.com/search?q=%22choice+maxoccurs%22. I suspect this is a bug in Xerces 2.6.2?

-- [[Main.GregorHagedorn][Gregor Hagedorn]] - 12 Sep 2004

7. It took us a while working together (well, mostly Jacob and some mail to xml-dev). The last part of Sec 3.7.2 of http://www.w3.org/TR/xmlschema-1/#element-group is: "The name of this section is slightly misleading, in that the second, un-named, case above (with a ref and no name) is not really a named model group at all, but a reference to one. Also note that in the first (named) case above no reference is made to <nop>minOccurs or <nop>maxOccurs: this is because the schema for schemas does not allow them on the child of <nop><group> when it is named. This in turn is because the {min occurs} and {max occurs} of the particles which refer to the definition are what count"

It appears that the recommended usage is to make the content of groups be by ref in the schema, and put the occurrence counts on the refs or perhaps wrap the sequence or choice element inside another sequence or choice element with no <nop>minOccurs and <nop>maxOccurs as attributes. This shouldn't change instance docs.

Jacob observes that the following definition of "<nop> &lt;xs:complexType name="namedGroup"&gt;" in the normative schema for schemas at the end of http://www.w3.org/TR/xmlschema-1 is the specification of this. Jacob found that the MS parser also enforces this as does xerces. Spy is wrong in permitting it. Simple examples are attached  [[%ATTACHURL%/samples.zip][samples.zip]]

A little scouting on the net suggests that others occasionally bump into this, and that even schema experts can't necessarily explain why the design is this way. See http://lists.w3.org/Archives/Public/xmlschema-dev/2004Jul/0063.html. In particular, it would be nice to have a justification for the sentence:  "This in turn is because the {min occurs} and {max occurs} of the particles which refer to the definition are what count." 

Arguments about reusability might /favor/ using a ref in an instance document, but that would hold for lots of other things too. So this smells a little like it comes from "design by committee" and that somebody's design ideas made it into this bit, but not other places in the schema for schemas. My guess is that xerces has fewer bugs than Spy just because it is open source.

Main.BobMorris<br/>
Main.JacobAsiedu

---

Referring to the Xerces maxOccurs-unbounded problem discussed above: I am confused about the discussion. The section 3.7.2 you are citing refers to element *group* (xs:group), not to the compositor *xs:choice* element where Xerces reports an error that no maxOccurs may be present. I believe we have the problem on the *compositor* (xs:sequence, xs:choice, xs:all), not on the xs:group element.

I easily find an example in http://www.w3.org/TR/xmlschema-1 where exactly this is present: "xs:choice minOccurs="0" maxOccurs="unbounded"" (see immediately above chapter "3.4.3 Constraints on XML Representations"). In "3.8.2 XML Representation of Model Group Schema Components" the syntax seems to explicitly allow the maxOccurs="unbounded" for xs:choice.

It is true, that in SDD these repeated choices are usually inside a model group - but I cannot see why this should matter. If it is legal to have xs:sequence( xs:choice (unbounded, some elements), xs:choice (unbounded, other elements) ), why would it not be legal to have xs:sequence( xs:choice (unbounded, some elements), xs:group (ref="g1") ) where xs:group (name="g1", choice (unbounded, other elements))?

Note that the model groups used are only used to keep the discussion about using xsi:type or choice alive. They allow a replacement, and highlight all places where a polymorphic design is intended. They have no bearing on the behavior of the schema - which is the expected use of element groups...

Can you perhaps show which changes to the SDD schema would make it legal under Xerces?

-- [[Main.GregorHagedorn][Gregor Hagedorn]] - 16 Sep 2004

Xerces throws an exception not because we are using minOccurs/maxOccurs with choice/sequence but because we are using choice/sequence with the min/maxOccurs as an immediate child element of the group element( which is not allowed by W3C schema even though XMLSPY allows it. I have filed a bug report with Altova)<br/>.
Xerces does not throw an exception if one uses minOccurs/maxOccurs with sequence/choice if they are not immediate child elements of a group element.

Gregor writes: "If it is legal to have ... , why would it not be legal to have ...?" My reponse: Well, the documentation says it is not allowed and they do not give a reason for it.

-- Main.JacobAsiedu

Great job making me understand, thanks a lot! I think I have (understood and solved) it now! Starting with [[CurrentSchemaVersion][SDD 1.0 beta 3d]] (those who are watching please excuse the small beta steps!) SDD should be more valid and work with Xerces. The changes involved required a bit of type name changes and annotation changes - and I am certain something missed will be picked up later - but no changes to the fundamental model and instance documents. Thus the conceptual discussion can still be based on beta 2.

-- [[Main.GregorHagedorn][Gregor Hagedorn]] - 16 Sep 2004

%META:FILEATTACHMENT{name="samples.zip" attr="h" comment="" date="1095289628" path="samples.zip" size="911" user="JacobAsiedu" version="1.2"}%
@


1.18
log
@none
@
text
@d1 1
a1 1
%META:TOPICINFO{author="LeeBelbin" date="1258685129" format="1.1" reprev="1.18" version="1.18"}%
d19 1
a19 1
<strong>The changes and problems discussed below are quite important for implementations, but not for architectural/structural discussions. I believe those interested in "understanding" BDI.SDD can ignore the discussion below. (Gregor)</strong>
d21 1
a21 1
Jacob Asiedu writes: Xerces 2.6.2(the latest version), does not validate the BDI.SDD schema. The following are two errors I have come across so far. 
d27 1
a27 1
3. "derivation-ok-restriction.2.1.1: Error for type 'Certainty'.  The attribute use 'ref' in this type has a 'use' value of 'optional', which is inconsistent with the value of 'required' in a matching attribute use in the base type." -- Comments Gregor: The type "Certainty" is a restriction of "CharacterModification", and in both cases in XML spy the attribute is required. So either Xerces or Spy has a bug here. Spy assumes that if nothing is said in a schema attribute in a restriction-derived type, that the information from the schema attribute in the base type applies, Xerxes assumes the default value for the attribute as defined for xml-schema (i.e. as if there would be no schema inheritance). I cannot tell which is correct. It does not hurt to add the inherited information in the restriction case explicitly to the schema, which should keep Xerces happy... (Note - we talk about the schema files here, this has no bearing on UBIF or BDI.SDD instance documents.)
d34 1
a34 1
5. Another error noted by Jacob is that the Sample/@@id and <nop>SampleRef (element "BasedOnSample") had no key/keyref identity constraints. These have been added, starting with "BDI.SDD 1.0 beta 3b". This improves validation, but otherwise does not change the schema.
d36 1
a36 1
6. Several other Xerces-related problems could be fixed in the file attached under CurrentSchemaVersion. However, a major problem with Xerces remains. It rejects repeated choice (i. e. a maxOccurs="unbounded" on a choice model), and I see not solution for this. We have been using this all the time in BDI.SDD and it seems strange that it surfaces only now. The cardinality constraints on choice are legal to my knowledge. They are supported in Altova XML spy, and see e.g. http://www.dcs.napier.ac.uk/~andrew/xml/xsd/x1q6-ans.htm and http://www.google.com/search?q=%22choice+maxoccurs%22. I suspect this is a bug in Xerces 2.6.2?
d59 1
a59 1
It is true, that in BDI.SDD these repeated choices are usually inside a model group - but I cannot see why this should matter. If it is legal to have xs:sequence( xs:choice (unbounded, some elements), xs:choice (unbounded, other elements) ), why would it not be legal to have xs:sequence( xs:choice (unbounded, some elements), xs:group (ref="g1") ) where xs:group (name="g1", choice (unbounded, other elements))?
d63 1
a63 1
Can you perhaps show which changes to the BDI.SDD schema would make it legal under Xerces?
d74 1
a74 1
Great job making me understand, thanks a lot! I think I have (understood and solved) it now! Starting with [[CurrentSchemaVersion][BDI.SDD 1.0 beta 3d]] (those who are watching please excuse the small beta steps!) BDI.SDD should be more valid and work with Xerces. The changes involved required a bit of type name changes and annotation changes - and I am certain something missed will be picked up later - but no changes to the fundamental model and instance documents. Thus the conceptual discussion can still be based on beta 2.
@


1.17
log
@Added topic name via script
@
text
@d1 2
a4 2
%META:TOPICINFO{author="GregorHagedorn" date="1147083148" format="1.1" version="1.16"}%
%META:TOPICPARENT{name="SchemaDiscussion"}%
d19 1
a19 1
<strong>The changes and problems discussed below are quite important for implementations, but not for architectural/structural discussions. I believe those interested in "understanding" SDD can ignore the discussion below. (Gregor)</strong>
d21 1
a21 1
Jacob Asiedu writes: Xerces 2.6.2(the latest version), does not validate the SDD schema. The following are two errors I have come across so far. 
d27 1
a27 1
3. "derivation-ok-restriction.2.1.1: Error for type 'Certainty'.  The attribute use 'ref' in this type has a 'use' value of 'optional', which is inconsistent with the value of 'required' in a matching attribute use in the base type." -- Comments Gregor: The type "Certainty" is a restriction of "CharacterModification", and in both cases in XML spy the attribute is required. So either Xerces or Spy has a bug here. Spy assumes that if nothing is said in a schema attribute in a restriction-derived type, that the information from the schema attribute in the base type applies, Xerxes assumes the default value for the attribute as defined for xml-schema (i.e. as if there would be no schema inheritance). I cannot tell which is correct. It does not hurt to add the inherited information in the restriction case explicitly to the schema, which should keep Xerces happy... (Note - we talk about the schema files here, this has no bearing on UBIF or SDD instance documents.)
d34 1
a34 1
5. Another error noted by Jacob is that the Sample/@@id and <nop>SampleRef (element "BasedOnSample") had no key/keyref identity constraints. These have been added, starting with "SDD 1.0 beta 3b". This improves validation, but otherwise does not change the schema.
d36 1
a36 1
6. Several other Xerces-related problems could be fixed in the file attached under CurrentSchemaVersion. However, a major problem with Xerces remains. It rejects repeated choice (i. e. a maxOccurs="unbounded" on a choice model), and I see not solution for this. We have been using this all the time in SDD and it seems strange that it surfaces only now. The cardinality constraints on choice are legal to my knowledge. They are supported in Altova XML spy, and see e.g. http://www.dcs.napier.ac.uk/~andrew/xml/xsd/x1q6-ans.htm and http://www.google.com/search?q=%22choice+maxoccurs%22. I suspect this is a bug in Xerces 2.6.2?
d59 1
a59 1
It is true, that in SDD these repeated choices are usually inside a model group - but I cannot see why this should matter. If it is legal to have xs:sequence( xs:choice (unbounded, some elements), xs:choice (unbounded, other elements) ), why would it not be legal to have xs:sequence( xs:choice (unbounded, some elements), xs:group (ref="g1") ) where xs:group (name="g1", choice (unbounded, other elements))?
d63 1
a63 1
Can you perhaps show which changes to the SDD schema would make it legal under Xerces?
d74 1
a74 1
Great job making me understand, thanks a lot! I think I have (understood and solved) it now! Starting with [[CurrentSchemaVersion][SDD 1.0 beta 3d]] (those who are watching please excuse the small beta steps!) SDD should be more valid and work with Xerces. The changes involved required a bit of type name changes and annotation changes - and I am certain something missed will be picked up later - but no changes to the fundamental model and instance documents. Thus the conceptual discussion can still be based on beta 2.
@


1.16
log
@none
@
text
@d1 2
@


1.15
log
@none
@
text
@d1 1
a1 1
%META:TOPICINFO{author="JacobAsiedu" date="1095342775" format="1.0" version="1.15"}%
d3 73
a75 72
<h2>Conceptual bugs</h2>

As Jacob notes in ResolvedTopicCitationPublicationOptional, the Publication element in Citation should be required. The next beta version released will incorporate this minor change.

-- [[Main.GregorHagedorn][Gregor Hagedorn]] - 08 Sep 2004

The character modifiers were present in Coded, but forgotten in the Natural language descriptions.

-- [[Main.GregorHagedorn][Gregor Hagedorn]] - 16 Sep 2004

---

<h2>Technical bugs</h2>

<strong>The changes and problems discussed below are quite important for implementations, but not for architectural/structural discussions. I believe those interested in "understanding" SDD can ignore the discussion below. (Gregor)</strong>

Jacob Asiedu writes: Xerces 2.6.2(the latest version), does not validate the SDD schema. The following are two errors I have come across so far. 

1. Fatal error when minOccurs is associated with a sequence. -- Gregor: This is a cosmetic issue. I believe that xmlspy is correct in allowing  optionality on sequences, but since it has no relation to programming, I never really used it seriously (this is one reason why we have a number of additional compositor elements rather than flatter structures!). If Xerxes has a problem with it, I will certainly avoid it. In the meantime in UBIF.xsd please change &lt;xs:sequence minOccurs="0"&gt; to &lt;xs:sequence&gt;.

2. Fatal error " derivation-ok-restriction.2.1.2: Error for type 'CreatorContributorRef'. An attribute use in this type has a type which is not validly derived from the type of the matching attribute use in the base type." -- Gregor: This may well be a true design error, since the xmlspy does not seem to correctly validate the restriction derivation - so it is my job to do it and I may have failed. Here it seems there is a problem with the fact that for enumeration types, union should be the opposite of restriction, but xerces gets caught somehow. "RichAgentRef" has a "role" attribute of type "AgentRoleEnum". "CreatorContributorRef" has role attribute of type "AgentCreatorContribRoleEnum". "RichAgentRef" is supertype of "CreatorContributorRef", and "AgentRoleEnum" is a superset of "AgentCreatorContribRoleEnum". So far all the requirements are fullfilled, it is impossible to create an instance document where "CreatorContributorRef" cannot be treated as its supertype. However, the enumerations are composed through union, whereas the complex types are xml-schema-restrictions. -- Jacob: It went away after I made the changes you requested (= delete the 'CreatorContributorRef' in the indirect case). -- Gregor: So it seems that Xerxes cannot deal with indirect unions - it can however understand a single union step as being valid in the restriction case. See also UBIF.AgentRoleEnumXerces262Problem!

3. "derivation-ok-restriction.2.1.1: Error for type 'Certainty'.  The attribute use 'ref' in this type has a 'use' value of 'optional', which is inconsistent with the value of 'required' in a matching attribute use in the base type." -- Comments Gregor: The type "Certainty" is a restriction of "CharacterModification", and in both cases in XML spy the attribute is required. So either Xerces or Spy has a bug here. Spy assumes that if nothing is said in a schema attribute in a restriction-derived type, that the information from the schema attribute in the base type applies, Xerxes assumes the default value for the attribute as defined for xml-schema (i.e. as if there would be no schema inheritance). I cannot tell which is correct. It does not hurt to add the inherited information in the restriction case explicitly to the schema, which should keep Xerces happy... (Note - we talk about the schema files here, this has no bearing on UBIF or SDD instance documents.)

4. "derivation-ok-restriction.2.1.2: Error for type 'MeasurementUnitRef'.  The attribute use 'ref' in this type has type 'anySimpleType', which is not validly derived from 'RelationID', the type of the matching attribute use
in the base type." -- Gregor: very similar to above, different interpretation and implementation of schema inheritance. Here it affects the type rather than the minOccurs. The same solution used above should work.

-- [[Main.GregorHagedorn][Gregor Hagedorn]] - 01 Sep 2004

5. Another error noted by Jacob is that the Sample/@@id and <nop>SampleRef (element "BasedOnSample") had no key/keyref identity constraints. These have been added, starting with "SDD 1.0 beta 3b". This improves validation, but otherwise does not change the schema.

6. Several other Xerces-related problems could be fixed in the file attached under CurrentSchemaVersion. However, a major problem with Xerces remains. It rejects repeated choice (i. e. a maxOccurs="unbounded" on a choice model), and I see not solution for this. We have been using this all the time in SDD and it seems strange that it surfaces only now. The cardinality constraints on choice are legal to my knowledge. They are supported in Altova XML spy, and see e.g. http://www.dcs.napier.ac.uk/~andrew/xml/xsd/x1q6-ans.htm and http://www.google.com/search?q=%22choice+maxoccurs%22. I suspect this is a bug in Xerces 2.6.2?

-- [[Main.GregorHagedorn][Gregor Hagedorn]] - 12 Sep 2004

7. It took us a while working together (well, mostly Jacob and some mail to xml-dev). The last part of Sec 3.7.2 of http://www.w3.org/TR/xmlschema-1/#element-group is: "The name of this section is slightly misleading, in that the second, un-named, case above (with a ref and no name) is not really a named model group at all, but a reference to one. Also note that in the first (named) case above no reference is made to <nop>minOccurs or <nop>maxOccurs: this is because the schema for schemas does not allow them on the child of <nop><group> when it is named. This in turn is because the {min occurs} and {max occurs} of the particles which refer to the definition are what count"

It appears that the recommended usage is to make the content of groups be by ref in the schema, and put the occurrence counts on the refs or perhaps wrap the sequence or choice element inside another sequence or choice element with no <nop>minOccurs and <nop>maxOccurs as attributes. This shouldn't change instance docs.

Jacob observes that the following definition of "<nop> &lt;xs:complexType name="namedGroup"&gt;" in the normative schema for schemas at the end of http://www.w3.org/TR/xmlschema-1 is the specification of this. Jacob found that the MS parser also enforces this as does xerces. Spy is wrong in permitting it. Simple examples are attached  [[%ATTACHURL%/samples.zip][samples.zip]]

A little scouting on the net suggests that others occasionally bump into this, and that even schema experts can't necessarily explain why the design is this way. See http://lists.w3.org/Archives/Public/xmlschema-dev/2004Jul/0063.html. In particular, it would be nice to have a justification for the sentence:  "This in turn is because the {min occurs} and {max occurs} of the particles which refer to the definition are what count." 

Arguments about reusability might /favor/ using a ref in an instance document, but that would hold for lots of other things too. So this smells a little like it comes from "design by committee" and that somebody's design ideas made it into this bit, but not other places in the schema for schemas. My guess is that xerces has fewer bugs than Spy just because it is open source.

Main.BobMorris<br/>
Main.JacobAsiedu

---

Referring to the Xerces maxOccurs-unbounded problem discussed above: I am confused about the discussion. The section 3.7.2 you are citing refers to element *group* (xs:group), not to the compositor *xs:choice* element where Xerces reports an error that no maxOccurs may be present. I believe we have the problem on the *compositor* (xs:sequence, xs:choice, xs:all), not on the xs:group element.

I easily find an example in http://www.w3.org/TR/xmlschema-1 where exactly this is present: "xs:choice minOccurs="0" maxOccurs="unbounded"" (see immediately above chapter "3.4.3 Constraints on XML Representations"). In "3.8.2 XML Representation of Model Group Schema Components" the syntax seems to explicitly allow the maxOccurs="unbounded" for xs:choice.

It is true, that in SDD these repeated choices are usually inside a model group - but I cannot see why this should matter. If it is legal to have xs:sequence( xs:choice (unbounded, some elements), xs:choice (unbounded, other elements) ), why would it not be legal to have xs:sequence( xs:choice (unbounded, some elements), xs:group (ref="g1") ) where xs:group (name="g1", choice (unbounded, other elements))?

Note that the model groups used are only used to keep the discussion about using xsi:type or choice alive. They allow a replacement, and highlight all places where a polymorphic design is intended. They have no bearing on the behavior of the schema - which is the expected use of element groups...

Can you perhaps show which changes to the SDD schema would make it legal under Xerces?

-- [[Main.GregorHagedorn][Gregor Hagedorn]] - 16 Sep 2004

Xerces throws an exception not because we are using minOccurs/maxOccurs with choice/sequence but because we are using choice/sequence with the min/maxOccurs as an immediate child element of the group element( which is not allowed by W3C schema even though XMLSPY allows it. I have filed a bug report with Altova)<br/>.
Xerces does not throw an exception if one uses minOccurs/maxOccurs with sequence/choice if they are not immediate child elements of a group element.

Gregor writes: "If it is legal to have ... , why would it not be legal to have ...?" My reponse: Well, the documentation says it is not allowed and they do not give a reason for it.

-- Main.JacobAsiedu

Great job making me understand, thanks a lot! I think I have (understood and solved) it now! Starting with [[CurrentSchemaVersion][SDD 1.0 beta 3d]] (those who are watching please excuse the small beta steps!) SDD should be more valid and work with Xerces. The changes involved required a bit of type name changes and annotation changes - and I am certain something missed will be picked up later - but no changes to the fundamental model and instance documents. Thus the conceptual discussion can still be based on beta 2.

-- [[Main.GregorHagedorn][Gregor Hagedorn]] - 16 Sep 2004
@


1.14
log
@none
@
text
@d1 1
a1 1
%META:TOPICINFO{author="GregorHagedorn" date="1095339928" format="1.0" version="1.14"}%
d65 2
a66 1
Xerces throws an exception not because we are using minOccurs/maxOccurs with choice/sequence but because we are using choice/sequence with the min/maxxOccurs as an immediate child element of the group element. Xerces does not throw an exception if one uses minOccurs/maxOccurs with sequence/choice if they are not immediate child elements of a group element.
@


1.13
log
@none
@
text
@d1 1
a1 1
%META:TOPICINFO{author="JacobAsiedu" date="1095335399" format="1.0" version="1.13"}%
d9 4
d17 2
d65 4
a68 7
Xerces throws an exception not because we are using minOccurs/maxOccurs with choice/sequence but because we are using choice/sequence with the min/maxxOccurs<br/>
as an immediate child element of the group element</br/>
Xerces does not throw an exception if one uses minOccurs/maxOccurs with sequence/choice if they are not immediate child elements of a group element.<br/>

Gregor writes:<br/>
"It is true, that in SDD these repeated choices are usually inside a model group - but I cannot see why this should matter. If it is legal to have xs:sequence( xs:choice (unbounded, some elements), xs:choice (unbounded, other elements) ), why would it not be legal to have xs:sequence( xs:choice (unbounded, some elements), xs:group (ref="g1") ) where xs:group (name="g1", choice (unbounded, other elements))?"<br/>
My reponse: Well, the documentation says it is not allowed and they do not give a reason for it.
d71 3
@


1.12
log
@none
@
text
@d1 1
a1 1
%META:TOPICINFO{author="JacobAsiedu" date="1095330660" format="1.0" version="1.12"}%
d65 1
a65 1
My reponse: Well, the documentation says it is not allowed and they did not give a reason for it.
@


1.11
log
@none
@
text
@d1 1
a1 1
%META:TOPICINFO{author="GregorHagedorn" date="1095322680" format="1.0" version="1.11"}%
d58 10
@


1.10
log
@none
@
text
@d1 1
a1 1
%META:TOPICINFO{author="JacobAsiedu" date="1095288960" format="1.0" version="1.10"}%
d26 1
a26 1
5. Another error noted by Jacob is that the Sample/@@id and SampleRef (element "BasedOnSample") had no key/keyref identity constraints. These have been added, starting with "SDD 1.0 beta 3b". This improves validation, but otherwise does not change the schema.
d32 1
a32 3
7.
It took us a while working together (well, mostly Jacob and some mail to xml-dev).<br/>
The last part of Sec 3.7.2 of http://www.w3.org/TR/xmlschema-1/#element-group is <br/>
d34 1
a34 5
"The name of this section is slightly misleading, in that the second, un-named, case above (with a ref and no name)<br/>
 is not really a named model group at all, but a reference to one. Also note that in the first (named) case above no <br/>
reference is made to <nop>minOccurs or <nop>maxOccurs: this is because the schema for schemas does not allow them on the <br/>
child of <nop><group> when it is named. This in turn is because the {min occurs} and {max occurs} of the particles which <br/>
refer to the definition are what count"
d36 1
a36 3
It appears that the recommended usage is to make the content of groups be by ref in the schema, and put the occurrence <br/>
counts on the refs or perhaps wrap the sequence or choice element inside another sequence or choice element <br/>
with no <nop>minOccurs and <nop>maxOccurs as attributes. This shouldn't change instance docs.<br/>
d38 1
a38 4
Main.JacobAsiedu observes that the following definition of<br/>
	 <nop> <xs:complexType name="namedGroup">
in the normative schema for schemas at the end of <br/>
http://www.w3.org/TR/xmlschema-1 is the specification of this.<br/>
d40 1
d42 2
a43 2
Main.JacobAsiedu found that the MS parser also enforces this as does xerces.<br/>
Spy is wrong in permitting it.
d45 1
a45 8
Simple examples are attached  [[%ATTACHURL%/samples.zip][samples.zip]]:  <br/>

A little scouting on the net suggests that others occasionally bump into this, and that even schema experts<br/>
can't necessarily explain why the design is this way. See http://lists.w3.org/Archives/Public/xmlschema-dev/2004Jul/0063.html.<br/>
 In particular, it would be nice to have a justification for the sentence: <br/>
 "This in turn is because the {min occurs} and {max occurs} of the particles which refer to the definition are what count." <br/>
Arguments about reusability might /favor/ using a ref in an instance document, but that would hold for lots of other things too.<br/>
So this smells a little like it comes from "design by committee" and that somebody's design ideas made it into this bit, but not other places in the<br/> schema for schemas.<br/>
d47 1
d49 1
a49 1
My guess is that xerces has fewer bugs than Spy just because it is open source.<br/>
d51 1
d53 1
a53 4
Main.BobMorris<br/>
Main.JacobAsiedu

  
d55 1
a55 1
	* [[%ATTACHURL%/samples.zip][samples.zip]]: 
d57 2
a58 1
%META:FILEATTACHMENT{name="samples.zip" attr="" comment="" date="1095289628" path="samples.zip" size="911" user="JacobAsiedu" version="1.2"}%
@


1.9
log
@none
@
text
@d1 1
a1 1
%META:TOPICINFO{author="JacobAsiedu" date="1095269820" format="1.0" version="1.9"}%
d46 1
a46 1
main.JacobAsiedu observes that the following definition of<br/>
d71 2
d75 1
a75 1
%META:FILEATTACHMENT{name="samples.zip" attr="" comment="" date="1095269709" path="samples.zip" size="1695" user="JacobAsiedu" version="1.1"}%
@


1.8
log
@none
@
text
@d1 1
a1 1
%META:TOPICINFO{author="GregorHagedorn" date="1095013754" format="1.0" version="1.8"}%
d31 43
@


1.7
log
@none
@
text
@d1 1
a1 1
%META:TOPICINFO{author="GregorHagedorn" date="1094990040" format="1.0" version="1.7"}%
d26 3
a28 1
Several errors could already be fixed in the intermediate file attached under CurrentSchemaVersion. However, a major problem with Xerces, that it rejects repeated choice (i. e. a maxOccurs="unbounded" on a choice model), I can currently not solve. We have been using this all the time in SDD and it seems strange that it surfaces only now. The cardinality constraints on choice are legal to my knowledge. They are supported in Altova XML spy, and see e.g. http://www.dcs.napier.ac.uk/~andrew/xml/xsd/x1q6-ans.htm and http://www.google.com/search?q=%22choice+maxoccurs%22
@


1.6
log
@none
@
text
@d1 1
a1 1
%META:TOPICINFO{author="GregorHagedorn" date="1094654700" format="1.0" version="1.6"}%
d17 1
a17 6
2. Fatal error " derivation-ok-restriction.2.1.2: Error for type 'CreatorContributorRef'. An attribute use in this type has a type which is not validly derived from the type of the matching attribute use in the base type." -- Gregor: This may well be a true design error, since the xmlspy does not seem to correctly validate the restriction derivation - so it is my job to do it and I may have failed. Here it seems there is a problem with the fact that for enumeration types, union should be the opposite of restriction, but xerces gets caught somehow. "RichAgentRef" has a "role" attribute of type "AgentRoleEnum". "CreatorContributorRef" has role attribute of type "AgentCreatorContribRoleEnum". "RichAgentRef" is supertype of "CreatorContributorRef", and "AgentRoleEnum" is a superset of "AgentCreatorContribRoleEnum". So far all the requirements are fullfilled, it is impossible to create an instance document where "CreatorContributorRef" cannot be treated as its supertype. However, the enumerations are composed through union, whereas the complex types are xml-schema-restrictions.

Jacob: It went away after I made the changes you requested (= delete the 'CreatorContributorRef' in the indirect case). 
 Gregor: So it seems that Xerxes cannot deal with indirect unions - it can however understand a single union step as being valid in the restriction case.


d25 4
@


1.5
log
@none
@
text
@d1 1
a1 1
%META:TOPICINFO{author="GregorHagedorn" date="1094116500" format="1.0" version="1.5"}%
d3 1
a3 1
Jacob Asiedu writes:
d5 9
a13 1
Xerces 2.6.2(the latest version), does not validate the SDD schema. The following are two errors I have come across so far. 
d29 1
a29 1
-- Main.GregorHagedorn - 01 Sep 2004
@


1.4
log
@none
@
text
@d1 1
a1 1
%META:TOPICINFO{author="GregorHagedorn" date="1094050823" format="1.0" version="1.4"}%
d7 1
a7 1
1. Fatal error when minOccurs is associated with a sequence. Gregor: This is a cosmetic issue. I believe that xmlspy is correct in allowing  optionality on sequences, but since it has no relation to programming, I never really used it seriously (this is one reason why we have a number of additional compositor elements rather than flatter structures!). If Xerxes has a problem with it, I will certainly avoid it. In the meantime in UBIF.xsd please change &lt;xs:sequence minOccurs="0"&gt; to &lt;xs:sequence&gt;.
d9 1
a9 1
2. Fatal error " derivation-ok-restriction.2.1.2: Error for type 'CreatorContributorRef'. An attribute use in this type has a type which is not validly derived from the type of the matching attribute use in the base type." Gregor: This may well be a true design error, since the xmlspy does not seem to correctly validate the restriction derivation - so it is my job to do it and I may have failed. Here it seems there is a problem with the fact that for enumeration types, union should be the opposite of restriction, but xerces gets caught somehow. "RichAgentRef" has a "role" attribute of type "AgentRoleEnum". "CreatorContributorRef" has role attribute of type "AgentCreatorContribRoleEnum". "RichAgentRef" is supertype of "CreatorContributorRef", and "AgentRoleEnum" is a superset of "AgentCreatorContribRoleEnum". So far all the requirements are fullfilled, it is impossible to create an instance document where "CreatorContributorRef" cannot be treated as its supertype. However, the enumerations are composed through union, whereas the complex types are xml-schema-restrictions.
d11 2
a12 1
3. "derivation-ok-restriction.2.1.1: Error for type 'Certainty'.  The attribute use 'ref' in this type has a 'use' value of 'optional', which is inconsistent with the value of 'required' in a matching attribute use in the base type."
a13 1
Comments Gregor: The type "Certainty" is a restriction of "CharacterModification", and in both cases in XML spy the attribute is required. So either Xerces or Spy has a bug here. Spy assumes if nothing is said in an attribute in a restriction-derived type, that the information from the same attribute in the base type applies, Xerxes assumes the default value for the attribute as defined for xml-schema, regardless of derivation. I cannot tell which is correct. It does not hurt to add the inherited information in the restriction case explicitly, which should keep Xerces happy...
a14 1
I did this in experimental file sent to Jacob...
d16 4
@


1.3
log
@none
@
text
@d1 1
a1 1
%META:TOPICINFO{author="JacobAsiedu" date="1094045374" format="1.0" version="1.3"}%
d9 1
a9 1
2.Fatal error " derivation-ok-restriction.2.1.2: Error for type 'CreatorContributorRef'. An attribute use in this type has a type which is not validly derived from the type of the matching attribute used in the base type." Gregor: This may well be a true design error, since the xmlspy does not seem to correctly validate the restriction derivation - so it is my job to do it and I may have failed. Here it seems there is a problem with the fact that for enumeration types, union should be the opposite of restriction, but xerces gets caught somehow. "RichAgentRef" has a "role" attribute of type "AgentRoleEnum". "CreatorContributorRef" has role attribute of type "AgentCreatorContribRoleEnum". "RichAgentRef" is supertype of "CreatorContributorRef", and "AgentRoleEnum" is a superset of "AgentCreatorContribRoleEnum". So far all the requirements are fullfilled, it is impossible to create an instance document where "CreatorContributorRef" cannot be treated as its supertype. However, the enumerations are composed through union, whereas the complex types are xml-schema-restrictions.
d11 5
a15 1
I mail an attempt to Jacob to see whether a possible change helps.
a18 7

  3. I am still getting validation errors with Xerces:
		  "  derivation-ok-restriction.2.1.2: Error for type 'CreatorContributorRef'.  
The attribute use 'role' in this type has type 'AgentCreatorContribRol
eEnum', which is not validly derived from 'AgentRoleEnum', the type of the match
ing attribute use in the base type."
  
@


1.2
log
@none
@
text
@d1 1
a1 1
%META:TOPICINFO{author="JacobAsiedu" date="1094040809" format="1.0" version="1.2"}%
d21 1
a21 2
  

@


1.1
log
@none
@
text
@d1 1
a1 1
%META:TOPICINFO{author="GregorHagedorn" date="1094032015" format="1.0" version="1.1"}%
d15 8
@