See also: IRC log
MSM: sees this as a trade off in design vs. practicality. He is willing to let this go and remain with the current proposal.
Ginny: Based on the acyclic document, she doesn't think its a good idea to move acyclic to elements. Votes to leave this as-is.
Sandy: said in minutes that he had a slight preference for the existing spec. And if we had to change for consistency, he would move to all on elements.
johnarwe: Sounds like consensus. Does anyone object to not changing what the spec says for bug 5379.
MSM: would like to suggest that we close this as WONTFIX
johnarwe: Is it the consensus of the group that closing 5379 as WONTFIX is the current tradeoff for resolving this bug?
RESOLUTION: close bug #5379 as WONTFIX
Valentina: suggests adding rationale for decision into spec
There were multiple suggestions that we leave the rationale in the bug and minutes
johnarwe: Does anyone object to not adding the rationale to the spec?
<MSM_> [Minutes of yesterday: http://www.w3.org/2008/01/21-sml-minutes.html]
RESOLUTION: The rationale will not be added to the spec
Ginny: Section 1, this sentence "SML uses
XML Schema [XML Schema Structures, XML Schema Datatypes] to define
constraints on the structure of data in a model." is redundant with the
content above it at the line stating with "1. Schema". Wants to remove
the sentence (which is 3 paragraphs or so below the sentence that
starts with "1. Schema".
... Section 2.2 Terminology. In the definition of "Rule bindings", the
definition implies that you can have schematron rules on schema
documents? Is that correct?
agreement that this is correct
<MSM_> scribenick: MSM
We discussed several points raised by Ginny and John, deciding whether to open issues for them or not.
- Is it a problem to have Schematron rules that apply to schema documents?
- Do we really want separate sml and smlfn namespaces?
Probably; no consensus for change. Advantage to having smlfn namespace for deref is that specs wishing to refer to it and implementations using it can simply import/refer to the entire ns without bringing in other things they don't need(to the refer-ers, "clutter").
- Sec 4.1.2 "SML Null reference" and "resolved SML reference" and "unresolved SML reference" seems non-parallel. "null SML reference" ? (yes)
- Sec. 4.2.1 "then the model MUST be dclared invalid"
Longish discussion of 4.2.1.
Sentiment in favor of changing all places (e.g. including 4.2.2) where the spec says "... must be declared invalid" to make them impose positive requirements on models
Sentiment to remove the second sentence of 4.2.1 (as redundant with first sentence); discussion of deref() function will need to be clear about relation of validity to deref().
In section 7, either (a) add a specific clause referring to satisfaction of the reference semantics, or (b) replace most of the definition with a blanket statement that conforming SML models must satisfy all of the normative constraints applicable to models in this spec.
If (b), then probably also move the existing specific list of particular constraint classes into a Note (it's useful, even if we want the normative statement to be a broader blanket statement).
<MSM_> scribenick: zulah
Section 4.2.3. Question is, as written, this applies
only to model validators. Not sure that we want to restrict this
section to only apply to model validators vs. things that are doing
something narrower in scope.
... we also have the name "model processor" with no definition.
Suggests that we remove the term "model validator" from section 4.2.3
Kumar: if we remove model validator, it will require every processor to do this. If it is there, it does not preclude others from following the rules
Sandy: suggests that we go through spec and ensure that model validator is changed to read "this must be true (period)" and model processor similarly. Essentially rephrase in terms of requirements on the data and then requires all model validators to comply with all reqts in the spec when there exist (separate) behavioral requirements.
MSM: question is whether we are talking about a property of the processor or the data. Should not talk about property of the data by specifying what a processor should do.
Group sentiment is that this is covered by the previous bug.
ginny: Section 4.2.4, is it necessary to say "and/or be expressed in different ways"?
MSM: If we leave this out then, then we have the issue that we don't cover the case where the same scheme can be expressed in multiple ways.
johnarwe: suggests that we add in section 4.2.3, that a single element can be targeted by multiple reference scheme instances... In general, thinks that at minimum this text belongs in the reference scheme section.
Proposal is to remove the text "and/or be expressed in different ways" or the entire containing sentence and placing similar text in Section 4.2.3.
ginny: Section 4.2.6, sentence starting "In particular, for each node..." interpretation issue
If you need to know order or which derefs fail for example, then you need to use
ginny: same section, if deref doesn't attempt to resolve any scheme, then no target is returned. So you can have an empty deref function that satisfies this.
The group didn't feel strongly that the latter needed to be outlawed.
The group feels that the section is correct.
node-set is a well defined XPath term
MSM: In #2, there may be an opportunity to clarify in the body of section #2
Sandy: We iterate over references and then for each over schemes.
MSM: suggests adding, for a-e, "for each reference node in the input-set"
A bug will be opened
ginny: 4.3, in #1, the phrase "one and the only"
Group has previously adopted a proposal to fix. This is in bug 4992.
Section 4.3.1
ginny: wants to move #2 after #4.
suggestion that #4 could be before #1 and not part of the three rules.
Sandy: if we move the syntax to be before the rules for recognizing the scheme, this could cause confusion. You first recognize the scheme and then check if the syntax is correct. Suggests #4 be included in #2.
johnarwe: Section 4.3.1, #1 Define the smlxpath1() scheme. What have we done about registration and at what point in the process would we do this?
<scribe> ACTION: Kumar will register the smlxpath1() scheme [recorded in http://www.w3.org/2008/01/22-sml-minutes.html#action01]
<trackbot-ng> Created ACTION-157 - Will register the smlxpath1() scheme [on Kumar Pandit - due 2008-01-29].
Section 4.4
johnarwe: In 4.4.1.1, #3 is not consistent with text in 4.4 "The value of {acyclic} for xs:anyType is false"
Sandy: These are talking about different things and the spec is correct as is.
Section 4.4.1
ginny: first sentence.
johnarwe: suggested rewording in bug 5399
... Section 4.4.1.3. bullet #2, Should this be read to mean that
documents always end up being the nodes in the graph.
johnarwe will open a bug for the question
<MSM_> [w.r.t. table 4-2 at end of 4.4.3: could we tweak the stylesheets to get some padding into those cells and give the words a little more room to breathe?]
johnarwe: table 4-2 in section 4.4.3, the table is non-normative. two questions (1) it does say what "Check" means, (2) for the non-reference row does not see where the "Satisfied" values followed from instance validity rules.
MSM (attempting to channel Sandy): There is an "if" here, if I satisfy these things then valid, should this be an "iff"?
suggestion that we should make the table normative. That this would resolve any potential confusion.
Sandy: Similar issue in other sections Section 4.5.1.2 #4
MSM: blanket rule (if we didn't say anything, we didn't mean anything) is probably better than having to explicitly say this in all appropriate places in the spec.
<Kirk> scribe: Kirk Wilson
<Kirk> scribeNick: Kirk
John: Review of previous discussion
... "logicians" analyze this as if A then B. And there is an
inconsistency with the table and that inconsistent must be resolved.
... others were arguing about what we were defining. See definition of
conformance in section 7. When A is false, no normative condition in
the text has been violated regarding validity. Thus, the model would
still be considered valid.
... Thus, first row of table is irrelevant to validity
Jim: If rule doesn't apply, then it has been satisfied.
MSM: If A then x must be y.
...rephrase: It must be the case that if A then B (B = x does y)
Just that statement (If A then B) is true when A is false.
John: We will take the discussion off line. Disagreement as to whether If A then x must be y, then it is OK without change of meaning to say "It must be the case...."
MSM: If we had something more explicit, readers wouldn't have to replicate this discussion. We need something more explicit so readers don't end up arguing about Boolean logic.
John: could clauses 2 and 3 be
conflicting?
... Conflict= different identity constraints because of groups with
same names.
Sandy: We can't have the same name because they are in the same symbol space.
Ginny: Do we need parentheses around expression?
MSM: Don't need, but won't hurt.
Ginny: And Kumar, we should use parentheses. Sandy adds further instances where parentheses might be used.
MSM: Kill word "User defined". Just say Constraint can be specified.
John: This is not implementation-dependent. It is in the SML-IF text.
Sandy: This is one level below binding in SML-IF
<scribe> ACTION: Virginia to open bug on sentence before 5.2. Regarding use of word "binding". [recorded in http://www.w3.org/2008/01/22-sml-minutes.html#action03]
<trackbot-ng> Created ACTION-158 - Open bug on sentence before 5.2. Regarding use of word \"binding\". [on Virginia Smith - due 2008-01-29].
Pratul: There is no sense of binding in Schematron
John: It is the syntax of the binding that is implementation-dependent.
Sandy: Two inconsistencies around
rule-binding.
... What is binding between: documents (in definition) vs.
patterns/elements.
Kumar: Binding is between documents.
Sandy: This definition will not work in the example we were looking at.
Pratul: One action: take out sentence.
Kumar: We should delete statement and say that this binding is outside scope of SML.
Ginny: "Conforming Profile": is this defined in Schematron? XSLT is the default, this is not a profile.
Pratul: No it doesn't; in fact, we support full Schematron.
John: No objection to taking out the entire paragraph.
Kirk: There are other mentions of Schematron Profile
<scribe> ACTION: Virginia to open bug to remove the word "profile." [recorded in http://www.w3.org/2008/01/22-sml-minutes.html#action04]
<trackbot-ng> Created ACTION-159 - Open bug to remove the word \"profile.\" [on Virginia Smith - due 2008-01-29].
Ginny: Check on "conforming implementation"
Sandy: Replace "conf imple" and other equivalent phrases with a common term.
Ginny: Use "conforming model validators"= model validator conforming to spec.
Sandy: Just use "model validatotrs."
Sandy: Answered in bug 4664.
John: 5.3.2 #3 vs. 5.3.3 #3: Does second statement imply an ordering for the unioning.
Sandy: Problem with "set of" in 5.3. Replace "set of" with "sequence of". Rules have to be ordered.
Kumar: Rule property consists of Schematron constraints--rules are deeper in the Schematron hierarchy.
Sandy: We should change the name of the property.
Pratul: We should leave the name of property. We should be explicit about referencing Schematron rule.
Ginny: In 5.3.3. #3 Capture Schematron rules. Then Schematron rule are defined by schematron elements.
Pratul: The definition of "rule" is weird.
MSM: We refer to our own rules.
... We want to define rules; concretely we do it using Schematron rules.
... The word is overloaded.
<scribe> ACTION: Virginia to open bug on the clarification of rule; eliminate the definition. [recorded in http://www.w3.org/2008/01/22-sml-minutes.html#action05]
<trackbot-ng> Created ACTION-160 - Open bug on the clarification of rule; possibly eliminate the definition. [on Virginia Smith - due 2008-01-29].
MSM: Last sentence in 5.3.3. item 3: We
say order of schematron rules, which is what Schematron says. Order of
the evaluation of Schematron constraints is not constrained. We should
say that.
... Should say that it is implementation defined.
Ginny: Take out statement that says: "As Schematron defined".
Kumar: Preference to keep it there
<scribe> ACTION: Ginny to open bug on how we should consider Schematron [recorded in http://www.w3.org/2008/01/22-sml-minutes.html#action06]
<trackbot-ng> Sorry, couldn't find user - Ginny
John: Followed up with Ginny 2/6 to ensure this comment and action were not lost.
Sandy: We have no links for rules. Also, if we keep bullet 3, then use Schematron prefix for elements.
John: First, 5.3.1, second, 5.3.2 #1, and thirdly, Section 6 bullet #2: Should these places be consistent?
Sandy: First and Third of these need to
be consistent.
...Second: This is different because it is at the component level.
Inheritance.
John: 5.3.2 #1: "global element declarations schema component,"
Sandy: This is difference betwen syntax and component. Other places refer to xs:element for syntax.
<scribe> ACTION: John to open bug to distinguish syntax vs. component use of "GED". [recorded in http://www.w3.org/2008/01/22-sml-minutes.html#action07]
<trackbot-ng> Created ACTION-161 - Open bug to distinguish syntax vs. component use of \"GED\". [on John Arwe - due 2008-01-29].
MSM: 5.3.1 turns out to be about
components.
... in 6 bullet 2, use XSD syntax, but Sandy has misgivings: 5.3.1 and
6 should be consistent.
John: Why is this the case?
Discussion of the meaning of this constraint and LocID attribute.
Sandy: LocID is specified on the element that has textual content.
John: Remove the constraint regarding schema.
Sandy: Also remove "containing textual content".
MSM: Could eliminate rule 3
<scribe> ACTION: Valentina to open bug on clarification of rule 3 and use of LocID. [recorded in http://www.w3.org/2008/01/22-sml-minutes.html#action08]
<trackbot-ng> Created ACTION-162 - Open bug on clarification of rule 3 and use of LocID. [on Valentina Popescu - due 2008-01-29].
John: We need discussion as to scope of this correction. Do other bullets need similar correction?
<scribe> ACTION: John to open bug to make correction for this item. [recorded in http://www.w3.org/2008/01/22-sml-minutes.html#action09]
<trackbot-ng> Created ACTION-163 - Open bug to make correction for this item. [on John Arwe - due 2008-01-29].
John: item #5: "X must be true, but in one corner case, behavior is implementation-defined." This seems to be strange.
Sandy: Move bullet 5 to before the final set of numbers.
MSM: All documents must be available to test validity. "Gray area" regarding normativeness.
Kumar: If not reachable, behavior is implementation-dependent.
MSM: We talk about what is required to determine validity, and then talk about the meaning of validity.
<scribe> ACTION: John to open bug regarding reorg to handle bullet #5 in section 7. [recorded in http://www.w3.org/2008/01/22-sml-minutes.html#action10]
<trackbot-ng> Created ACTION-164 - Open bug regarding reorg to handle bullet #5 in section 7. [on John Arwe - due 2008-01-29].
Ginny: What is "Explicit Reference"? Ginny has sense of group.
Ginny: What behavior is implied here? Actions are specified in 5.3.3.
John: We should refer to the section for clarification.
Sandy: We have a bug on this.
John: Read this to mean "retrieve"?
Ginny: We now say, validator may ignore a
referenced document.
... ISSUE: Relationship of this to the discussion of schemaComplete.
MSM: This is a confusion. Sandy/Kumar not
a confusion.
...ISSUE: SHOULD/MUST discussion regarding decision to not locate the
document.
MSM: Should be a MUST
Sandy: This should still be a SHOULD, but it really doesn't matter much (Zulah agrees.)
John: Any objections to leaving text as
is.
... No objections, but MSM wishes to record his concern.
MSM: Supports having this kind of section.
Discussion of current/past members in Acknolwedgement
MSM: At publication time, editors look at IP list.
<ZULAH> Zulah thinks that the previous issue should have been a MUST but can live with a SHOULD and agrees with Sandy that this doesn't matter much.
John: URI vs. URI Reference. should use them carefully and as defined in RFC 3986
John: Is default Schema optional? Sandy:
Response Yes
... Rules for default Schema follow rules above, but these rules
reference a different parent. Variable SB must be bound to default
Schema.
... Why say consumer MUST generate default schema?
Ginny: Consumers may choose to ignore.
Sandy: "MUST be used" => "is used"
John: Use "the processing of default schema is as follows:"
<MSM> MSM's proposal for the defaultSchema paragraph:
<MSM> Change
<MSM> If defaultSchema is present, then an SML-IF consumer MUST compose a
<MSM> default schema from this element following rules 1 to 3
<MSM> above. Otherwise, an SML-IF consumers MUST compose a default schema
<MSM> using *all* schema documents included in the SML-IF document. An
<MSM> SML-IF consumer MUST use this default schema to validate those SML
<MSM> instance documents that are not included in any schemaBinding.
<MSM> to
<MSM> If defaultSchema is present, then the default schema used for SML-IF
<MSM> model validation is composed from this element following rules 1 to 3
<MSM> above, with the defaultSchema element as the value of SB. Otherwise,
<MSM> the default schema is composed using *all* schema documents included
<MSM> in the SML-IF document. When performing SML-IF model validation, an
<MSM> SML-IF consumer MUST use this default schema to validate those SML
<MSM> instance documents that are not included in any schemaBinding.
John: Assuming that we get agreement on substantive issues recognized today, are people comfortable with going to LC?
Pratul: There is no known substantive issue.
John: Discusses flow of going to LC. (See Process Document)
MSM: Encourages us to contact WG chairs
for related WGs to get schedule of their review. This is just the
Schema WG.
... Regarding getting back to commentators: We must place resolution in
the bug to ask for agreement/disagreement with originator. We need
boiler-plate text.
John: Once we go to LC, we must think and act more carefully about audit trail.
MSM: Candidate Rec is a Call for
implementations.
... Identifying Features at Risk: alert reviewers to consider what spec
would be like without this feature.
John: If we fail to mark a feature "at risk" and then are forced to remove it as a result of review comments, we must go back through Last Call according to the process. So we need to be careful to mark everything we are unsure about as "at risk" to avoid elongating the time-to-Rec.