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 [1]? - Steve [1] https://daffodil.apache.org/docs/dfdl/#_Toc398030646 On 02/22/2018 12:30 PM, Mike Beckerle wrote: > I was looking at our javadoc and scaladoc for rc2, as linked from here: > > > https://daffodil.apache.org/releases/2.1.0/ > > > 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? > > > > >
