Subject: Re: Some editorial matters for -syntax-

From: Ted Hardie <[email-masked]>
Date: Tue, 1 Dec 1998 10:28:24 -0800 (PST)

Graham,
	Thanks for your quick response.  I've made some additional
comments in the text below.

> [...]
> >In 3.5.1, the description of substring matching as "not...relevant to
> >feature set selection" should probably be simplified to "Substring
> >matching (for tokens?) is excluded from these proposals"; there are
> >areas like hierarchical types where it might be relevant, but we don't
> >want to deal with them--so let's say that instead.
> 
> This paragraph was intended as an explanation of the first bullet point.
> I'm not sure that your proposal says anything that isn't already stated
> there.  I would be happy to delete that paragraph.

Deleting it seems fine.

[...]

> Or:
>  "Within the semantic framework described by this document,
>   Boolean-valued feature tests can be used where presence tests would
>   be used in a directory search filter."

This is much better than my text, thanks.

> >In 3.6, I would eliminate the phrase "suggesting an "ideal" option
> >that is equally or more preferred than any other"; the direction of
> >the 0 to 1 range has already been given, and this seems to muddy the
> >waters from that description.
> 
> The intent was to clarify the consequence of omitting ;q=x.  If it doesn't
> do that then it should go.

Sorry, I meant that the first part of the sentence should stay 
(indicating that the omitting ;q=x means  ;q=1), but that the
ending phrase "suggesting an ...." should go.    I think the
first part does illustrate the consequence of omitting ;q=x
and should be retained.

> Section 3 was intended to introduce the underlying concepts and ideas,
> before section 4 launches into the syntax specifics.  As I write, the
> forward referencing I have noted is a result of using the notation
> described later to illustrate some ideas.  I would prefer to play down the
> forward referencing but leave the material in the order given if that does
> not cause discomfort to other reasons.  Where forward referencing is used,
> I'm happy to make it more explicit.

More explicit forward referencing will help a lot, so don't worry
over-much about moving things around.  I was a bit worried to
suggest such a major change this late anyway.

> 
> I propose replacing the clause beginning ", but such registration is not
> necessary..." with a new sentence:  "Unregistered feature tags should be
> allocated in the URI tree, as described by registration procedure [3]"

Sounds great.

> >In 4.2.4.2, I fear that we may actually have to say the + or - sign
> >must precede the expression "n/m" so we are not later asked why we
> >allow "10/-2".  I realize that the very name "rational number" should
> >exclude this, but it's probably best to make it very clear.
> 
> I thought that it was clear from both the syntax and section 4.2.4.2
> (paragraph 2, 1st sentence) that the sign must precede both integers of a
> rational value.
> 
> If you still feel this needs emphasizing then I can add something.

Sadly, I do.  I agree that it really ought to be clear from several
other things, but it is the kind of thing that can't be emphasized
enough.

> >In 5.5, would is it clearer to say "comparable" rather than related in
> >the statement "(NE a b): 'a' is not equal and not related to 'b'." ?
> 
> If you think that's better.  What I really want to say is:
> 
>     'a' is not equal to, less than or greater than 'b'
> 
> but that seemed like a bit of a mouthful.

Everything I've come up with sounds a bit clumsy too, but we
have to be a bit clumsy here.  Below are a few attempts:

(NE a b): 'a' is not equal to or orderable with 'b'

(NE a b): 'a' and 'b' are not equal or orderable

or, if you think we can borrow bit further into the language
of set theory:

(NE a b): 'a' and 'b' are disjoint

Thanks again for all your work on this,
			best regards,
				Ted Hardie

---

From: Graham Klyne <[email-masked]>
Date: Tue, 01 Dec 1998 19:01:14 +0000

At 10:28 01/12/98 -0800, Ted Hardie wrote:
[...]
>first part does illustrate the consequence of omitting ;q=x

No, it's me who's not being clear here -- that's what I thought you meant.

My point here was that the extra clause was to underline the consequence of
defaulting to ";q=1".   If it doesn't do that then I agree it should go.  I
was just resisting a little because I felt that the point being made was
legitimate, if structly redundant.

To summarize, the present text is:

  In the absence of any explicitly applied quality value, a value of
  "1" is assumed, suggesting an "ideal" option that is equally or
  more preferred than any other.

I accept your observation that the phrasing, as given, is not crystal
clear.  The minimum text would be:

  In the absence of any explicitly applied quality value, a value of
  "1" is assumed.

An alternative, which repeats the point I wanted to emphasize here, might be:

  In the absence of any explicitly applied quality value, a value of
  "1" is assumed  (i.e. the corresponding option is as good as any other).

>other things, but it is the kind of thing that can't be emphasized

OK.  I propose adding a note at the end of section 4.2.4.2

    NOTE:  A rational number sign must precede the first integer.
    Thus, the following are NOT valid rational numbers:
        5/+1
        4/-2

[...]

In the interests of unambiguity, I think I should bite the bullet and make
a mouthful of it.

Unless you request otherwise, I shall accumulate these editorial changes
for an update to be published after the IETF meeting.

#g

------------
Graham Klyne
([email-masked])