mbeckerle commented on code in PR #1187:
URL: https://github.com/apache/daffodil/pull/1187#discussion_r1534202685
##########
daffodil-core/src/test/scala/org/apache/daffodil/core/layers/TestLayers.scala:
##########
@@ -37,13 +37,48 @@ class TestLayers {
val B64Layer1Schema =
SchemaUtils.dfdlTestSchema(
- <xs:include
schemaLocation="/org/apache/daffodil/xsd/DFDLGeneralFormat.dfdl.xsd"/>,
+ <xs:include
schemaLocation="/org/apache/daffodil/xsd/DFDLGeneralFormat.dfdl.xsd"/>
+ <xs:import namespace="urn:org.apache.daffodil.layers.boundaryMark"
+
schemaLocation="/org/apache/daffodil/layers/xsd/boundaryMarkLayer.dfdl.xsd"/>
+ <xs:import namespace="urn:org.apache.daffodil.layers.base64_MIME"
+
schemaLocation="/org/apache/daffodil/layers/xsd/base64_MIMELayer.dfdl.xsd"/>,
<dfdl:format ref="tns:GeneralFormat"/>,
- <xs:element name="e1" dfdl:lengthKind="implicit">
+ <xs:element name="e1" dfdl:lengthKind="implicit"
+ xmlns:bm="urn:org.apache.daffodil.layers.boundaryMark"
+ xmlns:b64="urn:org.apache.daffodil.layers.base64_MIME">
Review Comment:
Right now the checking that the magic setter and magic getters are properly
handling all the variables depends on the namespace of each layer being
separate, so that the magic setter and getters taken together must exhaustively
use up all the variables in that namespace each as exactly one arg to the
setter, or one getter.
That is to say, the namespace and variables defined there "win" and the
layer code must match those, not the other way around. I think this is a bit
safer from the perspective of making sure the jar file of java/scala code
matches the DFDL schema, as you can't mistakenly use the layer code with a
schema that defines new variables that the code doesn't know about, and have
those variables be silently ignored.
And as you point out, one can have a dfdlx:layer="compressor" and use a
variable to select which algorithm.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
