> In the examples used in RFC 5222, there was only one namespace, so
> there was no need for a disambiguation prefix for the elements. Even
> in your example, the disambiguation occurs with a prefix only on one
> of the two namespaces; the erratum appears to suggest it is required
> even when there is a single namespace. I don't think it is.
The problem isn't that the example is ambiguous to you or I. Machine interpretation of these elements is unable to make the sorts of inferences you are describing.
The type of each of these elements is clear:
qnameList = list { xsd:QName* }
Say that I implement this in Java with JAXB. The type of each of these elements (based on the schema) is java.util.List<javax.xml.namespace.QName>. When I go looking to see if the "A3" element is valid, I would use something like:
List<QName> valid = locationValidation.getValid();
for (QName n : valid) {
if (n.getNamespaceURI().equals("urn:...:civicAddr")
&& n.getLocalPart().equals("A3")) {
return true;
}
}
return false;
That wouldn't work with the example as it stands, because the value that my parser reads is {urn:ietf:params:xml:ns:lost1}:A3.
Another secondary benefit of the schema being as it is: noise is flagged as being in error. The following would be picked up in parsing and validation unless the "foo" prefix was bound:
<valid>foo:bar</valid>
--Martin
_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit
