Please have a position on the below proposal
from IBM for this week's WG call.
Regards
Steve Hanson
Architect, IBM
DFDL
Co-Chair, OGF
DFDL Working Group
IBM SWG, Hursley, UK
smh@uk.ibm.com
tel:+44-1962-815848
From:
Steve Hanson/UK/IBM
To:
DFDL-WG <dfdl-wg@ogf.org>
Date:
12/01/2015 16:56
Subject:
Unparser maxOccurs
issue
Possible change to spec needed., where
it describes what happens when maxOccurs is exceeded during unparsing for
occursCountKind 'fixed' and 'implicit' (and by implication scalar elements).
It currently says it is a processing
error. I think it is better to say that the unparser moves on when maxOccurs
is reached. This makes the behaviour analogous to parsing, when it does
not try to parse beyond maxOccurs and moves on. The current unparser
wording is based on the assumption that any next occurrence of the element
in the infoset must be an error, but this is not true - the next occurrence
could be an occurrence of a same named element later in the schema.
An obvious example is:
<xs:element name="data"
minOccurs="2"maxOccurs="2" dfdl:occursCountKind="fixed"
... />
<xs:element name="stuff" minOccurs="0" dfdl:occursCountKind="implicit"
... />
<xs:element name="data" maxOccurs="2" maxOccurs="2"
dfdl:occursCountKind="fixed" ... />
with an infoset where 'stuff' is missing:
message_data
data - xx1
data - xx2
data - yy1
data - yy2
A more interesting example is this, taken
from MIL-STD-2045 schema (my bold comments added):
<xsd:sequence dfdl:separator="">
<!-- Element Value1 -->
<xsd:choice>
<xsd:sequence
dfdl:separator="">
<xsd:group ref="FPI_true"/>
<xsd:element dfdl:length="4" dfdl:lengthKind="explicit"
name="Value1" type="xsd:string"/>
</xsd:sequence>
<xsd:sequence
dfdl:separator="">
<xsd:group ref="FPI_false"/>
</xsd:sequence>
</xsd:choice>
<!-- Element Value2 -->
<xsd:choice>
<xsd:sequence
dfdl:separator="">
<xsd:group ref="FPI_true"/>
<xsd:element dfdl:length="4" dfdl:lengthKind="explicit"
name="Value2" type="xsd:string"/>
</xsd:sequence>
<xsd:sequence
dfdl:separator="">
<xsd:group ref="FPI_false"/>
</xsd:sequence>
</xsd:choice>
<!-- Element Value3 -->
<xsd:choice>
<xsd:sequence
dfdl:separator="">
<xsd:group ref="FPI_true"/>
<xsd:element dfdl:length="4" dfdl:lengthKind="explicit"
name="Value3" type="xsd:string"/>
</xsd:sequence>
<xsd:sequence
dfdl:separator="">
<xsd:group ref="FPI_false"/>
</xsd:sequence>
</xsd:choice>
</xsd:sequence>
...where the FPI_true and FPI_false elements
are defined in their own global groups.
<xsd:group name="FPI_true">
<xsd:sequence dfdl:separator="">
<xsd:element default="true"
dfdl:length="1" dfdl:lengthKind="explicit" dfdl:textBooleanFalseRep="0"
dfdl:textBooleanTrueRep="1" name="FPI_true" type="xsd:boolean">
<xsd:annotation>
<xsd:appinfo
source="http://www.ogf.org/dfdl/">
<dfdl:discriminator>{. eq fn:true()}</dfdl:discriminator>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:group>
<xsd:group name="FPI_false">
<xsd:sequence dfdl:separator="">
<xsd:element default="false"
dfdl:length="1" dfdl:lengthKind="explicit" dfdl:textBooleanFalseRep="0"
dfdl:textBooleanTrueRep="1" name="FPI_false" type="xsd:boolean">
</xsd:element>
</xsd:sequence>
</xsd:group>
If the infoset looked like the following
an error would be given, whereas it is valid because the second FPI_false
is for Value2:
message_prefixedOccurs
FPI_false - false
FPI_false - false
FPI_true - true
Value3 - 9999
Regards
Steve Hanson
Architect, IBM
DFDL
Co-Chair, OGF
DFDL Working Group
IBM SWG, Hursley, UK
smh@uk.ibm.com
tel:+44-1962-815848
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU