[
https://issues.apache.org/jira/browse/DAFFODIL-2537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dave Thompson closed DAFFODIL-2537.
-----------------------------------
Verified the specified commit (commit 02e0623b245171c74677169050590cd8344e66bf)
is included in the latest pull from the daffodil repository.
Verified changes identified in commit comment were implemented.
Verified the affected daffodil sub-project sbt test suites execute successfully
including the added tests.
Verified the nightly test schemas compile and save successfully.
Verified the nightly test suite executes successfully.
> dfdlx:runtimeProperties property
> --------------------------------
>
> Key: DAFFODIL-2537
> URL: https://issues.apache.org/jira/browse/DAFFODIL-2537
> Project: Daffodil
> Issue Type: New Feature
> Components: Back End, Front End
> Affects Versions: 3.1.0
> Reporter: Mike Beckerle
> Priority: Major
> Fix For: 3.2.0
>
>
> A feature is needed to make it easier for users of our APIs to communicate
> from the DFDL schema to software called via our APIs such as an
> InfosetOutputter.
> The idea here is to provide an extension property (dfdlx prefix/namespace)
> which allows a whitespace separated list of name-value pairs to be attached
> to the runtime data corresponding to a term (element or model group).
> This enables the extensible parts of Daffodil, such as an InfosetOutputter or
> InfosetInputter to get custom behaviors that go beyond what is expressed only
> with DFDL properties.
> An example of a need for this is a data format which is binary data, but
> which contains embedded strings that are XML. This XML has its own XML
> Schema.
> Suppose one of those strings contains <foo attrib="bar"/> which is XML that
> cannot be described in a DFDL schema because it uses XML attributes. That
> piece of XML would normally show up in Daffodil's XML output with escaping
> like
>
> {code:java}
> "<foo attrib="bar"'/>"{code}
>
> That is because the DFDL schema for such data must model these strings as
> that, strings. So the XML output from Daffodil might altogether look like:
>
> {code:java}
> <data>
> <xmlString><foo attrib="bar"'/></xmlString>
> </data>{code}
> As SAX events, one would get a Start Element for 'data' a Start Element for
> 'xmlString' with a simple value - the string, which would have to be escaped
> to be legal in XML - then End Element 'xmlString' and End Element 'data'.
> However, an application may want this XML embedded within the XML created by
> Daffodil's XML infoset outputter, so that the whole data document in XML
> looks like a uniform piece of XML like:
>
> {code:java}
> <data><xmlString><foo attrib="bar"'/></xmlString></data>
> {code}
>
> The SAX events would want to be Start Element 'data', Start Element
> 'xmlString', Start Element 'foo' carrying metadata for the attribute 'attrib'
> with value "bar", End Element 'foo', End Element 'xmlString' and End Element
> 'data'.
> A DFDL schema, with a dfdlx:runtimeProperties can be used to make this happen:
>
> {code:java}
> <xs:element name="xmlString" type="xs:string"
> dfdlx:runtimeProperties="stringAsXML=true" .../>{code}
> The runtime ERD for this element will contain a Map[String, String] which
> would contain this pair "stringAsXML" and "true", which would be ignored by
> parsing/unparsing, excepting a custom InfosetOutputter that generates SAX XML
> events could be created that looks at each element ERD to see if it carries
> this pair. If so it could parse the string as XML and generate the SAX events
> corresponding to the string, so that the ultimate set of SAX events appears
> as if the document didn't contain a string of XML, but contained that XML
> substructure.
> The symmetric unparser InfosetOutputter is a little trickier, but the
> principle is the same, the events for that element ERD would consume all the
> events corresponding to a full element, convert that element and all its
> children into a string of textual XML, and use that as the value of the
> simple type element named 'xmlString'.
> This dfdlx:runtimeProperties property is a very general extension hook that
> can be used to transmit information from the DFDL schema to layer
> transformers, infoset inputters/outputters, etc.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
