Pointless occurrence

Dit is een statische kopie van het eerdere discussie.kinggemeenten.nl.
Nieuwe discussies kunnen in de GitHub repository 'StUF standaarden' als issue worden opgevoerd.

1 bericht / 0 nieuw
Robert Melskens
Pointless occurrence

Pointless occurrence
Zoals beloofd volgt hieronder de mailwisseling die ik tot nu toe over het 'Pointless Occurrence' issue heb gevoerd met Maarten v.d. Broek en Henri Korver. Tevens voeg ik de reacties die ik daarover heb gehad op het forum van de XML-Schema Usergroup.
 
======

Henri, Maarten,
 
Ik ben nog even in het probleem gedoken wat zich voordeed met 'KOZ-kerngegevens' binnen bg0310.ent.xsd.
 
De melding 'Pointless occurrence' die verschijnt zet je n.m.m. wel even op het verkeerde been.
Deze melding geeft eigenlijk alleen aan dat er een 'zinloos voorkomen' is van een, in dit geval, 'sequence' element. Een 'Pointless occurrence' is, zover ik weet, echter nooit een reden om een XML-Schema invalid te verklaren.
Het is volkomen valide om meerdere 'sequence' elementen achter elkaar te plaatsen, het is alleen niet altijd even zinvol.
 
Dit event is dus n.m.m. niet de oorzaak van het invalid zijn van het schema.
Ik heb dus flink zitten zoeken en met een versimpelde versie van het schema zitten werken om het probleem te achterhalen. Het lukte me echter niet om er mijn vingers achter te krijgen.
 
Daarom ben ik maar een gaan kijken hoe andere validators reageren.
Op 'http://www.w3.org/2001/03/webdata/xsv' vind je de W3C validator for XML-Schema.
Tot mijn verbazing gaf deze geen foutmelding te zien zodra ik er de versimpelde versie van het schema (zie attachment) doorheen stuurde.
Of we nu ook de conclusie kunnen trekken dat de door jullie gewenste structuur toegestaan is weet ik niet maar die neiging heb ik toch wel. In deze sla ik de autoriteit van het W3C nl. toch wel hoger aan als die van Altova.

=====
 
Ik heb daarop een mailtje aan Altova gericht met de vraag of er sprake was van een bug in XML-Spy.
 
=====

Hello Robert,

Thanks for contacting us.
You just seem to be missing a:
minOccurs="0"
..setting on one of your sequence nodes (see attached version of your file) as without this the default, invalid minOccurs="1" is implied.
As a side note I tried this with the .NET and Xerces parsers and they both also agreed with XMLSpy's result.
I hope this helps.
Best regards,
Paul Rees
Support Engineer
Altova GmbH
www.altova.com
====
Hierop heb ik de volgende vraag op het forum van de XML-Schema Usergroup geplaatst.
 
====
Hi,
With the attached XML-Schema, a simplified version of one of our schema's, we had some problems within XML-Spy.
The schema contains a content-model, which is judged by XML-Spy as invalid.
I know how to solve this invalidness, but that solution conflicts with the desired model.
 
I wasn''t able to get a grip on the real source of this 'invalid' message by XML-Spy.
Why is it invalid to have a minOccurs of 1 on the sequence element? So I decided to try another validator, it might give me more clues.
I tried '_http://www.w3.org/2001/03/webdata/xsv_' enad surprisingly the schema was judged here as valid.
 
I concluded XML-Spy would probably have a bug because I put more trust in a W3C validator.
 
So I sent a bug-report to Altova. A moment ago they answered me. They did test the schema also on a .Net and the Xerces paser and also those parsers reported an error.
Does this mean the W3C validator has a bug? If so, can you answer the question above. The XML-Schema recommendation doesn't help me much.
 
I attached the mentioned schema.
 
Greetings,
 
Robert Melskens
====
Waarop ik de volgende twee reacties heb gehad.
 
====
Saxon-SA also treats this schema as valid.
 
Saxon and the W3C validator both use an algorithm published by Henry Thomson for deciding whether one complex type is a valid restriction of another. This algorithm is "better" than the algorithm in the W3C spec, in that it has a better fit to the intent of the rules, which is that R should be allowed as a valid restriction of B if all instances of R are valid instances of B. That's clearly the case here. However, although this algorithm is better, it is not conformant: the conformance rules require a processor to implement the rules in the spec, bugs and all. Which is what XMLSpy, Xerces et al appear to be doing.
 
XSD 1.1 avoids this problem by defining the rules "by intent" rather than by an actual algorithm: for this example, complA1 will be a valid restriction of complA.
 
It's always good practice to put a schema through more than one processor if you want the schema to be completely interoperable. People who only test on XML Spy, for example, often find that it tolerates violations of the UPA constraint which other schema processors reject.
 
Michael Kay
en
Hi Robert,
 
In addition to what Michael already said, here's a little additional explanation that points you toward where you run afoul of the spec...
 
The error Xerces gives is: rcase-Recurse.2: There is not a complete functional mapping between the particles.
 
Xerces seems to be following 2.2 at http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#cos-p....
It removes the "pointless" sequence, so that comp1A1 becomes:
  <xs:complexType name="complA1">
      <xs:complexContent>
          <xs:restriction base="complA">
              <xs:sequence minOccurs="0">
                      <xs:element name="B" minOccurs="0"/>
                      <xs:element name="C" minOccurs="0"/>
                      <xs:element name="D" minOccurs="0"/>
                      <xs:element name="E" minOccurs="0"/>
              </xs:sequence>
          </xs:restriction>
      </xs:complexContent>
  </xs:complexType>
 
However, after doing this, applying the rules for a sequence particle restricting a sequence particle (http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#rcase...) leads to the noted failure (element B would map to the original nested sequence, elements C..E don't map to anything).
 
Kevin
====
Als ik het goed heb begrepen dan voldoet mijn versimpelde versie van het StUF schema en het StUF schema zelf aan de wijze waarop de validatieregels voor XML-Schema eigenlijk uitgelegd zouden moeten worden maar niet aan de meer striktere benadering die is vastgelegd in de specs.
 
Eigenlijk een beetje zoiets als een scheidsrechter die het spel niet aanvoelt en de regels exact toepast zoals ze geschreven zijn.
 
Kevin legt vervolgens nog even uit wat er volgens hem precies in de parsers gebeurd. Blijkbaar wordt het schema bij het parsen ontdaan van de overbodige 'sequence' waarna pas gekeken wordt of voldaan wordt aan de inheritance regels. Wat op dat moment niet meer het geval is.
 
Tot zover.

P.S. Ik heb het schema dat ik naar Altova en naar de XML Schema Usergroup heb gestuurd bijgevoegd.