stevedlawrence commented on a change in pull request #458:
URL: https://github.com/apache/incubator-daffodil/pull/458#discussion_r526212182



##########
File path: 
daffodil-tdml-lib/src/main/scala/org/apache/daffodil/tdml/TDMLRunner.scala
##########
@@ -528,13 +532,39 @@ abstract class TestCase(testCaseXML: NodeSeq, val parent: 
DFDLTestSuite)
     } else rootAttrib
   }
 
-  lazy val rootNamespaceString = {
+  def getRootNamespaceString(schemaArg : Option[Node]) = {
     if (optExpectedOrInputInfoset.isDefined)
       infosetRootNamespaceString
     else if (embeddedSchema.isDefined)
       XMLUtils.EXAMPLE_NAMESPACE.toString
-    else
-      null
+    else if (this.rootNSAttrib != "")
+      rootNSAttrib
+    else {
+      // For some TDML Processors, we have to provide
+      // the root namespace. They don't provide a way to search
+      // for an element when just the name is unambiguous.
+      // So since nothing was provided, we just grab the
+      // target namespace URI (if any) from the primary
+      // schema file. If that turns out to be wrong, then
+      // the test case has to have an explicit rootNS attribute.
+      val schemaNode = schemaArg.getOrElse {
+        val schemaSource = getSuppliedSchema(None)
+        val source = schemaSource.newInputSource()
+        val node = try{
+          scala.xml.XML.load(source)
+        } catch {
+          // any exception while loading then we just use a dummy node.
+          case e:SAXParseException => <dummy/>
+        }
+        node
+      }
+      val tns = (schemaNode \ "@targetNamespace").text
+      val nsURIString = {
+        if (tns != "") tns
+        else null
+      }
+      nsURIString
+    }

Review comment:
       Do we know how IBM's TDML runner handles this negative case and how it 
finds the root element? They can do this without the rootNS attribute. I know 
our TDML has diverged quite a bit from the original TDML format, but it would 
be nice it we could minimize the differences and keep them somewhat compatible.
   
   I'm not a against the hueristic (I did give this a +1), but it feels 
unsatisfying to me to rely on this heursitic when we could just require that 
tests are unambigous and error if there are any ambiguities. Unambiguous tests 
are good thing.
   
   
   




----------------------------------------------------------------
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.

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


Reply via email to