[jira] [Commented] (DAFFODIL-2537) dfdlx:runtimeProperties property

["Steve Lawrence (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/DAFFODIL-2537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17362035#comment-17362035 ] 

Steve Lawrence commented on DAFFODIL-2537:
------------------------------------------

I think some motivation might be needed as to why we just don't add a new property. For example, what is the advantage compared to something like this:
{code:xml}
<xs:element name="xmlString" type="xs:string" dfdlx:stringAsXML="true" ... />
{code}
I guess maybe a difference is that this property doesn't affect how daffodil parses the data, but instead how Daffodil builds the infoset? Though, in this specific case, one could maybe consider that stringAsXML="true" does tell daffodil how to parse the string. It's just that Daffodil is going to implement it in the infoset builders rather than in the parsers.

Another thought, this potentially makes it so you can't enable Daffodil validation since the infoset won't match the schema anymore. I guess this could maybe be solved with something like a choice? But that requires that the xmlString element goes away when converted to XML? So for example, we could have a schema that looks something like this:
{code:xml}
<xs:choice>
  <xs:element name="xmlString" type="xs:string" dfdlx:runtimeProperties="stringAsXML=true" ... />
  <xs:element ref="foo" />
</xs:choice>
{code}
And maybe we have some property added to the foo ref that tells Daffodil that this foo element will never actually be parsed, won't contain any dfdl properties, and that the XML comes from the xmlString element?

Without stringAsXML="true', you would get:
{code:xml}
<data>
   <xmlString>&lt;foo attrib=&quot;bar&quot'/></xmlString>
</data>
{code}
But with it you would get:
{code:xml}
<data>
   <foo attrib="bar"/>
</data>
{code}

Which makes me think of an alternative approach. What if we do something like this instead:
{code:xml}
<xs:element ref="foo" dfdlx:stringAsXML="true" ... />
{code}
So we reference a foo element, which could be any kind of element (e.g. xs:string, xs:int, xs:complex, etc). We allow this foo element and anything it references to not require any dfdl properties.

Instead, we just treat this element as if it were an xs:string, and only require properties related to parsing an xs:string. Daffodil will parse this element as if it were a string and just convert it to XML before adding to the infoset. This allows the XML to validate against the foo element.

I guess that doesn't work with a JSONInfosetOutputter though, and maybe it's just output as a string? So the JSOn would look something like:

{code:json}
"data": {
  "foo": "<foo attrib=\"bar\" />"
}
{code}

No one validates json against the schema, so maybe not a big deal that it technically doesn't match the infoset?

Another though, we could potentially make the parsing happening during the parse, rather than when we create the infoset. That way, we actually modify the infoset, and then other parts of the DFDL schema could actually use DPath to reach into that XML. Not sure that's needed, but potentially an interesting use case. Implies the property wants to be something like
{code}
dfdlx:stringAsInfoset="xml"
{code}
The idea being that we could potentially support mutliple different kinds of strings that could be converted to the infoset. JSON seems like an likely candidate for something else.

Also, I feel like we've talked about this in the past and gone through multiple iterations. I suspect maybe you've already mention this approach. I'm not sure if I dismissed it, but if I did, I retract that. This feels like a reasonable approach to me.

> 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}
>       "&lt;foo attrib=&quot;bar&quot'/>"{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>&lt;foo attrib=&quot;bar&quot'/></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)