Subject: Re: [Ecrit] [Geopriv] Verifying errata 2511

From: Robert Sparks <[email-masked]>
Date: Wed, 14 Sep 2011 10:57:19 -0500

All - 

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
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ecrit
> 
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit