stevedlawrence commented on code in PR #1313:
URL: https://github.com/apache/daffodil/pull/1313#discussion_r1775627001
##########
daffodil-tdml-lib/src/main/scala/org/apache/daffodil/tdml/TDMLRunner.scala:
##########
@@ -2262,6 +2262,7 @@ case class Document(d: NodeSeq, parent: TestCase) {
case "byte" => new ByteDocumentPart(child, this)
case "bits" => new BitsDocumentPart(child, this)
case "file" => new FileDocumentPart(child, this)
+ case "" => throw TDMLException("documentPart must have attribute
'type'", None)
Review Comment:
I'm surprised we need this, the `tdml.xsd` file defines this as documentPart:
```xml
<element name="documentPart" type="tns:documentPartType"/>
<complexType name="documentPartType">
<simpleContent>
<extension base="xs:string">
<attribute name="type" type="tns:documentPartTypeEnum"
use="required"/>
...
</extension>
</simpleContent>
</complexType>
<simpleType name="documentPartTypeEnum">
<restriction base="xs:string">
<enumeration value="byte"/>
<enumeration value="text"/>
<enumeration value="bits"/>
<enumeration value="file"/>
</restriction>
</simpleType>
```
Seems like this already requires the `type` attribute and it must be one of
byte/text/bits/file. So I would think TDML XSD validation should catch this?
This ticket was opened in 2013, maybe we didn't do XSD validation back then? I
guess some unit tests could disable/skip validation, but then I would think
they would expect these kinds of failures? Do we really want to reimplement XSD
validation in scala just in case a unit tests disables it?
--
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]
