Re: [Geopriv] Other civic-related stuff

From: Brian Rosen ^lt;br@brianrosen.net>
Date: Thu Dec 09 2010 - 17:53:24 EST

This looks like consensus, at least between Martin and I.

Brian

On Dec 9, 2010, at 5:41 PM, Thomson, Martin wrote:

> On 2010-12-09 at 00:52:45, Brian Rosen wrote:
>>> A new proposal:
>>>
>>> 1. Continue using namespaces to extend the XML.
>>>
>>> 2. Define a way to carry namespace + localName + value in CAtypes.
>>>
>>> 3. End use of CAtype numbers.
>>>
>>> 4. Create a registry for the namespaces. FCFS or Expert Review with
>> a minimal template required only. Expert Review would only exist to
>> look for duplicates and to make sure the template is filled out.
>>>
>>>
>> I'm always willing to compromise, and decoration is one of the easiest
>> ways to compromise. All we need is uniqueness, and getting it by
>> registered namespace+local name gets that. I think it's unnecessary,
>> but it's okay.
>>
>> The downside to me is that there really is a difference between a
>> generally useful CAtype, with a document that has significant
>> consensus/review, and a CAtype that is not duplicative, but has a more
>> narrow use, and we're really only concerned about re-use. Retaining
>> the present registry with its current management requirements seems
>> important to me. If consensus is that having two levels of review is
>> not important, I won't make a fuss.
>
> I can be persuaded to include two levels of review, but I am only really describing the current management requirements. That is, the current requirements are equivalent to the weaker level you advocate.
>
> Current requirements are 'Expert Review' and 'Specification Required'. Specification Required is a subset of Expert Review [RFC5226], so that's just redundant. Without guidance (and there is none) Expert Review amounts to a check that the a specification exists.
>
>> As long as the template has a solid definition of the elements (such
>> that it's possible for anyone else to re-use it the same way, and the
>> expert can determine that a new one is different or not), It's okay.
>> Think about the fact that the registry has to have the elements defined
>> in it, not just the namespace, along with at least a minimal
>> description, so the expert (and anyone else) can scan through to find
>> out if something is there. IANA has to keep the templates, or they
>> have to be stored in some archive somewhere that is permanent. That's
>> simple enough. There wouldn't be any requirement that the element
>> names be unique (because the namespace is unique), but good practice
>> probably would suggest that it should be.
>
> Anything we do to specify a template or any other procedure only makes the process MORE difficult. That's probably not a bad thing because they also make it easier by making it clearer what the expectations are.
>
>> By the time you get to that, your registry and mine don't look very
>> different.
>>
>> I'm assuming that along with "Define a way to carry namespace +
>> localName + value in CAtypes", there is an equivalent DHCP option.
>> Qnames would continue to work for LoST validation and service
>> boundaries.
>
> That's right. The QName works by default. LoST validation and service boundaries only have to deal with one representation.
>
> --Martin
>
>> Brian
>
>
>

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
Received on Thu, 9 Dec 2010 17:53:24 -0500

This archive was generated by hypermail 2.1.8 : Thu Dec 09 2010 - 17:54:07 EST