I was thinking that we would try to keep the number of namespaces down to (about) one per country.
If the U.S., say, was first to define "milepost", but the UK used milepost, would you want the UK to import the US namespace just to get the milepost definition? It would clearly work, but I was thinking that the element registry didn't have the namespace, but that we encouraged reuse of the same entry in the registry for the same thing.
I'm okay either way.
Brian
On Sep 13, 2010, at 12:51 PM, Ted Hardie wrote:
> On Fri, Sep 10, 2010 at 5:54 PM, Winterbottom, James
> <James.Winterbottom@andrew.com> wrote:
>> What you have said is clear, and I do understand it.
>> My concern is that this falsely lulls a node receiving an element named fred in one namesapce into believing that it is interchangeable with fred in another namespace, and I think that this is a very dangerous precedent to set. If this is not the precedent that is trying to be set then I think that the second registry is redundant.
>>
>> Cheers
>> James
>
> I think the second registry actually shows tuples of (namespace,
> element) so that someone considering
> naming something ("newnamespace", "matched name") can consider whether
> they 1) need to create
> that element at all (instead re-using the existing one) or 2) whether
> disambiguation might be useful
> (e.g. using "track mile marker" instead of "milepost" for train track
> mile markers, when "milepost" has
> already been used to mean road mile markers).
>
> regards,
>
> Ted
>
>
>
>
>> ________________________________________
>> From: Brian Rosen [br@brianrosen.net]
>> Sent: Friday, September 10, 2010 5:35 PM
>> To: Winterbottom, James
>> Cc: Ted Hardie; Thomson, Martin; geopriv@ietf.org; James M. Polk
>> Subject: Re: [Geopriv] New Version Notification for draft-winterbottom-geopriv-local-civic-00
>>
>> I proposed two registries:
>>
>> One registered namespaces with (approximately) one per country.
>>
>> One registered element tags with expert review to avoid duplication and consistent naming that can be as big as it needs to be.
>>
>> I believe we all understand that an element in one namespace is distinct from an element in another in a syntactic/XML sense. However, it is very useful to avoid mile-post vs milepost even if the XML tools are clear that they are not the "same" thing. The point we are making is that they ARE the same thing and we should call them, and use them, the same way in any namespace that needs that kind of element. XML is actually getting in the way here, but no one is proposing to actually do anything other than have some expert look at a new element name to see if it is already in the registry and the same element name can be re-used to avoid complexity and confusion.
>>
>> Brian
>>
>> On Sep 10, 2010, at 6:12 PM, Winterbottom, James wrote:
>>
>>> Hi Ted,
>>>
>>> [AJW] I want to make really sure that I understand what you are saying here.
>>> Are you suggesting that different jurisdictions are defining different CATypes, e.g. Jurisdiction A defines CAType[100]=lamp-post and jurisdiction B defines CAType[101]=lamppost?
>>> This is the only kind of real overlap that I can see, and the draft indicates why continuing to extend CATypes has significant ramifications and should not be done.
>>> This really only leaves the option of adding new elements into a new XML namespace.
>>> Can we agree on this to start with?
>>> Otherwise we are not starting from the same premise.
>>>
>>> Other comments inline...
>>>
>>>
>>>
>>> For what it is worth, that's not something I see in the discussion to
>>> date at all. The interoperability you achieve
>>> with the xml namespace-based proposal without a registry is whatever
>>> was initially standardized. Each subsequent
>>> jurisdiction that wants to add functionality does so independently.
>>>
>>> [AJW] Do you agree that it does it within the jurisdiction though, and that the jurisdiction likely has the ability to require conformance?
>>>
>>> I agree with Brian that this is likely to mean that
>>> un-reviewed later additions will overlap (but likely not perfectly).
>>> Since the sender doesn't know what the
>>> receiver supports, the sender can't fix it by mapping to namespaces
>>> that the receiver *does* understand. That means
>>> the end device that doesn't understand "mile-post" but would have
>>> understood "milepost" can send it along,
>>> but can't actually use the data.
>>>
>>> [AJW] Okay, I see what you are saying, but I think that there are a couple of over simplifications in your example.
>>> The first is that if I have two namespaces urn:orga:civicextension and urn:orgb:civicextension, and both define milepost,
>>> <milepost xlmns:urn:orga:civicextension/> is not the same as <milepost xlmns:urn:orgb:civicextension/>, one cane define it as an integer, the other a complex element, and someone else a token. This is a very local thing and it should be.
>>> So what I am trying to say is that the base-part, that everyone needs to understand, is defined in the 5139 schema. Extensions are local, and that not everything will understand them, but they must not discard them. This will ensure that the information is used by things that can use it, even if intermediaries can't. This will mean that local applications will work, but that a foreign application may not get everything it wants. Emergency services as per ECRIT will work fine using the above method. Personally I think this is okay.
>>>
>>> I think having a registry here helps by identifying what has already
>>> been covered and fosters interoperability.
>>> Having a reviewer helps further, but making a first-come first-served
>>> registry to help folks identify what
>>> has already been done. I really don't seen how that level of support
>>> from the IETF could be considered
>>> control.
>>> [AJW] Because registry that Brian was proposing was a namespace registry, I didn't see a suggestion of also requiring them to register their schema extensions with the IETF. Even if they did, if the first come one had defined a lampost as a token within their namespace, and a second organization wanted to define a lamp-post as a token, for the second organization to pickup the first lamppost into their schema would result in a lot of unnecessary inclusions.
>>>
>>> So this leads back to my initial question of whether people understand the concern raise din the document about the continuing addition of more and more CATypes, and how this impacts things already specified and implemented.
>>>
>>> Cheers
>>> James
>>
>>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
