I assume it's more common for people to enable full validation rather
than only do limited validation, so a runtime1 implementation of fixed
probably isn't high priority (and maybe why we haven't implemented it so
far). Though I have run into cases where I would have used it were i
available. Also, I do know of some schemas that use the
dfdl:checkConstraints() function, which should also check the fixed
value if it exists. So this could be useful in cases outside of limited
validation. We certainly will need to support this at some point.
For that reason, I would say that it would be helpful to move your below
code into a DSOM trait (probably the same trait as default is
implemented) and then have your BinaryIntegerKnownLengthCodeGenerator
access the values off of the DSOM. That way the fixed value is available
in the way we expect once someone does get around to adding support in
runtime1 or maybe for future types (i.e. non-integers) in runtime2.
Aside from that minor suggestion, I think your plan sounds very reasonable.
On 2/16/21 11:46 AM, Interrante, John A (GE Research, US) wrote:
> Thanks, Steve. Once you told me where to look, I was able to search the xml
> and find the fixed attribute's value directly in
> BinaryIntegerKnownLengthCodeGenerator using two lines of code:
>
> val fixed = e.xml.attribute("fixed")
> val fixedValue = if (fixed.isDefined) fixed.get.text else ""
>
> Since this code runs only once for each integer element while generating C
> code in runtime2, I don't expect performance to be affected significantly.
> If people want runtime1 to perform limited validation on the fixed attribute,
> then we'd have to add new members to the DSOM as you suggested below. How
> often do people run Daffodil in limited validation mode and would they want
> Daffodil runtime1 to check the fixed attribute in limited validation mode
> too?
>
> We can make runtime2 pay attention to the validation mode later - for now I
> plan to always generate the validation check in runtime2 since we want the C
> code to enforce message field restrictions as best as it can. Is that OK
> with people?
>
> John
>
> -----Original Message-----
> From: Steve Lawrence <slawre...@apache.org>
> Sent: Monday, February 15, 2021 4:59 PM
> To: dev@daffodil.apache.org
> Subject: EXT: Re: runtime2: how to find "fixed" attribute in compiled schema
> objects?
>
> We don't currently support the fixed attribute:
>
> https://issues.apache.org/jira/browse/DAFFODIL-117
>
> Validation="on" gives errors but that's because for that validation mode we
> just feed Xerces the schema and the XML infoset and it performs schema
> validation itself. We don't implement any of that validation code.
>
> We do implement some custom validation code for "limited" validation, but we
> currently only validate things like restrictions.
>
> To support this, we would likely want to add new members to the DSOM to
> extract this value from the schema so that grammars/runtimes could have
> access to it. I imagine it would be very similar to how we handle the default
> attribute. Which does something like this in ElementDeclMixin.scala:
>
> final lazy val defaultAttr = xml.attribute("default")
>
> final def hasDefaultValue: Boolean = defaultAttr.isDefined
>
> final lazy val defaultValueAsString = {
> ...
> }
>
> There's also the following in ElementBase.scala which converts that string
> value to value with the correct primitive type:
>
> final lazy val defaultValue = {
> ...
> }
>
> Doing something similar for the fixed attribute would add new properties to
> the DSOM, which would then make it available in the Grammar and runtimes.
>
>
> On 2/15/21 4:23 PM, Interrante, John A (GE Research, US) wrote:
>> I have a question for more experienced Daffodil maintainers. Suppose a
>> schema contains some fixed="constant" attributes:
>>
>> <xs:complexType name="Limits">
>> <xs:sequence>
>> <xs:element name="sync0" fixed="210" type="idl:uint8"/>
>> <xs:element name="sync1" fixed="13" type="idl:uint8"/>
>> <xs:element name="id" fixed="34" type="idl:uint8"/>
>> <xs:element name="length" fixed="0" type="idl:uint8"/>
>> <xs:element name="checksum" type="idl:uint16"/>
>> </xs:sequence>
>> </xs:complexType>
>> <xs:element name="LimitsDecl" type="idl:Limits"/> </xs:schema>
>>
>> If a TDML test suite turns on validation="on", Daffodil runtime1 will call
>> Xerces to perform validation on an XML infoset and Xerces will report a
>> validation error if, say, element sync0 does not contain the right value:
>>
>> [Fail] limits_parse
>> Failure Information:
>> (Implementation: daffodil) Validation errors found where none were
>> expected by the test case.
>> Validation Error: cvc-elt.5.2.2.2.2: The value '208' of element 'sync0'
>> does not match the {value constraint} value '210'.
>>
>> I want Daffodil runtime2 to detect the presence of a fixed="constant"
>> attribute on a schema grammar object and generate C code to check that the
>> corresponding C struct member contains the right value. However, I don't
>> know how to write code to find the "fixed" attribute on a schema grammar
>> object when runtime2 calls a class like
>> BinaryIntegerKnownLengthCodeGenerator. I set a breakpoint in the debugger
>> but a quick search found the fixed attribute only in a shareKey value.
>>
>> How can I detect the presence of the fixed attribute and get its value in
>> BinaryIntegerKnownLengthCodeGenerator?
>>
>> John
>>
>
