RE: TAG scheme - some comments

> What 
> application for tags do you have in mind where parsing the 
> authorityName is necessary?

Simply that a TAG processor should be able to recognize a given URI to be a
TAG URI against the published syntax. Otherwise why both publishing a
syntax, anyway? Seems to me that you either want to generalize your
productions to include the possibility of a more generoc authoriyName oe
else dispense with the productions and leave it to the scheme alone to
declare that it's a TAG URI. ;)

I just don't believe you can leave the door open this way.

I'm also not a little sceptical about the following injunction:

> for generation only -- software SHOULD NOT parse tags.

The TAG has been minted to a specification which defines the two component
parts of a taggingEntity quite clearly: authorityName and date. I don't
believe there should be any problem in an application retrieving these
pieces of information.

This gets us back towards the opacity of URIs argument which confuses two
separate things - the URI string itself and the dereferent (aka
representation). URI strings are _not_ fully opaque but have at least a high
level generic structure and sometimes a more specific scheme structure or
sometimes even an application-level structure (e.g. OpenURL). An HTTP
processor must necessarily parse an HTTP URI to dereference it. In
particular, it can pick out a network authority, a path, etc. Likewise the
TAG scheme publishes a component architecture.

Tony


> -----Original Message-----
> From: sandro@roke.hawke.org [mailto:sandro@roke.hawke.org] On 
> Behalf Of Sandro Hawke
> Sent: 21 October 2004 13:58
> To: Hammond, Tony
> Cc: uri@w3.org
> Subject: Re: TAG scheme - some comments 
> 
> 
> 
> 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
> 
> 



********************************************************************************
DISCLAIMER: This e-mail is confidential and should not be used by anyone who is not the original intended recipient. If you have received this e-mail in error please inform the sender and delete it from your mailbox or any other storage mechanism. Neither Macmillan Publishers Limited nor any of its agents accept liability for any statements made which are clearly the sender's own and not expressly made on behalf of Macmillan Publishers Limited or one of its agents. Please note that neither Macmillan Publishers Limited nor any of its agents accept any responsibility for viruses that may be contained in this e-mail or its attachments and it is your responsibility to scan the e-mail and attachments (if any). No contracts may be concluded on behalf of Macmillan Publishers Limited or its agents by means of e-mail communication. Macmillan Publishers Limited Registered in England and Wales with registered number 785998 Registered Office Brunel Road, Houndmills, Basingstoke RG21 6XS
********************************************************************************

Received on Thursday, 21 October 2004 15:48:32 UTC