[
Lists Home |
Date Index |
Thread Index
]
Henry S. Thompson wrote:
>The interpretation of the declarative language of the spec., which
>speaks about what is and isn't valid, in terms of control flow, is
>tricky at this point, I agree -- it requires a sort of
>backward-chaining through the prose, which then has to be "run" in a
>forward direction by an actual validator. With hindsight (which, as
>the saying goes, is often 20-20), we should have found a different way
>to express all this.
>
>The use of the word 'may' has to be understood in the context of that
>backward-chaining -- it ends up with full 'required to' force when
>takin in conjunction with other aspects of the definition of
>validation, expressed elsewhere in the REC. Having said that, the
>language isn't as helpful here as it should be, I agree.
>
Wow. I guess Henry should feel that Clinton's "It depends what you mean
by 'is'" to be
a reasonable answer, on the strength of that response! :-)
"may
Conforming documents and XML Schema-aware processors are permitted to
but need not behave as described."
Henry, in general, in the Structures rec, does "may" mean
"this is one of the allowed behaviours, depending on the
applicability of other sections"
or
"this is the default behaviour, unless other sections apply"
or
"this is an optional behaviour, depending on the implementation or
configuration"
I have always assumed that recommendations would only ever
use the last, in particular because the others (especially the first)
require the user to have checked through all other statements
before they can interpret the current statement, which is pretty
intenable.
I think Dare is acute for noticing this "may": perhaps
the definition of may needs to be changed to reflect a need for
backwards-chaining the whole recommndation before relying
on any part, or some other phrase instead of "may" should be adopted.
Do other W3C recommendations use "may" in the same way?
Cheers
Rick Jelliffe
|
