mbeckerle commented on code in PR #1057:
URL: https://github.com/apache/daffodil/pull/1057#discussion_r1484698839


##########
daffodil-tdml-lib/src/test/scala/org/apache/daffodil/tdml/ScalaxbTests.scala:
##########
@@ -0,0 +1,23 @@
+package org.apache.daffodil.tdml
+
+import org.apache.daffodil.tdml.scalaxb.TestSuite
+
+import org.junit.Assert._
+import org.junit.Test
+
+class ScalaxbTests {
+
+  @Test def testReading(): Unit = {
+    val testSuite =
+      _root_.scalaxb.fromXML[TestSuite](
+        scala.xml.XML.load(
+          getClass
+            .getClassLoader()
+            .getResourceAsStream("test-suite/ibm-contributed/dpaext1-2.tdml"),
+        ),
+      )
+
+    assertNotNull(testSuite)
+    assertEquals(Some("dpaext"), testSuite.suiteName)
+  }
+}

Review Comment:
   > It's both reading and writing in the 
[daffodil-vscode](https://issues.apache.org/jira/browse/DAFFODIL-vscode) 
project, but I don't think that matters for the changes in daffodil proper. We 
can document the limitation with comments somewhere and downstream projects can 
choose to raise an error when encountering comments, filter them out, etc.
   
   So when scalaxb writes out an infoset, strings in the infoset are likely to 
contain "<", ">", "&", etc. So they need XML escapifying when output. I would 
assume this would happen automatically. 
   
   But note that if you read in TDML and an infoset is embedded and uses 
`<![CDATA[...]]>` stuff, that it will write out as the string contents (without 
the CDATA bracketing) but escapified. 
   
   I'm ok with that. It's just fragile if XML tooling decides it is ok to mess 
with the whitespace of the TDML file. E.x., if you output the XML back to a 
file by pretty printing it, then data might be corrupted by whitespace changes. 
   
   This is just a really painful area of experience with XML. It's just not a 
great data language because it was designed to be a human authored markup 
language. Hence, the whitespace insensitivity, line-ending changes, etc. 



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to