Your suggestion for an example in local-civic is something we could do anyhow - does anybody think that would be a bad idea?
RjS
On Aug 7, 2011, at 7:22 PM, Thomson, Martin wrote:
> On 2011-08-06 at 07:56:26, Ted Hardie wrote:
>> 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
_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit
