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

Michael Beckerle commented on DAFFODIL-1909:
--------------------------------------------

Sounds like my concerns about non-readonly are misplaced. 

Is your "not against changing" statement implying that there is some flaw here 
in the design that is to be corrected?


> 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
(v7.6.3#76005)

Reply via email to