- From: Sandro Hawke <sandro@w3.org>
- Date: Thu, 21 Oct 2004 08:58:01 -0400
- 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