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