There are two situations where it would
be be useful for DFDL to check XML schema constraints/facets when parsing,
regardless of the validation setting:
a) The scenario below, where a fixed
value is specified
b) The equivalent scenario where the
simple type has a single enumeration facet . This scenario can be extended
to cover all types of facets.
Both a) and b) are actually used in
xsds for industry standards where a choice is resolved by an identifier
field. Sometimes the identifier is not the first element on the choice
branch, so cannot be used as an initiator. Last time we discussed this,
we agreed ( I think ) to add a new dfdl function that checks fixed values
and facets and throws a processing error if they do not match the parsed
value. Or maybe we agreed to make it a new type of dfdl:assert/discriminator
test.
I proposed an alternative scheme in
which the DFDL parser unconditionally treats facet validation errors as
processing errors. This was not accepted because
a) facet validation can be expensive
in CPU, so it is useful to
b) if facet validation was put under
control of a parser feature then the info set produced by a parser would
depend on information outside of the DFDL schema.
I'm not sure about b), given that we
support external variables that could affect backtracking behaviour and
therefore affect the contents of the info set.
regards,
Tim Kimber, DFDL Team,
Hursley, UK
Internet: kimbert@uk.ibm.com
Tel. 01962-816742
Internal tel. 37246742
From:
Mike Beckerle <mbeckerle.dfdl@gmail.com>
To:
dfdl-wg@ogf.org
Date:
06/09/2012 03:09
Subject:
[DFDL-WG] clarification
wanted: fixed values
Sent by:
dfdl-wg-bounces@ogf.org
The spec states that the fixed facet is only used for validation.
That is, it works like default in that it supplies a default that can be
used when parsing and unparsing, but the comparison of an existing data
value with the schema-specified fixed value is only done for validation.
This means that a value not agreeing with the fixed value specified in
the schema would never cause backtracking.
Is this right? It seems awkward to me that I have to use a dfdl:assert
annotation to achieve this. That said, however, I can achieve the behaviour
I need. it's just more verbose than I wanted.
Is this what the current IBM implementation does?
Thanks
--
Mike Beckerle | OGF DFDL WG Co-Chair
Tel: 781-330-0412
--
dfdl-wg mailing list
dfdl-wg@ogf.org
https://www.ogf.org/mailman/listinfo/dfdl-wg
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