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