See also: IRC log
RESOLUTION: approved
Pratul: Kumar sent an email to the member list with the working group's position; any objections or changes to this?
Sandy: ok but would prefer to reword 2nd to last paragraph - "we expect..."
Pratul: extending schema is part of our charter
Kumar: should we add a sentence to reflect this?
Pratul: our core scenario is extension of schema
Kumar: can also add that we don't want to block DTD
<Kumar> The SML group's charter is to standardize extensions to the XML Schema, therefore the group's focus is on supporting scenarios where XML schema combined with Schematron rules is used to validate a model. However, the group recognizes that there may be some cases where XML schema is not used at all. The group does not want to go out of the way and forbid such cases.
<Kumar> SML constraints can only be specified as a part of XML schema. When model has only DTDs, there cannot be SML constraints present. This is not the mainstream use-case for SML models. We expect majority of SML models to include XML schemas (with or without SML constraints) because XML schema validation is an integral part of SML model validity assessment and XML schemas are the only means of defining SML constraints. Due to implementation
<Kumar> and schedule constraints, we would like to allow but not require DTD ID support for this case. We believe this will have minimal impact on the users of SML because most SML models will use XML Schemas for validation.
RESOLUTION: Working group agrees to changes as suggested by Kumar above. Kumar to send update to public email list.
RESOLUTION: mark bug as fixed
<johnarwe_> looks fine to me
RESOLUTION: mark bug as fixed
RESOLUTION: mark bug as fixed
<MSM> +1 to SG's implicit proposal
ginny: +1
<johnarwe_> the implicit proposal being to add a similar stmt for nilref wrt psvi as we currently have for sml:ref
RESOLUTION: make proposed change; mark editorial, no needsReview
Sandy's proposal is "both <namespaceBinding> and <documentAlias> should be '*', that is
minOccurs=0, maxOccurs=unbounded."
Pseudo-schema and normative schema must be changed to agree with this proposal.
RESOLUTION: make proposed change; mark as editorial, no needsReview
<MSM> [I think also it's convenient to have an explicit no-binding construct so that I can have a default schema binding for most documents, but still exclude a few documents by saying "no schema for this one"]
If a processor does not process schemabindings then no change is necessary with this proposal.
Proposal is to "add a new <noSchemaBinding> sub element under <schemaBindings>.
It contains any number of <documentAlias> elements. If an instance document
matches one of the <documentAlias>, then the default schema doesn't apply to
it."
Kumar: if a model contains instance doc a, b, c then it is not possible to specify that c is not bound to a schema?
SML-IF states that "If an SML-IF consumer chooses to process the schemaBindings element and if the
optional defaultSchema element is present, then an SML-IF consumer MUST
compose a default schema from this element following rules 1 to 3 above,
replacing SB in the text with DS (i.e., the /model/schemaBindings/defaultSchema
element). Otherwise, an SML-IF consumers MUST compose a default schema using
*all* schema documents included in the SML-IF document. An SML-IF consumer MUST
use this default schema to validate those SML instance documents that are not
included in any schemaBinding."
discussion of whether the 'otherwise' applies to 1st 'if' on previous sentence or to both 'ifs' in previous sentence.
<MSM> One alternative: "If the consumer does not process schemaBindings, OR if the optional defaultSchema element is absent, then ..." (this is equivalent to what JA just said.)
Proposal now has 2 parts: the noSchemaBinding element and rewording the 'otherwise' as above.
<MSM> [I think leaving to the editors the choice between the alternative above and "Otherwise (if ... or if ...)" is the Right Thing. Editors, work it out.]
Proposal is: 1) to "add a new <noSchemaBinding> sub element under <schemaBindings>.
It contains any number of <documentAlias> elements. If an instance document
matches one of the <documentAlias>, then the default schema doesn't apply to
it." and 2) reword 'otherwise' per John's and MSM's comments above
RESOLUTION: fix as proposed; mark editorial then needsReview
Proposal is: "2a For each XML Schema document in the model's definition documents, the
[validity] property of the root element MUST be "valid" when schema validity is
assessed with respect to a schema constructed from the "schema for schemas" and
the "normative SML schema" schema documents.
2b All schemas assembled from the XML Schema documents in the model's
definition documents MUST satisfy the conditions expressed in Errors in Schema
Construction and Structure (ยง5.1). [XML Schema Structures]
Note: This specification does not define how many schemas are assembled and
which schema documents contribute to assembling the schemas."
(Replace bullet 2 with proposal above.)
RESOLUTION: fix as proposed; mark editorial and then needsReview
Sandy: if there is a problem in the 'metadata' then the model should be non-conformant.
as opposed to invalid.
Ginny: seems to be the general consensus
The general case references the sections labeled "schema component rules" and "schema constraint construction" and "SML Rule Consruction". We can construct the general conformance statement referencing these section titles.
RESOLUTION: fix per proposed using the general case of the section titles as mentioned above; mark as editorial and then needsReview
Proposal is: ""1. In each instance document in the model, the [validity] property of the root
element and all of its attributes and descendants MUST NOT be "invalid" when
schema validity is assessed with respect to any schema that is bound to this
instance document. [XML Schema Structures]
Note: How schemas are bound to instance document is not defined by this
specification. Multiple schemas may be bound to the same instance document.""
<johnarwe_> http://www.w3.org/Bugs/Public/show_bug.cgi?id=5797 is related
<MSM> I don't want to insist or even suggest that everything be done at once, only to make sure the editors don't inadvertently overwrite one change while making the other.
John: This bug intersects with 5797 with regard to the non-normative note.
RESOLUTION: fix as proposed; mark editorial and then needsReview
Last Scribe Date Member Name Regrets pending 2008-05-22 Lynn, James 2008-07-10 McCarthy, Julia 2008-07-17 Gao, Sandy 2008-07-24 Wilson, Kirk 8/14, 8/28, 9/4 2008-07-31 Kumar, Pandit 2008-08-07 Smith, Virginia 9/4, 9/11 Exempt Arwe, John Exempt Dublish, Pratul 8/28 Exempt MSM 8/14