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

["Martin J. Dürst" <[e-mail]>]

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.