We do not currently provide the general scaladoc tree for all of
daffodil online anywhere. And I'm hesitant to provide that since I view
anything not in the daffodil-japi or daffodil-sapi subprojects as
internal and subject to change (i.e. not suitable for an API).
I think DAFFODIL-1909 that you just added is the right approach to solve
this. We should add an abstract class/trait that provides a minimal and
maintainable interface to the internals of the DISimple/DIComplex/etc.
and make that trait available in the japi/sapi so that
InfosetIOutputters can use it. Passing in DISimple/DIComplex/etc.
directly to the InfosetOutputters may have been a mistake, but since
there's really no Java/Scaladoc available for it I don't think we need
to worry about breaking backwards compatibility since no one could
really use this API as is. I suspect this new trait would essentially
have one public method for each of the members in the DFDL Infoset ?
On 02/22/2018 12:30 PM, Mike Beckerle wrote:
> I was looking at our javadoc and scaladoc for rc2, as linked from here:
> My mental experiment was to write my own Java InfosetOutputter (something
> requested by folks at AFRL) to directly output RDF triples from a parse.
> This turns out to be impossible, as our scaladoc for InfosetOutputter, does
> not allow one to drill into the DISimple, DIComplex or DIArray classes/traits
> of the arguments to the InfosetOutputter method calls.
> Do we provide the general scaladoc tree for all of daffodil anywhere online
> other than in a javadoc archive that can be pulled as a managed dependency?