W3C home > Mailing lists > Public > uri@w3.org > October 2004

Re: TAG scheme - some comments

From: Sandro Hawke <sandro@w3.org>
Date: Thu, 21 Oct 2004 08:58:01 -0400
Message-Id: <200410211258.i9LCw114002038@roke.hawke.org>
To: "Hammond, Tony" <T.Hammond@nature.com>
cc: uri@w3.org

After a quick two reads, your comments seems good/valid, thanks.

Except this one:

> 5. Sect 2.1 (para "Authority names...") and Sect. 4 ("There is a significant
> possibility...").
> I do not see how one can issue a syntax and then require TAG processors to
> ignore that syntax in order to futureproof the spec. That is the statements
> 	"To allow for such developments, software that processes tags MUST
> NOT reject them on the grounds that they are outside the syntax for
> authorityNamde defined above."
> 	"As stated in Section 2, however, to allow for future expansion,
> software MUST NOT reject tags which do not conform to the syntax specified
> in Section 2."
> IMO would appear to invalidate the utility of the spec. The way to deal with
> this situation is presumably to reissue a new TAG spec at such time as TAG
> processors have widespread support for alternative authority names.

Why is this a problem?  We tell software how to mint tags to avoid
collisions; we tell software how to compare tags.  Those are the only
things we expect people to do with tags for which they might be
different from other URIs.  Some people might be inclined to try to
parse tags - for some application-specific reason - and that's okay,
as long as they obey the restriction you're challenging, that they
don't complain if they can't parse the authorityName.  What
application for tags do you have in mind where parsing the
authorityName is necessary?

Maybe we need to state more clearly, near the BNF, that the syntax is
for generation only -- software SHOULD NOT parse tags.   (This is
wildly ironic, since I'm such a proponent of automated use of grammars
for both generation and parsing.  :-).

     -- sando
Received on Thursday, 21 October 2004 12:56:31 UTC

This archive was generated by hypermail 2.4.0 : Sunday, 10 October 2021 22:17:46 UTC