See also: IRC log
RESOLUTION: approved
Most don't care which days of that week we meet in Redmond; Michael has a mild preference for Mon-Wed.
Now in Last Call; accepting comments until Sep 12.
Discussion of John's comment - P1e Anonymous type definition as a child of a GED
This is a special case that is significant in the case of substitution groups.
What we really mean by P1d is "local TDs except for the ones that are in the set P1e"
John is updating the bug with this information.
MSM: if we say "assign no meaning to rules property in these cases" an SML processor cannot assign any meaning that affects SML validation
Proposal: Allow (but not talk about) meaning applied to rules property in cases of P1c, P1d, and P1f; that is remove the "MUST NOT"s
No objections heard.
Kumar: what about rules on a local element that is a restriction of a global element?
MSM: E.g., CT2 restricts CT1; element A in CT2 changes A in CT1; rules are allowed in A in CT1; currently spec does not allow rules in A in CT2
Kumar: bullet 3 in 6.3.2 disallows this conflict - A in CT2 cannot be made local
Discussion of whether this restriction should be removed and the effect of this on future specs that may layer on SML
<MSM-EDI> yzhou, we are discussing http://www.w3.org/Bugs/Public/show_bug.cgi?id=5636
<MSM-EDI> and in particular the second change labeled Prong 2 change 3
<MSM-EDI> whether to allow (or continue to forbid) restriction of a global element E1 with non-empty {rules} to a local element
Kumar: showing example of 2
globals A elements in CT1 and one local A and one global A in
CT2
... no easy way to match which A is based on which A in CT1; if
only one A has rules this is a problem
... this becomes a problem if we remove the restriction in
6.3.2, bullet 3
ginny: if we remove the MUST NOT restrictions, concerned that we may have to revisit parts of the spec
<MSM-EDI> there seems to be consensus that bullet 3 of 3.6.2 should continue to forbid restricting a global element declaration with rules to a local declaration
Consensus is not to make prong2, change 3b.
Discussion of prong 2, change 1
MSM: proposal to replace 'elsewhere' with 'in any other kind of schema component'
<johnarwe> (to go into bug)
<johnarwe> (f2f consensus)
<johnarwe> - prong 2 change 1 (removal of general prohibition of rules on locals) accepted in concept
<johnarwe> - prong 2 change 3 ...second change 3 NOT accepted, keep this restriction
<johnarwe> prong 2 change 1: want reasonable reader to understand that if {rules} is non-empty on a component for which sml assigns no meaning, those {rules} have no effect on sml validity.
<johnarwe> prong 2 change 1: editorial sugg, replace "elsewhere" with "in any other kind of schema component"
prong 2, change 2
proposal to say value of rules is not defined in all other cases rather than empty set
prong 2 change 3a
proposal: remove the MUST
statement and do not replace it (6.3.2, bullet 1)
... remove entire paragraph
consensus is to remove 6.3.2, bullet 1
prong 2 change 3b
consensus already reached is not to do this change
prong 2 change 4 & 5 - consensus is not to make these changes
prong 1 change 1: consensus is to reject this change
prong 1 change 2
<MSM-EDI> In 6.3.1 para 2, change from
<MSM-EDI> sch:schema elements MAY be embedded in members of the {application
<MSM-EDI> information} of the ...
<MSM-EDI> to
<MSM-EDI> sch:schema elements MAY appear as items in the {application
<MSM-EDI> information} of the ...
consensus is to use the above proposal
prong 1 change 3: duplicate, ignore
prong 1, change 4a & 4b: consensus is to reject these changes
prong 1 change 5a: consensus is to reject this change
prong 1 change 5b: consensus is to reject this change
prong 1 change 6: consensus is to reject this change
prong 1 change 7: consensus is to reject this change
prong 1 change 8
Kirk: do we need to consider other aspects if we do not make this change?
MSM: need to define local rules
for other schema components as empty in 6.3.1 para 3
... should revisit prong 1, change 3
consensus is to reject change in prong 1 change 8
new proposal to accept prong 2 change 2
proposal accepted
<MSM-EDI> lunch break ... for an hour ....
<MSM-EDI> WG reconvenes .................................
<Kirk> scribe: Kirk Wilson
<Kirk> scribenick: Kirk
<MSM-EDI> http://www.w3.org/Bugs/Public/show_bug.cgi?id=5637
John: Notes that 5636 was
blocking 5637.
... RE 5636. Issue needs to be Editorial, Needs Review
...New classification passes without objection.
John: 5636 was about consistency
of text; 5637 was about understanding the text.
... It could be that discussion of 5636 "bled into" 5637.
MSM:Should 5637 be reviewed after we review changes in text for 5636 or should we mark 5637 as a dup of 5636?
Kumar: We would be reviewing changes for 5636.
John: Will mark 5637 as blocking 5636.
<MSM-EDI> http://www.w3.org/Bugs/Public/show_bug.cgi?id=5519
MSM: Performing SML validation
requires Type annotations in the PSVI. Type annotations are
affected by schema validation and processors can be lazy and
not validate subtrees.
... MSM owes Ginny a test case.
... We planned to reach agreement on accepting variability in SML
validation processing based on variability in Schema
validation. Or shall we specify what kind of XML Schema
validator (lazy vs. industrious) that we wish to require.
John: Things we agree upon:
... Do we have any affect on {Schema validation attempted}? We
seem to have agreement on this. We don't affect this.
MSM: Reviews {Schema validation
attempted}: Full, None, Partial.
... Where value is "None", no SML reference or constraints on
references has not been checked. We depend on validation
attempted, but schema validation does not.
MSM: It is important to distinguish between No errors because constraints are there and checked vs. No errors because nothing applied.
Kumar: Proposes principle: Root has to be valid, descendants not invalid (can be unknown).
MSM: We should specify how schema
processor should be initiated.
... Take case of SML model that is simply instance documents,
with no schemas. This would be invalid because there is no root
to be valid.
<MSM-EDI> overview of schema-validation assessment results: http://www.w3.org/XML/2001/06/validity-outcomes.html
MSM: SOAP: well known case in
which different parties are interested in parts of the
document, but not whole document.
... We have similar case.
<johnarwe> proposal from MSM:
<johnarwe> SML validity entails NOT being Schema-INvalid on the root or any descendant.
<johnarwe> SML validity can be non-vacuously checked only after Schema validity assessment, and only on the portions of the subtree for which PSVI is available.
<johnarwe> Because the depth of PSVI is implementation-dependent, there is variability in the visibility of SML constraints available to the SML validator, and consequently in SML validity results.
MSM: We should capture this in section 8, as a non-normative note.
Sandy: Other thing: Schema
validity on the node only. There is at least one case where we
do not get what we expect.
... Case of element name with same name as parent. If we don't
have declaration of the parent, this may come out as invalid when
we would like it to be valid.
Kumar: We have covered this case. We accommodate change from invalid to valid depending on type of processor.
<johnarwe> for cmdb federation we are talking about exchanging instances of resource models. those models must be extended over time, by new levels of the spec, vendor, customer company, customer LOB, ... The pt of cmdbf is to exchange those across vendors.
Sandy: Case involves a parent
and child of same name but different type, and we don't have
the declaration of the parent.
... In looking at all descendants, we may make models invalid
that should be valid.
... We might define SML model validity, talk only about
validity of the root element; drop other language about
checking children.
... In Schema, you can look at the whole PSVI to determine what
we want to do.
MSM: Prefers stricter rule in order to guarantee interoperability. We should label the model invalid, rather than allow invalid nodes with root = valid.
<Sandy> [lax: If the item has a uniquely determined declaration available, it must be ��valid�� with respect to that definition, that is, ��validate�� if you can, don't worry if you can't.]
Ginny: In lax processing, validity would depend upon whether you have a schema or it.
MSM: Issue is how do we handle elements further down in the tree for which we have declarations.
Kumar: Suggestions we just state what the relationship is between Schema and SML validity without saying which definition of processor is accepted.
MSM: SML validity, clause 1, is underspecified because there are 4 ways of initiating schema validity processing. We need to say which one we expect.
<johnarwe> (f2f) add as non-normative note the following to clarify relationship between sml validity and schema validity
<johnarwe> SML validity entails NOT being Schema-INvalid on the root or any descendant.
<johnarwe> SML validity can be non-vacuously checked only after Schema validity assessment, and only on the portions of the subtree for which PSVI is available.
<johnarwe> Because the depth of PSVI is implementation-dependent, there is variability in the visibility of SML constraints available to the SML validator, and consequently in SML validity results.
John: Does anyone have objections to adding this as a non-normative note in section 8?
Ginny: We should define "non-vacuous".
Sandy is to think about whether he wants to open an issue regarding clause 1 in section 8 regarding whether we should look only at the {validity assessment} of the root.
John: Change issue to Decided and Editorial. No objections.
RESOLUTION: Change
issue 5519 to Editorial and Decided.
... Also Needs Review
<MSM-EDI> http://www.w3.org/XML/2008/06/sml-bug5542.xml
MSM: Has produced a discussion
paper. (Not as complete as he would have liked.)
... In looking at relative URI, he found difficulties in
Schema-Complete. This issue is not relevant here. Look at
points 3 & 4 in the discussion.
John:MSM's point #1 about target-complete has to do with distinguishing between the output of the calculation of target-complete identifier vs. input to the calculation.
ACTION: John to open bug on schema-complete definition. [recorded in http://www.w3.org/2008/06/23-sml-minutes.html#action01]
<trackbot> Created ACTION-199 - Open bug on schema-complete definition. [on John Arwe - due 2008-06-30].
Kumar: Questions need to have
this issue.
... URI relative in reference scheme can be converted to a
target-complete URI.
MSM: Three claseses of reference: Don't use URI, use URI that when absolutized suffices, and those that use URIs that are not target-complete identifiers even when absolutized (e.g., EPR reference schemes).
Moving on to section 2:
MSM: Section 2 is still about point 3.b in section 1.
<johnarwe> http://www.w3.org/XML/2008/06/sml-bug5542.xml
MSM: Sanity test: we can write a
reference scheme that requires the use of absolutized
URI.
... Consider whether this is implementation-dependent. But the writer of a
reference scheme is not the implementation. This means the
scheme author can't do that.
... It should be clear that a reference scheme requires an absolutized URI,
but that is not accommodated by current definition.
Kumar: If scheme author doesn't define way to absolutize it, then it is implementation-dependent.
<MSM-EDI> Sandy: no, the schema author MUST define how to find the URI.
<MSM-EDI> Kumar: yes, covered by point 2.
<MSM-EDI> Sandy: if it's covered by point 2, then 3.b should refer to point 2.
<Sandy> in 3.b. "if these ..., then the set of rules for resolving SML references to targets (see #2 above) MUST include what base URI to use for resolving reletive references to URIs or IRIs."
<MSM-EDI> or perhaps "MUST specify how to identify the base URI / IRI to use in resolving relative references ..."
<MSM-EDI> or s/identify/determine/
John: If we specify that
reference schemes can defined by authors, then should we say
that definitions are implementation-dependent or
implementation-defined?
... Reference Author MUST define base URI. Issue: whether
absolutizing URI is impl-dep or impl-defined.
MSM: We should say "impl-define". Impl-dependent is useless.
Scheme authors are required to say where to find baseURI and make no weaker statement than impl-defined. SHOULD NOT say imple-dependent.
<MSM-EDI> concrete alternative would be s/MUST NOT/SHOULD NOT/
<johnarwe> No objections to ref scheme authors MUST NOT say impl dep, and MUST say how base URIs are arrived at if they allow relative refs
MSM: We need to align relative
URI/base URI with the relevant RFCs and XML specs.
... Order of resolving relative URI: 1. Document content, 2.
Encapsulating entity, 3. Retrieval URI, 4. Default
(implementation dependent)
... Proposes use of [base URI] for Doc content, which is
aligned with xml:base.
John: Definition is about both SML and SML-IF. In SML, because SML URI Ref Scheme is defined there.
MSM: Unclear in the spec. baseURI
defined in <document> used in document; otherwise use
baseURI on <model>.
... Not clear whether the <document> baseURI falls within
Document content in the RFC 3986.
... Use of <document> baseURI is like Doc content. Not
sure whether this is the case for non-embedded documents.
Ginny: We also use <model> baseURI as the URI taken from the encapsulating entity. We don't need the 3rd and 4th source.
MSM: We should say, that relative URI resolution should respect Doc content and encapsulating entity.
Kumar: Producer can use different baseURIs in SML-IF in order to point to the document in the SML-IF package. Producer can change the URL to the document as it exists on the Web.
MSM: Considers this is bad idea.
There is an accepted technology for using baseURI, and it would
be best to follow this.
... We should require support for xml:base. If the authors use
it, we should respect their use of xml:base. We also need to
respect [baseURI].
Kumar: Intranet addresses should be able to be changed in the SML-IF document because those addresses are private to the intranet.
MSM and Kumar have a vigorous discussion on this point.
Last Scribe Date Member Name Regrets pending 2008-04-17 McCarthy, Julia 2008-05-22 Lynn, James 2008-06-05 Gao, Sandy 2008-06-12 Kumar, Pandit 2008-06-23 Smith, Virginia 2008-06-23 Wilson, Kirk Exempt Arwe, John Exempt Dublish, Pratul Exempt MSM Exempt PH