[
Lists Home |
Date Index |
Thread Index
]
>In my experience, the words "as if" are often a signal that something is
>badly wrong in a spec.
I disagree. An "as if" description is often the most straightforward
way to describe something. The XML line end normalization description
is in fact a good example of this. The original 1.0 text said:
To simplify the tasks of applications, wherever an external parsed
entity or the literal entity value of an internal parsed entity
contains either the literal two-character sequence "#xD#xA" or a
standalone literal #xD, an XML processor must pass to the
application the single character #xA. (This behavior can
conveniently be produced by normalizing all line breaks to #xA on
input, before parsing.)
Unfortunately, it turns out that normalizing on input is *not*
equivalent to the conversion described, because of the possibility of
using character references in entities. So the spec was
contradictory. Furthermore the normalization-on-input version is the
one that most processor use. In an attempt to be declarative rather
than procedural, it instead was inconsistent.
> Saying that it behaves for some purposes as it it normalized them and
> for other purposes as if it didn't is a sure path to ambiguity, and a
> sure signal that the processing model has not been adequately defined.
But it doesn't say that, except maybe as a result of carelessness if
you agree with John. The intention is that it behaves as if it normalized
line ends on input, for all purposes.
>In all these cases the problems would be avoided by describing a
>processing model in which the stages of processing (of an object such as
>a stylesheet) are explicitly described, and constraints are defined on
>the object at a specific stage of processing.
Fine, but if these stages are internal to a process such as parsing,
there is no way for the user to tell whether it's implemented like
that or in some equivalent way. And in that case, there is no reason
to require it a particular implementation method (nor is there a way
to test it).
The only point of "as if" is to avoid prohibiting alternative,
indistinguishable, implementation methods.
I would prefer the whole spec to be wrapped in "as if", rather than
introducing it for specific points. The ISO C standard works that way.
-- Richard
|
