Re: [apps-discuss] [Ecrit] review of draft-ietf-ecrit-lost-sync-12

(One typo correction inline)

On 3/5/12 4:05 PM, Robert Sparks wrote:
> There's an aspect of this document that I want to make sure folks 
> aren't missing.
>
> The things lostsync1 are adding are not things that something that 
> speaks lost will every say.
s/every/ever/

>
> It's not an iteration of the lost vocabulary in that sense.
>
> It is something spoken by things that talk about lost speakers.
>
> This is not an extension of Lost. It is a different protocol that 
> replicates the data used to
> answer Lost queries. It reuses the format that Lost uses when talking 
> about that data.
>
> Does that make a difference in whether a new namespace is appropriate?
>
> (No is an OK answer - I don't have a strong opinion, but my instinct 
> says that the separate
> namespace is likely to introduce fewer problems because of a bad 
> assumption an implementer
> could make if the values were in the same namespace).
>
> RjS
>
>
> On 2/23/12 4:38 AM, "Martin J. Dürst" wrote:
>> Hello Peter, others,
>>
>> On 2012/02/23 6:55, Peter Saint-Andre wrote:
>>> Robert Sparks asked me to think about the namespaces issue...
>>>
>>>> -------- Original Message -------- Subject:     Re: review of
>>>> draft-ietf-ecrit-lost-sync-12 Date:     Fri, 13 Jan 2012 11:17:10 
>>>> +0200
>>>> From:     Hannes Tschofenig<hannes.tschofenig@gmx.net>  To:     
>>>> "Martin J.
>>>> Dürst"<duerst@it.aoyama.ac.jp>  CC:     Hannes Tschofenig
>>>> <hannes.tschofenig@gmx.net>, Henning Schulzrinne
>>>> <hgs+ecrit@cs.columbia.edu>, Marc Linsner<mlinsner@cisco.com>,
>>>> Robert Sparks<rjsparks@nostrum.com>, "apps-review@ietf.org"
>>>> <apps-review@ietf.org>, ecrit@ietf.org
>>>>
>>>>
>>>>>  From Martin:
>>>>
>>>>> Namespaces: It is overkill to define new namespaces for each spec.
>>>>> It's a well-known secret in the XML community that it's easily
>>>>> possible to add a number of new elements to an existing namespace.
>>>>> This would be very appropriate in this case, because the number of
>>>>> reused elements and attributes is quite large, and the number of
>>>>> new elements is low. This would simplify most of the examples.
>>>>
>>>> I guess you refer to the namespace registration in the IANA
>>>> consideration section, namely urn:ietf:params:xml:ns:lostsync1
>>>>
>>>> In the RAI area we have (to my knowledge) always created new
>>>> namespaces for new schemas. But I am pleased to hear that this is not
>>>> needed.
>>>>
>>>> Could you explain what we should be doing instead?
>>
>> Rather than define a new namespace lostsync1, just add the few 
>> elements you defined anew to the lost1 namespace. It will make the 
>> format simpler, and it won't hurt.
>>
>>> I don't see a problem with defining a new namespace for each iteration
>>> of an XML format (lostsync1, lostsync2, etc.),
>>
>> There's no 'problem' with defining a separate namespace for each 
>> element. Correct software should still work. But it's not really 
>> necessary, it's tedious for human users and just overkill.
>>
>>> because I don't think
>>> there's a general case here -- backward compatibility can depend on the
>>> community of interest. One community might be doing strict schema
>>> checking, so that any new elements or attributes would be problematic.
>>> By contrast, another community might be more lax in its processing
>>> because they specify that applications must ignore unknown elements and
>>> attributes, even those qualified by an existing namespace.
>>
>> Validation is largely independent of namespaces. There are some 
>> problems with validating documents with more than one namespace, 
>> depending on the technology (I'd have to look up the details), but 
>> there are NO issues, with any of the validating technologies around 
>> (DTDs, XML Schema, Relaxing, Schematron), when having only one 
>> namespace and validating against subsets thereof.
>>
>> W3C technologies regularly do that (XHTML and SVG are the examples I 
>> know best). Way, way back there was a heated discussion in the XML 
>> community about whether a new namespace would make sense for a new 
>> version of XHTML, and this was strongly and utterly rejected. The way 
>> it was put most prominently was "a <p> is a <p> is a <p>".
>>
>> Validation is not only different for versions, but as you have 
>> explained also for various other purposes. Some applications may use 
>> validation to introduce further restrictions (e.g. for security 
>> reasons in certain places), and so on.
>>
>> A new namespace for a new version only make sense if the old and the 
>> new version are something completely different, with essentially no 
>> common elements and no documents that would be acceptable in both 
>> versions. For other cases, using separate namespaces just increases 
>> clutter without contributing anything.
>>
>> The same is the case here. The proposed "lostsync1" namespace doesn't 
>> contain many elements, and is only useful together with the "lost1" 
>> namespace. That's of course unless the people in charge of the LOST 
>> protocol and the people who came up with LOSTSYNC totally distrust 
>> each other, but I was just assuming that's not the case :-).
>>
>> Regards,    Martin.
> _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org
> https://www.ietf.org/mailman/listinfo/ecrit