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

<johnarwe> http://lists.w3.org/Archives/Public/public-sml/2008Jun/0074.html

<ginny> scribe: Virginia Smith

<ginny> scribenick: ginny

<scribe> agenda: http://lists.w3.org/Archives/Public/public-sml/2008Jun/0046.html

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

<Kirk2> Kirk2 is Kirk

<MSM-EDI> there seems to be consensus that bullet 3 of 3.6.2 should continue to forbid restricting a global element dclaraiton 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

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

Rule attachment to Schema: 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

<scribe> ...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" 5636.

MSM: 5637 should 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.

<MSM-EDI> http://www.w3.org/Bugs/Public/show_bug.cgi?id=5519

John: Will mark 5637 as blocking 5636.

Relationship of Schema Validity/SML Validity (5519).

MSM: Performing SML validation requires Type annotations in the PSVI. Type annotations is affected by schema validation and processors can be lazy and not validate subtrees.
... MSM owes Ginny a test case.
... We nned to reach agreement on accepting variability in SML validation processing based on variability in Schema validation. Or shall we sspecify 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.

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.

TESTING

MSM: It is important to distinguish between No errors because constraints are there and checked vs. No errors because nothing applied.

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

<scribe> scribenick: Kirk

<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 invalid when we would like it to be valid.

Kumar: We have covered this case. We accommadate change from invalid to valid depending on type of processor.

<johnarwe> for cmdbf 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 an 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: Pefers 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 is relationship without does say which definition is accepted.

MSM: SML validity, clause 1,are underspecified becasue there are 4 ways of initiating schema validity processing. We need to say which one epxect.

<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 has objections to adding this as a non-normative note in section 8?

Ginny: We should define "non-vacuous".

Sandy is think whether he want to open an issue regarding clause 1 in section 8 regarding whether we should look only at the {validity assessment} of the root.

MSM: To think more about specifying validation needs in clause 1 of section 8.

The decision, I believe, was to let you decide whether you want to open the issue.

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 a difficulties in Schema-Complete. This issue is not relevant here. Look at points 2 & 3 in the discussion.

<nick2> I am nick2

<nick2> I am Kirk

<nick2> John: MSM's point about schema-complete has to do with output to the calculation and input to the calculation.

<nick2> scribnick: nick2

<nick2> scribenick: nick2

<scribe> 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 absolutizing suffice, and those that use URIs that are not complete even when absolutizing (e.g., EPR reference schemes).

<Kirk> scribenick: Kirk

Moving on to section 2:

MSM: Section 2 is still about point 3b.

<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.
... If 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 is absolutized, but that is not accommodated by current definition.

Kumar: If scheme author doesn't define why 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."

<scribe> scribenick: Kirk

<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 what base URI and where to find is no weaker than impl-defined. MUST 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

<johnarwe> scribenick:johnarwe

<johnarwe_> This is really Kirk typing.

<johnarwe_> scribenick: johnarwe_

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; other wise 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-EDI> we just lost

<MSM-EDI> we just lost phone connection

<MSM-EDI> we'll dial in again

<MSM-EDI> unless you need to go

MSM: We should say, that relative URI resolution should respect Doc content & encapsulting 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 vigor discussion on this point.

rssagent, make log public

rssagent, generate minutes

- DRAFT -

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

23 Jun 2008

Attendees

Contents