Re: more 3028bis comments

[Ned Freed <[e-mail]>]

> On Wed, Jul 06, 2005 at 12:31:40PM -0700, Ned Freed wrote:
> > > > > > The 'variables' extension has to specify greedy/non-greedy ":matches" ;
> > > > > > this really ought to be in 3028 so that extensions can consistently
> > > > > > follow whatever rule there is; although, again, it might fail the
> > > > > > "non-substantive" test.
> >
> > > > > I don't think this behaviour description is relevant for the main spec.
> > > > > it can not be observed without the variables extension.
> >
> > > > Yes, exactly so. This could easily come back to bite us when we need to move to
> > > > draft.
> >
> > > sorry, I'm dense.  are you agreeing with Mark or with me?
> >
> > With you.
> >
> > My worry here is that requiring non-greedy in the base specification is, as you
> > put it, requiring nonobservable behavior that cannot be externally verified.

> The issue I had in mind was that of setting precedent; now that we know
> that an extension wants to define the greediness behaviour, it seemed to
> me that it would have been best to have that precedent set in the base
> document.

I disagree. It is far more important that specifications specify the minumum
necessary and not specify stuff that cannot be verified externally.

> Otherwise, unrelated extensions could simply state what
> behaviour they require, with one contradicting another.  I imagine that
> in practice this would be unlikely; precedent set by one extension is
> likely to be followed by another.

And to the extent it possible for one specification to contradict another, it
is also possible for an extension to unwittingly contradict the base
specification. Irrespective of the liklihood of such a contradiction occurring,
the increased likihood of it happening because of the location of one of the
contradictory statements is bound to be marginal.

> Nevertheless, since we know that this
> definition is needed by an extension, it feels much better to me to
> specify it in the base document.  So I'm looking for neatness more than
> anything.  Also, having it there, even if the behaviour is not visible,
> makes it easier for an implementation coded to that specification to be
> able to support extensions that do make it visible.

But it may make it harder to advance the base to draft. And advancement to
draft is what we're supposed to be focused on per the charter.

> > When documents go to draft we at a minimum will have to write up a list of
> > conformance criteria and then make sure we have enough conforming
> > implementations. Including non-observable criteria on the list means that
> > the only person who can submit information about a given implementation
> > is someone able to see the code for that implementation. This would have
> > been a problem for several past conformance list exercises.

> I too am probably being dense... but in another message you said, regarding
> the CRLF/CR/LF wording:

> > I see no "MUST generate an error" clause here, so as far as I'm concerned the
> > handling of bare CR and bare LF means you have a nonconformant script, but how
> > implementations handle this particular form of nonconformance is undefined.

> which seems to be somewhat opposite reasoning, justifying the
> specification of something entirely on the basis that nonconformance
> can't be observed.  I'll probably reply to that separately, tho.

First, it is axiomatic that conformance criteria only apply to defined
behavior. Undefined behavior cannot be something you test conformance to.
Second, advancement to draft involves checking for sieve implementation
compliance; the existance or nonexistance of incompliant scripts in the wild
isn't particularly relevant unless, I suppose, it could be shown that all
scripts out there are incompliant.

				Ned