Schema buggy: minOccurs

[netzkind]

Ahoi,

bei der Entwicklung des Editors ist mir aufgefallen, dass das Schema sich anders verhält als manche meinen mögen:

  <xsd:complexType name="trigger">
    <xsd:choice maxOccurs="unbounded" minOccurs="1">
      <xsd:element name="label" type="label" />
      <xsd:element name="layout" type="layout" minOccurs="0" maxOccurs="1" />
      <xsd:element name="address" type="address" minOccurs="1" />
    </xsd:choice>
    <xsd:attribute ref="value" use="required" />
    <xsd:attribute ref="mapping" use="optional" />
    <xsd:attribute ref="styling" use="optional" />
    <xsd:attribute ref="align" use="optional" />
  </xsd:complexType>

Diese Definition erlaubt auch einen Knoten wie er beispielsweise in der Demo-Config zu finden ist, der mir aber für die eigentliche Visu unsinnvoll erscheint - weil ein Element ohne Adresse nun mal nicht interaktiv ist:

        <trigger value="0" styling="All_Colors">
          <label>red</label>
        </trigger>

Was ist denn nun richtig? Sollte trigger zwingend ein address-Element haben, oder nicht?

Grüße,
Julian

[netzkind]

Das gilt übrigens nicht nur für Trigger, das war einfach das erstbeste Beispiel.

Wenn man sagt, dass address-Element MUSS vorhanden sein, der Rest ist optional, dann kann man bspw. diesen Weg hier gehen:
XSD Definition "any order" but with multiple, optional, and one occurence

Das ist natürlich echt starker Tobak. Wobei ich spontan davon ausgehen würde, dass die Jungs vom W3C ihre Definition von XHTML1-strict nicht so gemacht hätten wenn es auch anders ginge ...

[Chris M.]

Aus Visu-Sicht darf ein Widget gerne auch keine Adresse haben.

Das macht natürlich erst mal keinen Sinn. Kann aber z.B. beim Erstellen der Visu helfen, in dem man erst mal alle Widgets anlegt und erst dann die Adressen vergibt (keine Ahnung ob das jemand macht; die Praxis zeigt aber, dass User immer was anders machen, als man erwartet).

=> Ich würde es weiterhin zulassen.

Wenn allerdings Gründe dagegensprechen, die das schwierig machen (z.B. die Implementierung im Editor), dann können wir gerne dieses bisschen Freiheit wegnehmen und es strikter regeln.

[JuMi2006]

0/0/0 ist ja auch erstmal eine valide Adresse. Ebenso kann sich jeder eine Platzhalteradresse ausdenken.

[netzkind]

Wie parellel festgestellt, gilt das auch für maxOccurs, bspw.

  <xsd:complexType name="group">
    <xsd:choice minOccurs="0" maxOccurs="unbounded">
      <xsd:element name="layout" type="layout" minOccurs="0" maxOccurs="1" />
[..]
    </xsd:choice>
[..]
  </xsd:complexType>

oder

  <xsd:complexType name="colorchooser">
    <xsd:choice maxOccurs="unbounded" minOccurs="0">
      <xsd:element name="label" type="label" maxOccurs="1" />
      <xsd:element name="layout" type="layout" minOccurs="0" maxOccurs="1" />
      <xsd:element name="address" type="address" minOccurs="3" maxOccurs="3" />
    </xsd:choice>
  </xsd:complexType>

Man sollte meinen, dass hier maximal 1 layout respektive 3 address-Elemente erlaubt sind, das ist aber nicht der Fall - das XSD wird von check_config.php als valide durchgewunken auch wenn es mehr gibt.

Bislang interpretiert der Editor die bounds innerhalb von choices, was zwar dem entspricht was der XSD-Schreiber sich wohl dachte, nicht aber dem wie das XSD richtig zu interpretieren wäre.

Wenn das weiterhin akzeptabel ist, wäre die einfachste Lösung, innerhalb von choices keine bounds auf Elemente anzugeben (interessieren ja offenbar eh nicht).

Grüße,
Julian

[Chris M.]

XSD-Schreiber war in diesen Fällen vermutlich ich. Deine Vermutung sollte passen...

=> Kann ein XSD-Profi sagen, wie man richtig sagt, wie oft welches Sub-Element auftreten soll?

[netzkind]

Kann ein XSD-Profi sagen, wie man richtig sagt, wie oft welches Sub-Element auftreten soll?

Schau dir dazu mal den Link von mir ein paar Beiträge weiter oben in diesem Thread an. Da wird das XSD von xhtml1-strict referenziert. Die haben ja ein gleichartiges Problem im Head, dass dort nur ein title-Element auftauchen darf, aber beliebig viele script, meta etc. Das schaut echt wüst aus, wie da eine sequence-choice-sequence-Kaskade gebaut wird.

Meine Annahme ist, dass die Verfasser der XSD von xhtml1-strict wussten, was sie da taten, was mich zu der Annahme führt, dass genau das der richtige Weg ist.

[Chris M.]

Das glaube ich Dir gerne. Ich hatte gehofft, hier nimmt mich jemand an der Hand. Aber dann muss ich wohl mein Hirn da mal drum rum biegen