The way the API works is you create an InfosetOutputter and pass that
into the parse() method, along with your data. So if you wanted the
result of parse to be an XML text string, you would use the
XMLTextInfosetOutputter, which writes the text content to java OutputStream.
To do so in Java would look something like this:
ByteArrayOutputStream baos = new ByteArrayOutputStream();
XMLTextInfosetOutputter xmlio = new XMLTextInfosetOutputter(baos);
ParseResult pr = dataProcessor.parse(data, xmlio);
String xmltext = baos.toString("UTF-8");
If you wanted XSLT to process the output of parsing, you would then pass
this string into the API of the XSLT library of choice. Daffodil doesn't
care what you do with the String from here on out.
However, that's potentially inefficient because you've got to convert to
a string, and then the XSLT library will need to parse that string. A
more efficient way would be use a different infoset outputter to get the
infoset into something the XSLT library natively understands. For
example, if XSLT library understands JDOM, you might do this instead:
JDOMInfosetOutputter jio = new JDOMInfosetOutputter();
ParseResult pr = dataProcessor.parse(data, jio);
Doucment jdomDoc = jio.getResult();
And than use your XSLT library transform that doc:
Document transforemdDoc = xslt.transform(jdomDoc);
But it really comes down to what the XSLT library supports and if we
have an InfosetOuputter that supports it.
As an example, there is a "hello world" file on github:
https://github.com/OpenDFDL/examples/blob/master/helloWorld/src/main/java/HelloWorld.java
This example shows the use of the JDOMInfosetOutputter to parse data to
JDOM objects, then feeds that to JDOM's XSLT transformation library to
transform the JDOM document. So this never had to convert the infoset to
a string, everything worked in Java JDOM objects.
- Steve
On 10/28/19 10:33 AM, Costello, Roger L. wrote:
> Thank you Steve!
>
> What is the API method used to access "XML as a text string"?
>
> If I want to use XSLT to process the output of parsing, then what API method
> is used?
>
> /Roger
>
>
> -----Original Message-----
> From: Steve Lawrence <[email protected]>
> Sent: Monday, October 28, 2019 9:47 AM
> To: [email protected]
> Subject: [EXT] Re: Are these the 3 representations of parsed data?
>
> That is sortof correct, but could maybe be more precise.
>
> Daffodil has a concept of an "InfosetOutputter", which is how we convert
> Daffodil's internal infoset representation to something a user can use
> (there's no current way to directly access the internal infoset). We
> currently implement the following infoset outputters:
>
> XML - Standard XML text string
> JSON - Standard JSON text string
> JDOM - Java JDOM objects representing XML (org.jdom2.Document) W3CDOM -
> Java W3CDOM objects representing XML( org.w3c.dom.Document) Scala - Scala
> objects that represent XML (scala.xml.Node)
>
> The first two are generally what people think of when they hear XML or
> JSON--they're just text strings with the right structure.
>
> The last three are all different library representations of XML using
> different Java/Scala libraries. So depending on what library someone is using
> to invoke Daffodil parse, they might choose a different one of these.
>
> But note that all of these are part of the Daffodil API. So to say XML isn't
> part of the API isn't quite precise. They are all technically part of the API
> and can all be used in either Java or Scala, and API users get to pick which
> one they want to use.
>
> Also note that none of these output directly to files. The Daffodil CLI is
> capable of outputting to a file, but all it's really doing using one of the
> Infoset Outuptters, converting the result to a string (if it's not already)
> and then writing that string to a file. The -I flag lets you pick which one
> of the infoset outputters to use.
>
> - Steve
>
>
> On 10/28/19 9:17 AM, Costello, Roger L. wrote:
>> Hi Folks,
>>
>> On parsing Daffodil creates a representation of the data file:
>>
>> The representation may take several different forms. In the following
>> graphic I try to characterize the different forms:
>>
>> Do you agree with that? If no, then what would you change?
>>
>> /Roger
>>
>
