See also: IRC log
Minutes of 8-14 call are approved without objection.
Kumar has created a diff and Sandy had comments.
Pratul: Are these changes substantial or can be consider them editorial and move on?
MSM: We need to deal with Sandy's point #1 regarding an apparent contradiction.
Kumar: I agree with point #1.
Sandy: Point #2 doesn't have to fixed before LC.
<Kumar> new text for c.ii: If the fragment component complies with the Shorthand Pointer syntax, then the reference target is the element identified based on XML Schema determined ID by the Shorthand Pointer. If a target cannot be identified based on XML Schema determined ID then Reference target MAY be identified based on other criteria allowed for Shorthand Pointers.
<MSM> a suggestion and a question
<MSM> suggestion: s/then Reference target/then the reference target/
<MSM> question: just say the target may be identified based on other criteria?
Kumar agrees to suggestion
<MSM> or say "it is implementation-defined whehter a reference target is identified based on other criteria .../
Kumar agrees to MSM's proposed rewording.
<Kumar> If the fragment component complies with the Shorthand Pointer syntax, then the reference target is the element identified based on XML Schema determined ID by the Shorthand Pointer. If a target cannot be identified based on XML Schema determined ID then it is implementation-defined whehter the reference target is identified based on other criteria allowed for Shorthand Pointers.
Sandy: This change makes clearer
what our intention is, but it still suffers from the same
problem of the "is" vs. "may".
<ginny> If the fragment component complies with the Shorthand Pointer syntax, then:
<ginny> -- If a target can be identified based on XML Schema determined ID, then the target is the element identified based on XML Schema determined ID by the Shorthand Pointer.
<ginny> -- If a target cannot be identified based on XML Schema determined ID then it is implementation-defined whether the reference target is identified based on other criteria allowed for Shorthand Pointers.
Sandy agrees with ginny's wording.
<MSM> [MSM wonders whether "XML Schema determined ID" should be just "the schema-determined ID" (with same hyperlink)
Kumar: "schema-determined ID" previously caused confusion.
MSM: use "the" and hyphenate.
Pratul: Is there an objection to
ginny's text in IRC.
... There is no objection. Pratul will update the bug with these comments.
point #1 as per wording provided by Ginny.
... mark as editorial.
Pratul: Reviewer is still recorded as "not satisfied".
Kumar: fix does not include
... Strict-wildcard is requirement on processor, those added in Conformance section, and does not pertain to the structure of the model. Therefore it doesn't belong in Validity point #1.
MSM: This point leaves model validity underspecified. You have to say: Validity as specified in point 8 of Conforming model.
Kumar: I am OK with the cross-reference.
MSM: Two possibilities. Leave item 8 and insure cross-references. Put the text in point #1 so we don't need cross-reference.
Ginny and Kirk agree with MSM; which is in agreement with Sandy Comment #5.
Kumar: Need to have requirement on conforming validity, a processor can claim to be conforming without doing strict-wildcard validation. But can live with comment #5.
MSM: What is in item 8 is lax-wildcard validation.
Sandy: Issue: Is comment #2 what we agreed to? And if we did, verify that text says that.
MSM: Really mean if whether
element is in schema, & this has to do with SML validity,
not schema validity.
... If there is a schema, we want root element to be valid started in strict-wildcard mode. If there is no element in the schema, then it is not relevant to SML model validity.
<MSM> I think SG's text in comment 5 does the job pretty well (although it's kind of indirect)
Kumar: where do we say if there is no schema bound, then no schema validity is performed?
MSM: In this this case, no schema validity is to be performed in order to say that the model is SML valid.
Kumar: Requests Sandy to add another sentence.
MSM: Acknowledges that there is a problem in the XML Schema 1.1 spec, where the proposed text originated.
<Sandy> "If no schema is bound to the instance document, then whether schema-validity is assessed for that instance document is implementation defined. The outcome, if any, does not affect SML model validity."
<MSM> [Perhaps make the item begin "In each instance document in the model which is bound to a schema, ..."
<MSM> and add a sentence in a separate paragraph saying "For instance documents not bound to any schema, the schema-validity of the instance document is not relevant to the validity of the model"]
Pratul: Why are we making this change now?
MSM: Comment #2 goes beyond a declarative statement and becomes an imperative statement. The declarative statement in this case is that it is relevant to SML validity.
<MSM> 1. In each instance document in the model which is bound to a schema,
<MSM> the [validity] property of the root element MUST be "valid", and the
<MSM> [validity] property of all the other elements and all the attributes
<MSM> MUST NOT be "invalid", when schema validity is assessed with respect
<MSM> to any schema that is bound to this instance document. The assessment
<MSM> starts at the root element with no stipulated declaration or
<MSM> definition. [XML Schema Structures].
<MSM> Note: The schema-validity of instance documents not bound to any
<MSM> schema does not contribute to the validity or invalidity of the
MSM: Sandy's version is OK.
Kumar: Prefers the condition to be normative.
Sandy: Prefers MSM's version.
<MSM> Good job, editors and Sandy!
John: Proposal is to accept MSM's version, remove "Note:" so the statement is considered normative.
Pratul: We are in agreement.
MSM's wording for validity item #1; delete current item #8 for
... mark as editorial.
Pratul: Are there any objections to resolving this issue as in specs?
RESOLUTION: Issue 5922 is resolved as "Fixed".
Discuss changes to SML spec first (one small change in 4.3.1) first, then the more involved changes to SMLIF (section 5.3.2 heavily hit, small changes in 5.3.3 and 5.3.4) second
Ginny: Reviews her changes to SML
4.3.1 bullet 2.
... actually, changes are around 2a. No other changes beyond that. The change is to say SML uses [base URI] to obtain any base URI values needed to resolve relative references, but not how [base URI] is calculated.
Kumar: In 2aii, we need statement that behavior is implementation-defined.
John: Are we forcing processor to document something that is none of our business?
Kumar: does not want to support xml:base.
John: Agreed, doing so was/is not my intent.
Ginny: What is needed: Computation of [base URI] is impl-def/dep
<ginny> If the URI reference is a relative reference, then let U be the result of resolving the reference using the [base URI] property [XML Information Set] of the <sml:uri> element as the base URI. Otherwise, U is the URI reference itself. The computation of the [base URI] property is implementation-defined.
Discussion lead by John regarding use of "defined" vs. "dependent".
<johnarwe_> my pref for dependent is mild at best
<johnarwe_> (and, as co-chair, irrelevant)
MSM: "sympathy" with John's preference for "dependent", but feels need to know may trump other concerns.
Sandy: Agrees "defined" is OK.
John: Are there objections to keeping it as proposed by Ginny.
<johnarwe_> ginny's text is the proposed replacement for SML 4.3.1 item 2.a.ii.A
<johnarwe_> in section 4.3.1 SML URI Ref Scheme
RESOLUTION: Use text as proposed for by Ginny in 2aii in 4.3.1.
Ginny: Comment 12 contains the full text of the resolution (SML-IF changes, latest proposal after on-going email discussion).
Discussion between John and Ginny regarding the MUST embed condition, located at the beginning of SMLIF 5.3.2 in the proposal under discussion
<MSM> [sanity check: we are now discussing http://lists.w3.org/Archives/Member/member-sml/2008Aug/0026.html and its attachments, true? false?]
John: running out of time in this meeting, suggests we take the LC vote contingent on resolution of this issue, so we don't get tripped up by vacations/lack of quorum the next few weeks. We have regrets already for Kirk next week, Ginny the following two (and now possibly for next week as well).
Pratul: My quesiton was whether we should continue discussion of bugs now or carry on in email?
John reviews current open issues to see which the wg believes should be fixed before publishing the next LC draft.
Pratul: we should do 5600.
... Kirk, Ginny, MSM confirm availability.
RESOLUTION: Members agree that because some members will be absent next week, we will take an email vote. Those absent/with regrets have said they will have email access and so will be able to vote.
<johnarwe_> 5561 xlink
<johnarwe_> any objections to marking 5561 target CR?
Do we need to 5561 for LC (XLink)? No objections to marking it CR.
<johnarwe_> any objections to marking 5680 target CR?
Back to 5542
John: is OK with the "second
red", i.e. SMLIF draft
excerpt Each document in the interchange model has a document base
URI whose value is a computed value. in section 126.96.36.199 of the draft.
... Want to be sure group is aware of question Ginny raised in latest email: Is it allowed for consumer to calculate [base URI] from xml:base in one document and from smlif:baseURI in another in the same SML-IF document?
MSM: It was my understanding that it
would be possible to mix models in the same SMLIF
... Agnostic on whether they ought to or not.
... Ad hoc to forbid it.
Ginny: Foresees confusion and design difficulty.
<pratul> John: I need to leave now. Pls take over. Thanks!
John: Issue: mixing these in the same document and how this would work. See Ginny's example.
Ginny's concern if both mechanisms are used in the same (e.g. instance) document for different elements.
<MSM> [time check]
John: The way I had been reading the spec is: if xml:base
is used anywhere in the SMLIF document, then it must be used by
everyone, i.e. only one base URI mechanism would be used per SMLIF
... we need to make clean SML specifications to the best of our ability.
Ginny: we need to resolve issue on mixing the methods.
<scribe> Meeting: adjourned by John at 4:03. Will continue discussion trying to close last few bugs over next few days.
Last Scribe Date Member Name Regrets pending 2008-05-22 Lynn, James Until further notice 2008-07-10 McCarthy, Julia Until further notice 2008-07-31 Kumar, Pandit 2008-08-07 Smith, Virginia 9/4, 9/11 2008-08-14 Gao, Sandy 2008-08-21 Wilson, Kirk 8/28, 9/4 Exempt Arwe, John Exempt Dublish, Pratul 8/28 Exempt MSM