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

[Robert Sparks <[e-mail]>]

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.

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<[e-mail]>  To:     
>>> "Martin J.
>>> Dürst"<[e-mail]>  CC:     Hannes Tschofenig
>>> <[e-mail]>, Henning Schulzrinne
>>> <[e-mail]>, Marc Linsner<[e-mail]>,
>>> Robert Sparks<[e-mail]>, "[e-mail]"
>>> <[e-mail]>, [e-mail]
>>>
>>>
>>>>  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.