[
Lists Home |
Date Index |
Thread Index
]
"Dare Obasanjo" <dareo@microsoft.com> writes:
> This seems to contradict the quote
>
> "lax If the item, or any items among its [children]
> <http://www.w3.org/TR/xml-infoset/#infoitem.element> if it's an
> element information item, has a uniquely determined declaration
> available, it must be ·valid· with respect to that definition, that
> is, ·validate· where you can, don't worry when you can't."
How's the contradictory -- note this is in contrast to "don't
validate" on the one hand (skip) and "validate where you can, error if
you can't" (strict).
> Reading the spec, I find it hard to see how your quote from is said
> to apply specifically to wildcard declarations where processContents
> is lax. I also note the use of the word "may" in the quoted excerpt.
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.
I can't quickly check, but are you saying the the MS schema validator
_doesn't_ recurse after matching a lax wildcard?
ht
--
Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
Half-time member of W3C Team
2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
Fax: (44) 131 650-4587, e-mail: ht@cogsci.ed.ac.uk
URL: http://www.ltg.ed.ac.uk/~ht/
[mail really from me _always_ has this .sig -- mail without it is forged spam]
|
