Re: more 3028bis comments

["Mark E. Mallett" <[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.  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.  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.

This may or may not be outside the charter; again it's just something I
wanted to bring up while it's possible to talk about it.


> 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.

mm