Re: Rewrite of feature tag syntax rules

Larry Masinter:
>
   [Koen Holtman:]
>> Yes.  But feature tags are not ASCII strings just because it is easier
>> for `debugging and programming'.  The authors of negotiable content
>> will have to type in feature tags when making variant lists, and these
>> authors will generally not be programmers. Even worse, end users will
>> in some cases look at feature tags in variant lists when deciding
>> which variant to get (though one would hope that variant list authors
>> use {description xx} a lot).
>
>Koen, it's quite evident that you're trying to solve a different
>problem than I thought you were trying to solve. So I guess
>we need someone to actually work on the problem we established
>originally, which is how browsers and servers might automatically select
>the "tuned for Netscrape 12.7" pages when running "Netscrape 12.7"
>but not requiring some new browser to write "User Agent: Netscrape 12.7
>(compatible)", and deal with expressing preferences for content
>tuned for different kinds of screen resolutions, devices, etc.,
>when such negotiation is necessary.

Yup.  Well, I already solved this content negotiation problem, and the
solution is in the drafts.  As far as I am concerned, the solution
works, Code Has Run, etc.

What I am doing now is _revising_ the syntax of one component of the
solution. I'm revising the feature tag syntax to get closer to other
metadata formats.  People have told me, both in Memphis and at www6,
that it is important to them that TCN does not introduce more
divergence in metadata formats than it has to.

Maybe you were unaware of these concerns about diverging metadata
formats, or think that they do not apply, but as the ID author I have
to handle them.

>However, you're description above has the client actually
>presenting the feature tags (not some textual description
>of the feature tag, but the feature tag itself) to the user.
>This is nonsense.

The draft requires users to be able to review variant lists, and these
have feature tags in them.  This will not be common, but it will
happen.  Of course, as you correctly point out, this won't happen in
the normal case:

> If the server wants the user to select among
>many different representations, the server can send the user
>a page with links to the different representation. "Choose Frames", "No
>frames". Of course, pages in French might say that in
>French, instead. Unless you want to also require that feature
>tags written in different languages be marked as equivalent,
>it doesn't work.

I'm actually not very concerned about end users understanding tags.
The main consideration is that _authors_ will want to write these
tags.  Many authors write HTML tags and URIs by hand, and the same
will be true for feature tags.

>> So feature tags have a very wide human interface.
>
>Any design that requires that is a bad design.

Any feature tag design which does _not_ make it easy to write feature
tags by hand, and makes it easy to remember the most common tags, is a
bad design.

>Feature tags should be similar to, but orthogonal to,
>the space of Internet Media Types; 

That is what I am aiming for.  If I made it appear differently, then
this is bad writing on my part.  Note that authors (cgi authors) write
media types by hand too.

[....using URIs as feature tags....]
>> I agree it is cute, maybe too cute, but the W3C seems to be firmly set
>> on this course (not just in PEP, it also pops up in some Cougar stuff,
>> for example).  I feel we will need to have _very_ good reasons to go
>> out of sync with the W3C's approach.
>
>"Voodoo design" is the practice of making what you're designing
>look like some other design even though the function and purpose
>of the designs are different.

I think feature tags and PEP extension identifiers serve pretty much
the same purpose: they identify something which is the subject of
negotiation.

In fact, this is the one overlapping area I _do_ see between PEP and
TCN.

But if you don't think so, then let us agree to disagree.

[...]
>I think that feature tags should be handled using the same
>(not just similar, but the same) mechanism used for media type
>registration: register with IANA under various 'trees', establish
>an IETF tree for those things that are standards track, and
>a vnd. and pers. and x. tree for vendor, personal, and experimental,
>respectively.

Noted.

Let me try to summarise the current situation with my ID editor hat
on: 

The idea of merging the PEP extension identifier and TCN feature tag
namespaces is not liked by many people on this list, because they
think that using URIs in feature negotiation is a bad idea.

On the other hand, in Memphis and at www6 some people have told me that
they like to see a merger of these spaces.

I'll do a call for opinions to see which course to follow.  I'd be
happy to revert back to the old scheme: that would even mean less work
for me (and my co-editor).

>Regards,
>
>Larry

Koen.

Received on Monday, 19 May 1997 12:43:16 UTC