Let's take milepost.
Using your logic, the 300 or more countries that have some sort of numbered post which represents distance along a road/trail/whatever should each create a new namespace, and call that thing whatever fits their fancy. In the U.S., it would be a "milepost". It most certainly wouldn't in many other countries.
If I write an app that is expected to use the milepost globally, I have to use 300 different names for the same thing. I have to have 300 different snippets of code that do the same thing.
It "works" in the sense I can create the PIDFs, but not in the sense that the job to make a globally useful app is much, much larger than it should be for no value. The namespaces for all of these countries don't help me; they just make my code bigger and my PIDF bigger, and create more possibility for error.
Let's take "bridge". A bridge isn't something you would find in a street address, but many countries have naming schemes for bridges, and you can imagine apps that make use of them. I know of several. Your idea is that every app create it's own namespace, define bridge and demand that every user of that app use its definition of bridge. There isn't any reasonable way for an app designer to just know that someone else wrote an app that defined a bridge element unless you create a registry, so you would expect dozens of namespaces with a bridge element. Any creator of PIDFs needs custom code for each app, just to make a:bridge and b:bridge and c:bridge work.
To me, this is all stupid. There are very few instances of truly unique items in a location. Nearly every item is common across many applications. What you want is a list of element definitions. If someone has already defined it, use their definition. If not, create a new one and let everyone else know about it so they can use it. That is a registry.
I further observe that if you have such a registry, then namespaces are just baggage, but I said I would compromise on that point.
Brian
On Dec 8, 2010, at 2:49 PM, Winterbottom, James wrote:
> Responses inline.
>
>> -----Original Message-----
>> From: Brian Rosen [mailto:br@brianrosen.net]
>> Sent: Thursday, 9 December 2010 1:09 AM
>> To: Winterbottom, James
>> Cc: Thomson, Martin; geopriv@ietf.org
>> Subject: Re: [Geopriv] Other civic-related stuff
>>
>> We may be heading for compromise, so this may be moot but:
>>
>> The point of interoperability is that if YOU create a LIS and I create an
>> app that uses location, it would be real nice if my app uses your
>> location.
>>
>> If I define some extension that you don't know about, I may reject your
>> location.
>>
> [AJW] Then this would be a very bad application. If I provide you something that the application doesn't understand, then the application should ignore it. If the application requires more information than the LIS provides to the device in order to work, then having a registry still doesn't help. Perhaps you can elaborate a bit on how you see the registry fixing this problem?
>
>
>> The more we create these situations, the less the whole system will work.
>>
>> 99% of apps should be able to use the per country location that is
>> discussed in 5774. It is HIGHLY desirable that the total number of
>> elements needed to cover all of the countries that (eventually) get listed
>> in the registry that 5774 creates be as small as possible, and that
>> elements are re-used as much as possible. If I want my app to work world
>> wide, I have to deal with each of those elements, and the fewer, the
>> better.
>
> [AJW] If you want your app to work world wide, then we have a registry already for these elements, we don't need another one. If I want my app to work only within a limited scope, then I should be allowed to define local elements and have them made available to end-points that need to use the application. We have a disparity today in the HELD can do this and DHCP can't.
>
>>
>> I'll accept that there will be apps that need things beyond that.
>> However, the same considerations apply. The smaller the variation, the
>> easier it is to create locations and apps that interoperate.
>>
>> Uniqueness, which is the only property you seem to care about, is
>> necessary, but far, far from sufficient.
>>
> [AJW]I am not seeing what additional properties you require, certainly the registry is not providing anything additional.
>
>> I don't really care all that much about decoration. I'm an engineer and I
>> like things to be efficient. If you want to carry around a zillion
>> namespaces in a detailed location object, okay. I'd prefer just a unique
>> name in a registry, but that isn't that important to me. What is
>> important is to encourage re-use and advertisement of location elements so
>> that apps can be built that work well in a wide variety of situations.
>>
> [AJW] I like things to be efficient too. We aren't talking about a zillion namespaces in a location object, we are talking about one or two localized namespaces for local applications in some environments. The world doesn't need to know this stuff, so why tell it?
>
>
>> Brian
>> On Dec 7, 2010, at 7:12 PM, Winterbottom, James wrote:
>>
>>>
>>> Brian,
>>>
>>> I have asked on numerous occasions for you to justify the
>> "interoperability problems". I maintain that this is simply not true and
>> have provided examples of why it is not true. The fact that the XML we are
>> already using in protocols and in the PIDF itself all have multiple
>> namespaces goes a long way towards bunking the interoperability argument.
>> Quite simply, I don't want to discourage this, I think it is desirable
>> flexibility to have. It has no impact on backwards compatibility, basic
>> XML rules already allow for this. Local-civic explains this in quite a
>> succinct way.
>>>
>>> I am opposed to using a registry as you suggest below. We already have
>> clear guidelines on what is required to register a new CAtype, I don't
>> think these should be relaxed. Further, I think that anybody looking to
>> define new elements will think about their general applicability as part
>> of the definition phase and will, if they are good citizens, submit a
>> specification to have them accepted to the common set of CAtypes. Where
>> elements have local applicability I am all for them staying local, and I
>> think that we need a way to allow people to define these without imposing
>> unnecessary IETF process on them. I simply don't buy the FUD on
>> interoperability that is being pushed using arguments that misrepresent
>> scoping using XML namespaces.
>>>
>>> The reality is that the namespace mechanism doesn't need to be "made" to
>> work, because it already works and I don't see the prediction of doom and
>> chaos around us now, or even blooming on the horizon. Local-civic simply
>> makes DHCP compatible with what can be provided via HELD already.
>> Personally I am okay with a disparity, but previous decisions made by this
>> work group have wanted, as much as possible, to maintain a parity in
>> functionality between these LCPs. So, it is my opinion that this horse has
>> already to a large extent bolted in that we already have one LCP capable
>> of supporting 5139 civic extensions through namespace extension, the
>> greater question is do we leave DHCP behind?
>>>
>>> Your assertion that registries just work seems to be somewhat at odds
>> with the email that Richard forwarded from Julian Reschke on the 14th of
>> November.
>>> "Many people take it as a given that once you have an extension point,
>> you need a new registry. Not so." He then goes on to cite exactly what
>> they did in WebDav which has very close parallels to what we are
>> discussing here. The reality, quite to the converse to your assertion, is
>> that local namespaces work really well when defining local content!
>>>
>>> I assert that the proposed registry is an imposition on organizations
>> that want to define their own extensions. It is an administrative overhead
>> for the IETF. And, it undermines the due process required when defining
>> new CAtypes by providing a relaxed means of registering globally visible
>> civic address elements without requiring the scrutiny for general
>> applicability provided through the writing and approval of a formal
>> specification. This really will lead to the anarchy and chaos predicted
>> below.
>>>
>>> Cheers
>>> James
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
>> Behalf
>>>> Of Brian Rosen
>>>> Sent: Wednesday, 8 December 2010 9:25 AM
>>>> To: Thomson, Martin
>>>> Cc: geopriv@ietf.org
>>>> Subject: Re: [Geopriv] Other civic-related stuff
>>>>
>>>> There is currently two mechanisms. This adds 1/2 of one. Semantics,
>> to
>>>> be sure, but the point is that the only difference between two of them
>> is
>>>> the registry they go in and the actual element name/DHCP option.
>>>>
>>>> We can't avoid the new namespace thing, but it has so many
>>>> interoperability problems, all we can do is discourage it. Backwards
>>>> compatibility is going to be an issue. Yet another reason not to use
>> it.
>>>> Your proposal has the same problem.
>>>>
>>>> A problem occurs when you start with the local registry, and
>> subsequently
>>>> decide it deserves to be more general purpose. It occurred to me to
>> use
>>>> the same name/number in both, and ask implementations to treat one as
>> the
>>>> other if they encounter it. Anyone that really wanted to could
>> actually
>>>> check the IANA registry. All of the implementations we're concerned
>> about
>>>> are on-line anyway.
>>>>
>>>> The namespace mechanism can be made to "work", but it encourages
>> anarchy.
>>>> No interoperability, no common use. You have to just "know" that some
>>>> namespace is out there or roll your own. The registry is the
>>>> advertisement for what others have done. Namespaces are squeaks in the
>>>> wind. You could have a million of them and have no way whatsoever to
>>>> build a general purpose LIS, or LoST server, or anything else.
>>>>
>>>> I don't want to get rid of namespaces. Don't think we really could
>> even
>>>> if we were even more against them than I am. However, they are a bad
>>>> idea for all but a very, very constrained environment. Registries
>> work.
>>>> Once you have the registry, then you look for the simplest way to
>>>> implement the functionality. That's what I proposed (one extension
>>>> namespace, three DHCP options, and you are done for all new
>> extensions).
>>>> If you really want to, you could have only two DHCP options if you have
>>>> non-intersecting numbers in the two registries.
>>>>
>>>> Brian
>>>>
>>>>
>>>> On Dec 5, 2010, at 11:58 PM, Thomson, Martin wrote:
>>>>
>>>>> (Apologies for taking my time responding here.)
>>>>>
>>>>> That's three parallel extension mechanisms.
>>>>>
>>>>> You get to choose from three wonderful options. I'll admit that each
>> is
>>>> effectively partitioned from the other, so there is no need for
>> multiple
>>>> encodings for each.
>>>>>
>>>>> You'd better pick the right option from the outset. What happens when
>>>> you pick option 3 and it turns out that Option 2 or Option 1 was a
>> better
>>>> choice (maybe it was a good enough idea to standardize)?
>>>>>
>>>>> After all, if it didn't matter, why would there even be three options?
>>>>>
>>>>>
>>>>> The other big problem I have with this discussion is the subtext.
>> That
>>>> subtext is that the existing extension mechanism doesn't work and
>> /can't
>>>> be made to work/. You would have us throw it all in for a replacement
>>>> scheme. The numbers don't have enough code points; the namespaces are
>> too
>>>> ugly. To-mah-toes, to-may-toes.
>>>>>
>>>>> -local-civic acknowledges that it doesn't work due to the interaction
>>>> between the different formats, but proposes an approach that is far
>> less
>>>> disruptive.
>>>>>
>>>>> Changing backwards compatibility schemes has its own backward
>>>> compatibility problems, after all.
>>>>>
>>>>> I had a small concern about there being multiple forms, but now that
>>>> I've had time to mull it over, it's not going to cause significant
>> damage.
>>>> We can handle it. The way we agreed works. For the types of things
>> we're
>>>> being asked to add, we can handle it 100 times over.
>>>>>
>>>>>
>>>>> --Martin
>>>>>
>>>>> On 2010-12-03 at 09:32:40, Brian Rosen wrote:
>>>>>> I'll write an I-D if I need to.
>>>>>>
>>>>>> The essence is:
>>>>>> 1) A CAtype that is generally useful is defined and entered into the
>>>>>> existing registry as currently documented. To use it, the XML is:
>>>>>> <ext:EXT CAtype="STP">Avenue</ext:EXT>
>>>>>>
>>>>>> The DHCP is
>>>>>> <extCAoption><STP><Avenue>
>>>>>>
>>>>>> The LoST validation is:
>>>>>> ext:STP
>>>>>>
>>>>>> The LoST Service Boundary can contain <ext:EXT
>>>>>> CAtype=STP>Avenue</ext:EXT>
>>>>>>
>>>>>> 2) A CAtype that is not generally useful can be entered into a new
>>>>>> registry with expert review that simply avoids duplication. This
>>>>>> registry can't contain element names that conflict with those in the
>>>>>> existing registry (and vice versa). To use it, the XML is
>>>>>> <ext:localEXT CAtype="Foo">Baz</ext:localEXT>
>>>>>>
>>>>>> The DHCP is
>>>>>> <extlocalCAoption><Foo><Baz>
>>>>>>
>>>>>> The LoST validation is:
>>>>>> ext:Baz
>>>>>>
>>>>>> The LoST Service Boundary can contain <ext:localEXT
>>>>>> CAtype="Foo">Baz</ext:EXT>
>>>>>>
>>>>>> 3) It's possible, as it is now, to create a new namespace and
>> elements
>>>>>> within it. To do so requires no registry entry. The XML is
>>>>>> <my:Food>Tomato</my:Food>
>>>>>>
>>>>>> The DHCP is
>>>>>>
>> <extNameSpaceOption><http://foodsoftheworld.net/ns/food><Food><Tomato>
>>>>>>
>>>>>> The LoST validation is:
>>>>>> my:Food
>>>>>>
>>>>>> The LoST Service Boundary can contain <my:Food>Tomato</my:food>
>>>>>>
>>>>
>>>> _______________________________________________
>>>> Geopriv mailing list
>>>> Geopriv@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/geopriv
>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
