See also: IRC log
<MSM> http://www.w3.org/Bugs/Public/show_bug.cgi?id=4675
Resolution: Mark Bug Editorial as per notes in comment #30 in Bugzilla
<MSM> http://www.w3.org/Bugs/Public/show_bug.cgi?id=5306
Resolution: To change wording according to notes in minutes entered by Ginny and in comment #5 in Bugzilla
Pratul: The value for the version in an SML-IF version 1.1 MUST be '1.1'
MSM raises a question about the type of the version identifier
If you specify the type as 'token' you leave flexibility for future versions.
By requiring, for instance, that the version is a decimal we enforce an ordering.
<MSM> http://www.w3.org/XML/2008/01/sml-reference-constraints.xml
MSM: In processing elements to be considered for 'acyclic' there are three questions to be considered.
1. Do we recognize the elements in question by their name or by their type?
2. Constraints on target - target name, target type, target exists, or links acyclic.
3. How to refine the constraint.
In addition (4.) Where do we constrain the elements? On the element or on the types?
Break for Lunch
<MSM> [It's interesting that the type-oriented work-around Kumar just mentioned involves moving 'up' in the XML instance tree to the type of the parent element ...]
Sandy: allowing everything on both elements and types sounds like trouble: confusion, and harder to specify in the spec.
Sandy: A purely type-based approach ends up creating a lot of reference types, each with different constraints, but otherwise identical. That seems counter-intuitive to the idea that you use types to constrain the CONTENT, and other constraints to constrain usage. It's simpler to specify a single type, with different usage constraints depending on where it's being used.
Kumar: (earlier) moving acyclic to elements would be possible, but non-trivial, not easy. And it would be a breaking change.
Kumar: And adding the missing constraints so that all four can be done on both elements and types - that's more work than is compatible with project plans based on our original schedule.
MSM: concerned with inconsistency
(different constraints specified on different components);
heard that there were no user complaints.
... Can probably live with no change; can also live with
changing to be consistent, either all on elements, all on
types, or all on both elements and types.
... may prefer all on both; don't see all on type-only
happening.
Sandy: slight preference for what's currently in the spec; if we need consistency, strong preference on element-only.
Zulah: no firm position (will check with XML experts). can live with what's in the spec; can also live with all on element-only.
Kirk: originally want all on type-only; worry about consistency. suggest to have all on element-only and also leave acyclic on types.
Kumar: prefer no change; can live with all on element-only.
Jim: feels more right to have constraints on types; can live with any of the possibilities.
Valentina: prefer to no change, as there's no compelling use case; not very concerned with inconsistency. can live with all on element-only.
Ginny: prefer consistency; need to revisit the acyclic bug, which may suggest that acyclic should be on types. ordinarily prefer types over elements. with all information available, maybe we should leave the spec as is.
Pratul: will pick up bug 5379 first thing Tue. morning.
Ginny: Comment 1 in 5395 was
already fixed.
... suggest to repeat some information currently in 4.4 about
schemaComplete in section 5.
... a new subsection that provides definition of "schema
complete" and a normative definition of the schemaComplete
attribute?
MSM: is schemaComplete an assertion about whether all necessary schema documents are included?
Kumar: it's an assertion about sufficiency, but not necessarily necessity.
Sandy: don't think it's an assertion. it's a constraint on the validation process.
MSM: consider an undischarged
reference that's needed during validation. should it be allowed
(if schemaComplete is considered a constraint) or forbidden (if
it's considered as an assertion)?
... 3 cases -- which of these are legal if schemaComplete is
true? 1) missing needed component (hard failure), then no
assessment outcome 2) no hard failure 3) (e.g. lax wildcard)
validation succeeds with or without the additional
component
... #1 corresponds to the "constraint" view; #2 corresponds to
the "assertion" view, asserts that you will be able to complete
validation. #3 additionally requires that there's no additional
component that, when added to the schema, produces validation
outcome that has more information.
<MSM> [MSM offers alternative (but essentially equivalent) formulations:
<MSM> 1 no claim is made, schemaComplete just affects what counts as SML IF validation
<Kirk> s/requires/requires
<MSM> 2 schemaComplete affects what counts as SML IF validation, and additionally asserts that there will be no hard failures of reference (so validation can complete)
<MSM> 3 schemaComplete affects what counts as SML IF validation, and additionally asserts that there are no elements or attributes for which no declarations were found (except those matching a skip wildcard)
Sandy: 3 is not desirable,
because there are cases where lax wildcard is used and want to
allow the corresponding element not having a corresponding
global declaration.
... #2 may be difficult or impossible to check. consider the
strict wildcard case, if an element matching the wildcard has
no matching global declaration, then it could be caused by
missing component or caused by an instance error.
MSM: one possibility is to limit #2 to only explicit undischarged references (i.e. the strict wildcard case will not cause #2 to fail)
Sandy: according to http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/#conformance-missing, for the "hard failure" case, processors are not expected to abort/fail in the case of missing necessary components.
MSM: there is a useful
distinction between a schema that has no missing necessary
component and a schema that has. maybe schema should have made
this distinction (if it hasn't).
... but because schema 1.0 didn't provide this distinction, to
work with existing schema processors, it may be hard to require
this distinction.
... we need at least #1
... in the strict wildcard case, it's not possible to tell
whether it's missing component or instance error; this could be
expanded to all cases. fear that #2 is not checkable.
Ginny: if take #2 and schemaComplete=true, can use that to make the decision: assume that the schema is complete and the usage (e.g. instance) is in error.
MSM: then practically, no difference between #1 and #2. it's only a producer claim.
Ginny: a human can attach meaning to "schemaComplete", after model validation.
MSM: agree that schema assessment
can be completed, even with missing components.
... but we can provide a useful definition for #2. in PSVI,
error codes can indicate whether the error is caused by missing
components.
... definition for #2: when schemaComplete=true, 1) only use
schema documents in IF document, and 2) the 2 "missing
component" error codes can't appear in PSVI.
Ginny: can you get those errors
in any other way (than missing components)? if not, then
schemaComplete=true + these errors means the producer made a
mistake.
... because those errors can be caused by, e.g. typos, getting
those errors is not sufficient to blame the producer.
Sandy: 1) what additional information is obtained from #2? the error code is already in PSVI to be discovered. 2) there is no proof that existing schema processors produce error codes consistently. 3) assertions in IF don't really help. it's always up to the consumer to prove. if consumers can prove the claim to be wrong, then there's already info in the outcome about the claim, so it's not needed in the first place.
<MSM> 1 makes 'schema-complete' mean 'the schema you are going to use can be constructed completely from the schema documents in this package': 'complete' means the package is complete.
<MSM> 2 makes 'schema-complete' mean 'the schema you construct from the schema documents in this package is complete w.r.t. the needs of an attempt to validate these instances'. 'complete' means 'complete for use'.
Ginny: (earlier) it may be a big burden for producers to check whether schemaComplete should be set to "true".
<MSM> I think the meaning in (2) is more useful, comes closer to things that are going to be interesting in practice, than the meaning in (1). So defining 'schema-complete' that way means conformance to our spec will tend to be a more useful concept in practice.
John: what did people want schemaComplete to mean?
Sandy: #1. it's just an instruction. everything else (inter-op, producer's intention of schema completeness) is a consequence.
Ginny: close to #1, but also a statement by producer that if the packaged model is not valid it is not because of a missing schema.
MSM: something like 2 and/or 3, roughly "this package has everything you need or want".
Valentina: more like a hint, but could be wrong. it's "complete" as far as the producer knows.
Jim: these are the schemas that describe this model.
Kumar: think it was #1.
Kirk: treated it as a hint; didn't think it was connected to validity; so #1.
John: it sounds like everyone, coming in, felt that at a minimum, one thing schemaComplete (should) mean is "receivers must not need to consult sources external to the package".
John: does everyone agree with a minimal aspect of schema complete: when schema complete is true, a consumer performing model validation of the interchange set MUST NOT retrieve any schema components from outside the interchange set.
John: "must not" vs "does not" have to, which was Kirk and Ginny's understanding.
Kirk: now I have a clear understanding about "MUST NOT go outside is minimal requirement".
Kirk: agrees MUST NOT.
MSM: this same idea can be re-phrased as a definitional one. e.g. create a definition that says the process of doing model validation uses _this_ schema.
MSM: do we have a term for "a consumer performing model validation of the interchange set"? seems it's different from normal SML model validation.
RESOLUTION: introduce a new term, e.g. SML-IF model validation, for the operation "a consumer performing model validation of the interchange set"
MSM: bullet 1 in 5.3.2, suggest to replace "It MUST NOT be non-empty" with "It MUST be empty"
Sandy: base type ref global with {rules}; restriction has local. Should it be error (restriction violation) or inherit?
Kumar: we decided to say "error". possible rationale: "if base has refs to the same global; restriction has same-named local and ref to global, then difficult to ensure rules inherited by the local are the same as the ones specified on the global."
MSM: this sounds familiar. we
wanted to ensure consistency of rules for same-named elements
in the same content model.
... should also forbid the case when a local and a ref to
global (with rules) are in the same content model.
... now persuaded that the decision we made on Dec. 6 is good
(to mark the above situation as "error" and not
"inheritance".
... also suggest to move sub-bullets of 3 (in 5.3.2) into a
note. and replace "as" with "is".
<MSM> Also change "Consequently, it as an error if all of the following is true." to "Consequently, it is an error if all of the following are true."
RESOLUTION: adopt changes in comment #8 of 4644, with the above 4 amendments.
<MSM> 1 MUST NOT be non-empty -> MUST be empty. 2 move bullets into note, 3 as -> is 4 is -> are
Last Scribe Date Member Name Regrets pending 2007-08-30 Lipton, Paul until mid-January 2008 2007-12-06 Eckert, Zulah 2007-12-10 Smith, Virginia 2007-12-13 Wilson, Kirk 2008-01-03 Pandit, Kumar 2008-01-10 Popescu, Valentina 2008-01-17 Boucher, Jordan 2008-01-21 Lynn, James 2008-01-21 Gao, Sandy Exempt Arwe, John Exempt Dublish, Pratul Exempt MSM Exempt PH[End of minutes]