Re: Tag Time Issues

Tim Kindberg <timothy@hpl.hp.com> wrote:

> As has been said during this discussion, it'll be software that produces
> tags by-and-large, so I'm not too worried about mistakes. I'm more
> concerned about practices (see my response to your next point).

I'm a bit wary of this argument. We've heard this before in the guise that
"humans will never use X identifier, so it doesn't matter what it looks
like." It was said about email addresses. It was said about URLs. Humans are
making and distributing email addresses and URLs -- tags will be no
different, so we should prepare for this. Even if software produces tags,
there will be humans writing the software, and the authors may not read the
spec too carefully and may be confused. I've seen this happen time and
again, despite the best intentions of the standard-makers involved.

> The date is almost always used opaquely: as I'm sure you appreciate, its
> role is to make the tag unique and it's not a timestamp of any resource. So
> I'm less concerned as to whether it can be construed very easily as opposed
> to moderately easily, and more concerned about brevity.
>
> Of course, brevity can be undone by long specific identifiers (not to
> mention long domain names) but I'd like to try to make brevity possible.
> The majority of tags will contain very short date strings like ";1" and
> ";2-3", thus making them that bit easier for humans to write and say to one
> another. Aesthetically, I just like the way that that those short strings
> are unobtrusive.

Sure, I like them too. But I don't like the message they give off. I, and I
bet others, on first seeing tags thought:

    ;1 -- hmm, an incrementing number? that's a dumb idea


I mean really, 2001-01-01 isn't that much longer. It would be even better if
you allowed just 2001 (as in tann).

> (I'm settling down to the idea of seeing a ';' in there but 'semi-colon'
> isn't very nice to say as compared to 'dot', 'dash' etc. 'Comma' would be
> phonetically nicer.)

Phonetically, I say "semi" as in "blargh dot com semi two zero zero one".

> I used the term 'tag' because literal tagging of physical entities is my
> original motivation. Linear barcode symbologies (like some other id
> technologies) aren't very forgiving when it comes to length. Yes, I could
> have special conventions for writing tags into barcode form, which would be
> converted into canonical tag form. But then we have things floating around
> that sort of are tags and sort of aren't. We went through a process of
> allowing multiple forms for tags but Sandro persuaded me not to and now I'm
> a true convert to that idea.

I agree, there should be one standardized format. And I must admit, that I
don't know much about bardcoding. However, it seems that it will require
special code and I think this code can deal with tags properly. (prepend
"tag:", etc.)

> I think you (and several others) are right that our motivations are less
> than convincing. In our defence, it's not that we specifically want to make
> it possible for just about everyone to use ";1" but that we think people
> would be sorely tempted to do that and we wanted to see if there was a
> valid way for that to be done.

Well, now that you've tempted us... ;-) But seriously, I think that
providing these abbreviation forms will be _more_ confusing. The other way,
we can just say that you can't do it altogether. Now, we have to provide
some complicated rules -- which I doubt will be properly followed. I
personally like the tann: idea of time markers slowly becoming less precise.

> I'm tempted to remove the use of unassigned authority names from the
> proposal. I also think we should consider removing the parts about putting
> hints in the specific identifiers, and how those who mint tags can declare
> their true identities (by using an appropriate authority name). It seems to
> have created more trouble than it was worth to make that explicit.

I'd have to agree -- these sections bothered me, and anything that makes the
spec simpler sounds good to me.

OK, after reading the spec more closely, one more thing pops to mind:

   Future
   standards efforts may allow use of such names following syntax that is
   disjoint from this syntax. To allow for such developments, software that
   processes tags MUST NOT reject tags on the grounds that they are outside
   the syntax defined above.

This sounds like a recipe for extensibility disaster. How about building
forward compatibility into the spec, by prefixing the authority component:

    tag:dns:aaronsw.com;2001-0-04/blah
    tag:email:me@aaronsw.com;2001-0-04/blah

I suppose a semicolon could be used for those also:

    tag:email;me@aaronsw.com;2001-0-04/blah

Then write into the spec that the type (email/dns) component can change,
rather than messing with the whole syntax.
-- 
[ Aaron Swartz | me@aaronsw.com | http://www.aaronsw.com ]

Received on Friday, 4 May 2001 17:33:51 UTC