- From: <bugzilla@wiggum.w3.org>
- Date: Tue, 02 Sep 2008 17:36:54 +0000
- To: www-xml-schema-comments@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=6010
Noah Mendelsohn <noah_mendelsohn@us.ibm.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |noah_mendelsohn@us.ibm.com
--- Comment #1 from Noah Mendelsohn <noah_mendelsohn@us.ibm.com> 2008-09-02 17:36:54 ---
John Arwe wrote:
> 3.3.4.6 Schema-Validity Assessment (Element)
> - fallback to lax validation
> SML found it necessary to specify fallback
> to lax validation in its specs
> because Schema 1.0 had not done so.
and
> I'm not sure what the actual boundary for
> 'defined' is nor how interoperable its
> definition really is.
I confess to finding it a bit odd to see these two comments sitting so close
together, as LAX validation depends on a notion of which elements are "defined"
that's pretty much the same as what's proposed for wildcards. In the case of
LAX, if the element is defined, it's validated. In the case of #defined
wildcards, it's disallowed.
> A schema processor is allowed to put almost
> literally anything (extra, i.e. unused) into
> the schema (set of components) used for
> assessment, no?
Yes, although it's assumed that the processor chosen for a particular
application will or won't do such things according to the application's needs.
Most general purpose processors will use only those components that directly
result from the XSD files provided. By contrast, an HTML editor (to pick an
example) might use a customized incremental validator that had built in
knowledge of the XHTML schema.
More to the point, the recommendation is very clear that assessment depends on
knowing what the schema is, I.e. which components comprise it. Once you know
that, you know which elements will be validated during lax assessment, and
which ones would be disallowed by a #defined wildcard.
Noah
--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Tuesday, 2 September 2008 17:37:28 UTC