[urn] Re: Registration request for urn:thread:

Hello Dale,

> Here is one point you should consider:  if "a:b:c" is registered as a
> sub-namespace, is there a rule that "a:b:c:d" must not be registered as
> a sub-namespace?  

Right, good point! We didn't consider this yet for inclusion in the formal rules. But it's definitely needed to avoid parsing issues in the future. The text is now updated to include rules ("MUST ... MAY") around this. The diff can be viewed in the commit:
https://github.com/ThreadGroup/urn-thread-registry/commit/3d44ecc46b8797bb998a5d18d7879149892ed344

So now, if sub-namespace "a:b:c" is registered then "a:b:c:d" cannot be anymore, and vice versa if "a:b:c:d" is already registered then "a:b:c" cannot anymore, but "a:b:c:e" can. 

Also there's now a rule for extending the data part (sn-content) with more elements ( ":" <data> ) for a given already-registered element. Now writing this, I'm reconsidering that choice - it may give rise to complexity and parser incompatibility between older/newer parsers of URNs. So I'll probably replace this by something better later this week: only allow extensions that have been pre-specified. 

E.g., if urn:thread:spec:<number1>:sec:<number2> is defined, a future update may add urn:thread:spec:<number1>:fig:<number2>, but only if the initial registration already defined this format by a template (urn:thread:spec:<number1>:<name-string>:<number2>. That seems much cleaner than arbitrary additions of new items in the future.

> but I strongly suggest that you settle on a resolution and document it in the registration

Agree that resolving this a priori is best; I've now started on this path. Any comments on the updated text are welcome, in the meantime.

Esko

-----Original Message-----
From: Dale R. Worley <[email protected]> 
Sent: Wednesday, November 20, 2024 17:41
To: Esko Dijk <[email protected]>
Cc: [email protected]; [email protected]
Subject: Re: [urn] Re: Registration request for urn:thread:

Esko Dijk <[email protected]> writes:
> On the syntax specification: the ABNF was introduced here just as a
> guideline to people designing a new entry for the registry, and the
> maintainers to check proposed new entries against. It wasn't intended
> for implementing a generic parser that could decompose any urn:thread
> item. 

The requirement for registration is that there be a syntax
specification, so that one can say a URN does or does not conform to the
specification.  There's no rule that the syntax specification has to be
unambiguous as a grammar.

OTOH, syntax specifications are usually expected to be tools for
understanding the conceptual structure of the namespace.  So if the
grammar is ambiguous, it would be informative to the reader to add a
note explaining how parsing is expected to be done in practice.

Relative to that desideratum,

> Still, some form of parsing is of course needed and maybe future use
> cases will need more generic parsers. Normally (today) a parser would
> be looking for a specific URN only or a subset of URNs. E.g. all the
> urn:thread:dataset:* ones for an app that configures Thread datasets,
> or all the urn:thread:pc:* ones for an app that allows passcode entry
> by QR code.  If we would write/need a generic parser for all items, it
> would have the list of sub-namespaces (i.e. registry items)
> implemented inside it, so it could still distinguish between 
>
> 1) valid-syntax URN (using known sub-namespace), 
> 2) valid-syntax URN (but unknown sub-namespace), or 
> 3) invalid-syntax URN. 
>
> I don't see any need or use case for parsing the sub-namespace
> unambiguously from a given 'thread' URN for cases where the
> sub-namespace is *not* in the registry -- as the code doing this
> parsing would anyway not know how to handle these, it would all fall
> into bucket 2)! It doesn't matter for this case if the parser would
> parse part of the sn-content as an sn-label, or vice versa parse a
> part of the sn-content as an sn-label.

I will note that in practice, maintaining a generic parser that needs to
know the current registrations is difficult in practice.  OTOH as you
say, you don't expect any uses where one needs to parse an arbitrary
thread URN, and it's easy to have a parser that handles only a defined
and unchanging subset of the URNs based on specific knowledge of that
subset.

Here is one point you should consider:  if "a:b:c" is registered as a
sub-namespace, is there a rule that "a:b:c:d" must not be registered as
a sub-namespace?  That is, even if the parser knows the namespaces in
question, the registration as written does not ensure that the parser
can determine unambiguously where the namespace ends.  In particular,
"urn:thread:a:b:c:d" is ambiguous whether (1) the sub-namespace is
"a:b:c:d" and there is no sn-content, or (2) the sub-namespace is
"a:b:c" and the sn-content is "d".

That can be resolved by either constraining that no registered
sub-namespace can be an extension of another registered sub-namespace,
or by constraining that, for any registered sub-namespace, any further
registered sub-namespaces must be distinguishable from possible
sn-content in some way.

As I said earlier in this message, resolving this is not required for
namespace registration, but I strongly suggest that you settle on a
resolution and document it in the registration.  That will be for the
readers' benefit and also will help you avoid getting tangled in syntax
difficulties later.

Dale

_______________________________________________
urn mailing list -- [email protected]
To unsubscribe send an email to [email protected]