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

[Hannes Tschofenig <[e-mail]>]

Hi Martin, 

I understand the desire for namespace economy.

In this specific case we are defining a new protocol that incorporates elements from

* OGC  - a different organization who defined the Geography Markup Langugage. This is used for the geodetic location information.
* IETF GEOPRIV working group - this includes the civic location format.
* IETF ECRIT working group - this includes the prior work on LoST. We re-use one element from the LoST protocol (namely the <mapping> element).

While it is possible to avoid defining a new namespace for this protocol I believe it will lead to confusion. 
Of course IANA needs to define a new namespace but this is not a huge overhead. 

When extending the LoST Sync protocol with new elements one could think about the approach you suggest below, namely to just define new elements without defining a new namespace. Then, the group who defines that extension needs to take care that they do not define attributes and elements with colliding names (given that there is no registry defined either).  

Ciao
Hannes
 
On Feb 23, 2012, at 12:38 PM, 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.