stevedlawrence commented on a change in pull request #478:
URL: https://github.com/apache/daffodil/pull/478#discussion_r617512405



##########
File path: 
daffodil-runtime1/src/main/scala/org/apache/daffodil/processors/DaffodilParseOutputStreamContentHandler.scala
##########
@@ -84,21 +180,42 @@ class DaffodilParseOutputStreamContentHandler(out: 
OutputStream, pretty: Boolean
       writer.write(System.lineSeparator())
       outputIndentation(writer)
     }
+
+    // extracts attributes (or new mappings in the case where namespacePrefix 
== true) from atts
+    val pmAttrRes = processAttributes(atts)
+    /**
+     * represents the attributes for the current element. We use this to 
generate the attributes list
+     * within the start tag
+     */
+    val currentElementAttributes = pmAttrRes._1
+    currentElementPrefixMapping =
+      if (pmAttrRes._2 != null) {
+        currentElementPrefixMapping
+      } else {
+        NamespaceBinding(pmAttrRes._2.prefix, pmAttrRes._2.uri, 
currentElementPrefixMapping)
+      }

Review comment:
       Thinking more about this, does this just wanted to be this?
   ```scala
   if (pmAttrRes._2 != null) {
     currentElementPrefixMapping = pmAttrRes._2
   }
   ```
   The idea being that if pmAttrsRes._2 was set, that means we are not getting 
prefix mappings via startPrefixMapping, but instead get them from processing 
the attributes. In that case, we shouldn't have gotten any attributes from 
startPrefixMapping and just override it with whatever we got from 
processingAttributes?
   
   Which makes me wonder if this logic of changing currentElementPrefixMapping 
wants to be in processAttributes? That function already mutates 
activePrefixMappings, so maybe it should also mutate 
currentElementPrefixMappings? That way processAttributes only needs to retuen 
the attributes and not the new prefix mappings. And then startElement can 
assume that one of startPrefixMapping or processAttributes mutated these state 
variables correctly and it doesn't have to worry about it?
   
   Another thought, is it possible to get prefix mappings from both 
startPrefixMaping and mappings parsed in proessAttributes? If so should 
processAttributes merge mappings it finds with currentElementPrefixMapping? Or 
should currentElementPrefixMapping always be null if processAttributes finds 
prefix mappings?




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