Re: New Version Notification for draft-nottingham-link-hint-00.txt

On 06/25/2013 10:46 AM, Mark Nottingham wrote:
> Please have a look at the draft; the level of detail in the registrations is "a number" or "a list" or (infrequently) "an object" -- roughly on par with saying that a field in a registry is "an integer," which is quite common in IANA-land.

Ah fair enough. (Serves me right for reading & replying via phone
from a bus:-)

I misread it as you wanting the registry to contain [ "foo": "bar" ]
but you just want the registry to contain "array". Given you'd need
to read the spec I'm not sure its that much use to have that in the
registry, but I agree its not harmful.

Sorry for the distraction,
S.

> 
> On 25/06/2013, at 7:36 PM, Stephen Farrell <[email protected]> wrote:
> 
>> Just had a a quick peek at this since we've seen a case where stuff went wrong because a registry contained structured data. Roughly: 1) can we have an early allocation to work with IEEE; 2) oops that bit there should've been a 1; 3) can we mark (1) as reserved and redo stuff? 
>>
>> I think it's a mistake to ask IANA to handle structured data of any sort and this does that in spades.
>>
>> As a question: what makes you think this wouldn't be very likely to result in erroneous registrations? (Damaging the effectiveness of this registry but also possibly the IANA function, a bit)
>>
>> S
>>
>>
>> On 25 Jun 2013, at 05:17, Mark Nottingham <[email protected]> wrote:
>>
>>> Hi Erik, 
>>>
>>> Sorry for the delay - just back home now.
>>>
>>>> but i have one question about the general registry model: the current draft says that hints MUST have a name (very reasonable, of course), but also that hints MUST have their data model being defined in JSON.
>>>>
>>>> http://tools.ietf.org/html/draft-nottingham-link-hint-00#section-5.1
>>>>
>>>> living in a world where we have JSON services, XML services, and RDF services, it seems that hard-coding a specific language data model into such a spec (without constraining it in any way) will limit the utility of such a registry.
>>>
>>> It needs *a* data model.
>>>
>>>> for example, in the Home Document draft, which is the original source of the link hint idea, the hints were hard-coded with very constrained data models. this made it relatively easy to expose them in a different syntax (in the XML Home Document draft):
>>>>
>>>> http://tools.ietf.org/html/draft-wilde-home-xml-01#page-4
>>>>
>>>> without getting too much into the details of this specific registry: what are the best practices about allowing/controlling language dependencies in registries?
>>>
>>> Whoa, hold on - who said anything about a language? This is just the underlying data model; you can express it in a document however makes sense.
>>>
>>>> personally, i would feel more comfortable with having a registry that is of equal value to people regardless of their implementation language
>>>
>>> You're using "language" quite loosely here. 
>>>
>>>> , but then again that means that the registry itself must define a "mini-language" of its own.
>>>
>>> -1. Defining Yet Another Data Model as a political solution to avoid picking an existing one is sub-optimal at best.
>>>
>>> Cheers,
>>>
>>>
>>> --
>>> Mark Nottingham   http://www.mnot.net/
>>>
>>>
>>>
>>> _______________________________________________
>>> apps-discuss mailing list
>>> [email protected]
>>> https://www.ietf.org/mailman/listinfo/apps-discuss
> 
> --
> Mark Nottingham   http://www.mnot.net/
> 
> 
>