I think one must always qualify XML by "as text string" vs XML via some DOM tree or SAX events.
Ditto for json. So API vs text is orthogonal to XML/JSON. Get Outlook for Android<https://aka.ms/ghei36> ________________________________ From: Steve Lawrence <[email protected]> Sent: Monday, October 28, 2019 9:46:57 AM To: [email protected] <[email protected]> Subject: 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 >
