RE: Permit (greedy) conflicting wildcards (NIS wildcards)

Michael Kay wrote:
> Noah Mendelsohn wrote:
>> Nonetheless, it was because we realized that some users would want 
>> more help from the content model itself that we are likely to propose

>> the notQName="##defined"
>> construct (which, by the way, is known informally in the workgroup
and 
>> in some blog postings I think as the "Not In Schema" or NIS wildcard.
>
>The thing I'm having trouble understanding is that this seems to assume
a rather finite 
>and predictable schema. It seems to make the outcome of a validation
episode rather 
>dependent on the set of element declarations that happen to be lying
around in your schema 
>cache. Validation of a document containing @xml:space will succeed
until you install a new
>version of your schema processor that has a built-in attribute
declaration for @xml:space, 
>and then it will suddenly start failing because @xml:space is now in
"the schema".

When NIS wildcards were first proposed, I argued this exact point:  that
validation outcomes could vary widely through seeming side-effects
difficult to track in the validation environment.  However, after
understanding the utility of the feature to groups involved in WS
languages (and the extension of those languages), and also understanding
how >I< might use the feature in the languages we try to create at NACS,
I became a convert.

Note that one important caveat that helped change my mind was
understanding that most of the time the feature would be used as "in
this namespace but not in this schema," (e.g. the WS namespace)
effectively limiting the area where the dreaded side-effects might
occur.

Best regards,
David