This has been outstanding too long. Based on another review of the thread, I'm going to put this
errata into hold for document update and add a pointer to the thread to its log. We're capturing the
crux in the local-civic document. Any update to 5222 itself should be done through a draft to be sure
we're capturing consensus.
RjS
On Aug 18, 2011, at 4:48 PM, Robert Sparks wrote:
> Ted - with this argument, do you still think the errata is inappropriate?
>
> 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
_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit
