[
https://issues.apache.org/jira/browse/DAFFODIL-1909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16374613#comment-16374613
]
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
(v7.6.3#76005)
