Re: [Ecrit] Generalizing draft-george-ecrit-lamp-post

[Richard Barnes <[e-mail]>]

True.  The other annoyance is that you add attributes, sub-elements,  
etc., you have to come up with a binary encoding in order to maintain  
compatibility with DHCP.

Still, it seems wasteful of CAtype space to keep defining new CAtypes  
for every little thing we notice.  Wasn't that kind of the idea with  
INT?

--Richard


On Apr 19, 2010, at 5:12 PM, Brian Rosen wrote:

> We thought of that, although what we considered was a simple  
> attribute for
> type and then just leave value as a normal CAtype is defined.  I  
> even said
> that in the intro to this version.
>
> The annoyance is that, once again, to do that, you have to create a  
> new
> namespace, although I'm getting used to that now (thanks, Martin),
> especially when adding a Catype that has subelements or attributes.
>
> Brian
>
>
> On 4/19/10 5:07 PM, "Richard Barnes" <[e-mail]> wrote:
>
>> It seems like this draft is a little specific to a particular use-
>> case.  As several people mentioned in Anaheim, there are lots of
>> things around that have numbers on them -- from lamp-posts, mile-
>> posts, utility poles, bridges, etc.  If you were going to be
>> inclusive, you might include all the QR codes that Google has been
>> putting up as well.
>>
>> So to avoid having to define new CAtypes for every "numbered thing
>> that can be a location indicator", could I suggest that we make the
>> following generalization?
>>
>> 1. Add a single "place number" ("PLN"?) CAtype with two child nodes:
>> 1.1. A "type" to indicate what type of numbered object is being
>> referred to
>> 1.2. The number of the referenced object
>>
>> 2. Add a first-come-first-served registry of type values
>>
>>
>
>