W3C

W3C SML Face to Face Meeting of 2008-Jun-23

23 Jun 2008

Agenda

See also: IRC log

Attendees

Present
John, Kirk, Kumar, Ginny, Michael, Yu Chen, Sandy
Regrets
Julia, Pratul
Chair
John Arwe
Scribe
Ginny, Kirk

Contents


 

Approval of 6/19 minutes

RESOLUTION: approved

October meeting

Most don't care which days of that week we meet in Redmond; Michael has a mild preference for Mon-Wed.

Schema

Now in Last Call; accepting comments until Sep 12.

Bug 5636

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

Rule attachment to Schema: http://www.w3.org/Bugs/Public/show_bug.cgi?id=5637

<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.

Relationship of Schema Validity/SML Validity (5519).

<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

Base URI: http://www.w3.org/Bugs/Public/show_bug.cgi?id=5542

<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 TargetComplete. 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 targetcomplete definition. [recorded in http://www.w3.org/2008/06/23-sml-minutes.html#action01]

<trackbot> Created ACTION-199 - Open bug on targetcomplete 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 targetcomplete 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.

Summary of Action Items

[NEW] ACTION: John to open bug on targetcomplete definition. [recorded in http://www.w3.org/2008/06/23-sml-minutes.html#action01]
 
[End of minutes]

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