Steve Lawrence commented on DAFFODIL-1909:

Not really, I was just saying that if you thought there was an advantage to 
having InfosetInputters create InfosetNodes and setting properties on that, I'd 
be open to having that discussion. I haven't thought much about one vs the 
other. Probably not worth changing at this point unless there's a good argument.

> JAPI needs DISimple, DIComplex, DIArray, DIElement, etc for InfosetOutputter
> ----------------------------------------------------------------------------
>                 Key: DAFFODIL-1909
>                 URL: https://issues.apache.org/jira/browse/DAFFODIL-1909
>             Project: Daffodil
>          Issue Type: Bug
>          Components: API
>    Affects Versions: 2.1.0
>            Reporter: Michael Beckerle
>            Priority: Major
>             Fix For: 2.2.0
> Our JAPI and SAPI don't allow one to drill down (into the javadoc/scaladoc) 
> of the DISimple and other DINode subclasses that are passed to the 
> InfosetOutputter methods.
> The information on these DINode classes, including the ElementRuntimeData 
> information needed by an infoset outputter needs to be on documented APIs.
> This suggests we need to revisit the DINode classes and subclasses, and 
> create a read-only trait that we cast up to when passing these to the 
> InfosetOutputter API methods. 
> This is what InfosetElement, InfosetDocument, and InfosetArray were supposed 
> to be, though whether they are suitable is unclear. The DISimple/DIComplex 
> distinction, for example, is very helpful when creating an InfosetOutputter. 
> We may also want to provide an interface to a subset of the ERD data - as 
> many of its members are internally about the needs of parsers/unparsers and 
> not relevant to the external API for Daffodil.

This message was sent by Atlassian JIRA

Reply via email to