Specify allowed organisation numbers for document sharing

[hermanwh]

No description provided.

[runeflobakk]

Bare en heads-up på at du har navngitt selve elementet, som kan opptre ingen eller flere ganger, i flertall.
Altså at hvert orgnr. er et "numbers".

<allowed-origin-organisation-numbers>984661185</allowed-origin-organisation-numbers>
<allowed-origin-organisation-numbers>984661186</allowed-origin-organisation-numbers>
<allowed-origin-organisation-numbers>984661187</allowed-origin-organisation-numbers>

Det er nok mer korrekt å navngi elementet som angir ett orgnr i entall, og tillate flere av de (som du allerede gjør).

[hermanwh]

Jeg tenkte på det, men valgte å følge samme scheme som allerede var gjort for tags:

 <xs:element maxOccurs="unbounded" minOccurs="0" name="tags" type="tns:tag"/>

Åpen for at det var et dårlig valg, men det er i det minste konsistent 😅 Eller overser jeg noe?

[runeflobakk]

ok, det er allerede etablert konvensjon. Nei, skal ikke legge meg opp i det, men et element som angir 1 verdi er nok riktigst å navngi som nettopp en verdi, også kan elementet opptre flere ganger. JAXB har også innebygget støtte for å generere f.eks. Set<Tag> tags, altså at den slenger på flertalls-S på generert feltnavn når maxOccurs > 1 i XSD-en.

[hermanwh]

Ja enig 🙌

Jeg har noen ganger valgt å wrappe slike tilfeller i en egen type, f.eks ala

<xsd:complexType name="shared-documents">
    <xsd:sequence>
	<xsd:element name="shared-document" type="shared-document" minOccurs="0" maxOccurs="unbounded" />
    </xsd:sequence>
</xsd:complexType>

<xsd:complexType name="shared-document">
    <xsd:sequence>
	<xsd:element name="delivery-time" type="xsd:dateTime" />
	<xsd:element name="file-type" type="xsd:string" />
        ...
    </xsd:sequence>
</xsd:complexType>

Samme kunne f.eks vært gjort her med tags og tag, allowed-...-numbers og allowed-...-number osv.

[runeflobakk]

Ja absolutt, det er ofte røddig det! For det så har du jo også @XmlElementWrapper i JAXB som gjør at du kan unngå en ekstra klasse som uansett bare inneholder en collection av elementer.

[runeflobakk]

Det er ofte når man på et senere tidspunkt finner ut at man gjerne vil assigne "noe mer data" til en samling elementer som opptrer flere ganger, at man skulle ønske at man innførte et wrapper-element rundt de.

F.eks. et helt hypotetisk eksempel:
Man har fra før mulighet til å angi litt tags på et-eller-annet:

<tags>
  <tag>tag1<tag>
  <tag>tag2<tag>
</tags>

Også finner man senere ut at det kan være aktuelt med ulike sett med tags for ulike aktører, og man trenger å skille disse fra hverandre:

<tags>
  <applicable-for>OWNER</applicable-for>
  <tag>tag1</tag>
  <tag>secret-tag</tag>
</tags>
<tags>
  <applicable-for>PUBLIC</applicable-for>
  <tag>tag1</tag>
  <tag>public-tag</tag>
</tags>

Eller ev. applicable-for er et attributt på tags, man trenger uansett en måte å angi noe mer data for ulike sett med tags.
Sånt går an å innføre bakoverkompatibelt med litt nifty bruk av choice i XSD-en, men da er det viktig at de opprinnelige elementene er navngitt i entall, slik at man enten kan ha XML slik:

  <tag>tag1</tag>
  <tag>secret-tag</tag>

Eller slik:

<tags>
  <applicable-for>PUBLIC</applicable-for>
  <tag>tag1</tag>
  <tag>public-tag</tag>
</tags>
<tags>
  ...
</tags>

Java-koden må da mappe til både tag-elementet som en collection, og tags som en collection av en type som inneholder "tagger" og hvem de er for, også sørger skjema-validering for at man alltid bare vil få enten den ene eller andre collection-en.