SML WG call

 

 

Approval of minutes

<MSM> scribenick: Kirk

<MSM> scribe: Kirk Wilson

<pratul> Kirk: Bug 5506 should be "5606" in minutes

RESOLUTION: 5/22 Minutes are approved with correction of the typo
... A duplicate bug will be identified on 5715.

Action items.

Pratul: AI 137: proposal to Schema group: will be completed later.

Julia: AI; 188: Still digesting Valentina's response
... AI 186. Action is completed.

Kumar: AI 184: To work with Pratul
... AI 189: Currently working on this

MSM: AI 190: Will have this done by next weeks call.

Member announcements

Pratul: There are 2 new members from IBM; Sun has left the group.

Issues

Bug 5522: decided keyword should be removed.

Ginny: Should we removed "reviewerNotSatisfied"?

John: reviewerNotSatisfied should removed because we don't want to make assumptions of whether the reviewer is satsified with the new resolution.

RESOLUTION: Remove "decided", "resolved", and "reviewerNotSatisfied" and reopen the bug.

Ginny: Fix as per comment #5. Pratul agrees.

<johnarwe> to expand a bit: while the reviewer was dissatisfied w/ the original response, when we changed our response we should at that time have removed reviewerNotSatisfied

<pratul> Resolution in 5/29 call - reopen the bug (5522) so that it can be fixed as per Comment #5

Bug 5513: Why does SML define sml:ref instead of xlink.

Pratul: Two week period is over, we should resolve this issue.

RESOLUTION: Remove "decided" keyword and resolve the bug.

Resolve the bug as INVALID

Bug 5520: Why is document defined as a character sequence

Kumar: Text was not added to the text.

RESOLUTION: Take "Decided" keyword out and mark as "Editorial"

Bug 5524: Rename 4.4.1.1

RESOLUTION: Remove "decided"

Bug 5545: Reconcile SML URIs with RFC3986

RESOLUTION: Remove "decided"

Bug 5562: Define XHTML href Ref Scheme

Pratul: Have not heard from reviewer.

RESOLUTION: Remove "decided"; we need to keep "ReviewerNotSatisfied".

Resolved as WON'T FIX.

Bug 5541: Schema-less identification

<MSM> I thought he said http://www.w3.org/Bugs/Public/show_bug.cgi?id=5541

Pratul: Proposal is not ready yet.

Ginny: See comment 2: If we have two different mechanisms, we have a problem with interoperability. Producer can't guarantee interoperability.

<julia> would those not talking go on mute please?

MSM: If I were a producer and using schema-based, I would normalize it in instance document. Just the same as if I were using special scheme, I would substitute SML URI scheme.

Kumar: We do not require doing this in the spec because we don't want to violate signatures on the documents.

MSM: Agrees with Kumar, does not believe we should require it. But mentioning normalization is the right thing to do.

John: If we do mention this, we should mention that care must be taken dealing with signatures.

Kumar: Two types of interoperability: within validating consumers we could say these must use PSVI. Other consumers have a choice. Note: non-Validating consumers can do anything; therefore there is not a strong interoperability statement there anyway.
... Changes to the text. Validating Consumers MUST use PSVI; other consumers may use either approach.

Julia: Agree with proposal, but not sure where it goes into spec.

<MSM> [It occurs to me that with regard to schema-based identification of references, there are two useful pieces of advice: (1) producers can improve the chances of successful interoperation by normalizing the data, and (2) consumers can improve the chances by using the PSVI. In this way, schema-based references have a better story than, say, variation in reference schemes.]

Kumar: Go into 4.1.1 (SML Reference) of SML spec.

Ginny: We may need something in the Conformance section.

Kumar: We should agree to the proposal; then discuss actual text.

Ginny: I agree.

MSM: I agree if editors agree to come back with text.

<Jim> I agree as well.

Kirk: I agree

<julia> I agree also

<julia> +1

<scribe> ACTION: Kumar to work with Ginny to propose text changes to reflect Kumar's proposal on Validating Consumers using PSVI. [recorded in http://www.w3.org/2008/05/29-sml-minutes.html#action01]

<trackbot-ng> Created ACTION-191 - Work with Ginny to propose text changes to reflect Kumar's proposal on Validating Consumers using PSVI. [on Kumar Pandit - due 2008-06-05].

Bug 5519: SML model validity / XSD Validity

MSM: Action is to work on a test case, not a use case. Tell whether application is skipping a tree when encounter lax processing.
... This should not affect resolution of issue; but people may want to see test case before deciding.

John: Prefers not to wait.

Ginny: Prefer to wait. Test cases will provide information to colleagues for consultation to generate internal consensus.

MSM: We could say that XML schema validators that preform in a certain way are appropriate for SML Model validator.

<MSM> [I think the relevance of the test case may come up here: if we are leaning to solution 2, our choice of which form of 2 to use will depend on the processors we know and care about.]

Kumar: Two options: (1) recognize variability in processors or (2) limit processors. Likes option (1) better: XML Schema spec allows this and no reason for overriding it.

John: Comments #5 and #6 are not mutually exclusive. Different issues in #6, addressed orthogonally. Henry may be thinking that model validity in some way refers to Schema [validity] property because of similar words.
... This latter issue is a different issue than the issue MSM is talking about.
... model validity is a property of the model, not of the document like schema [validity]. Moreover, model validity has only two values (T or F).

<MSM> [So: (1) distinguish SML validity ('validity' for short) from XSD validity (or 'schema validity'),

<MSM> (2) characterize sml validity as one Boolean value for the entire model

<MSM> (3) point to implication relation / consistency requirement linking SML validity and XSD validity

<MSM> Anything else?]

John: there's local validly, but [validity] and [validation attempted] depends on children.

MSM: Full validity if locally valid and none of children are invalid.
... If you have invalid children, you are invalid, with exception of lax processing.

<MSM> Valid elements may have children with [validity] = valid or notKnown, but [validity] = invalid propagates upward (unless there is an element for which we had no declaration.)

<johnarwe> fyi, this is all in Schema Structures 5.2, which (mostly) punts to 3.2.5 (attributes) and 3.3.5 (elements)

<MSM> Ginny: so if an element is validated laxly, invalidity among the children does not propagate upward? But if it's validated against anyType, it does?

<MSM> MSM: yes (more or less): if the schema has a declaration for the element that says it has type anyType, or you have a 'processor-stipulated' declaration then yes, invalidity propagates upward.

Ginny: Is interested in how people feel about options (1) or (2).

<MSM> If the schema has no declaration for the element, and there's no xsi:type or stipulated type, then invalidity is 'blocked' by the [validity] = notKnown.

<MSM> One could imagine the design going either way, but XSD 1.0 and 1.1 both say the rule "no declaration? then validity = notKnown" is more important than the rule "invalid child? then validity = invalid".

MSM: I'm agnostic on this issue. Current design of 1.0 was not designed for WG like this one. In context of SML-IF it would make sense to say that schema process behaves consistently. 1.1 says we MUST validate the subtree.
... If we take option (2) we should select the version that is consistent with Schema 1.1.

<MSM> [+1 to SG's summary of the XSD 1.0 design choice.]

Sandy: Most users just want to look at the validity of the root. Our assumption is that elements must be valid or invalid. So we look at every node. Third option: look at validity property of root and only that can be valid or unknown. Text in section 8.

MSM: Concern about Sandy's option 3: it doesn't address issue of SML constraints that pertain to element types on a laxly processed subtree. Thus, does not address interoperability concern.

MSM: In laxly validated subtree, processor may not pick up invalid constraint on an element type. Another processor that processes the subtree would pick up this violation.

<pratul> Re 5519, it appears we need more discussion

<pratul> Recommend we discuss this in email

Ginny: You want to check validity. More important to know that it is valid than not invalid.
... I'm not ready to make a decision.

No objection to moving to next bug.

Bug 5542: Absolutizing URIs.

Pratul: Response from Henry that he has not satisfied with response.

Sandy: Henry is referring to baseURI property which is on every element information item in the infoset.

MSM: Henry is right that processors can set baseURI independent of the SML spec. We do need to say how to treat baseURI properties.
... MSM Believes that if you specify a value of baseURI that sets Infoset property.

<johnarwe> http://www.w3.org/TR/2008/PER-xmlbase-20080320/

<Sandy> http://www.w3.org/TR/2004/REC-xml-infoset-20040204/#XMLBase

Sandy: Infoset spec where baseURI property is defined.
... xmlbase defines how to define the value of the property.

<Sandy> http://www.w3.org/TR/2004/REC-xml-infoset-20040204/#intro.baseURIs is more appropriate link for the [base URI] property

<MSM> [There are three specs or sets of specs involved: the URI specs talk about the role of the base URI in resolving relative URIs, the XML Infoset spec talks about the base URI property of XML documents, and the XML Base spec talks about a way to manipulate base URIs in XML documents.

John: see section 5.1 of 3986 for absolutizing relative URI if none of elements if none of elements have a baseURI property set.

MSM: Henry is right in saying use baseURI and use rules in XMLBase. If these are not sufficient, means rules are implementation dependent.

<johnarwe> (from the xml base spec PER section 4.1, since it also summarizes RFC 3986)

<johnarwe> 4.1 Relation to RFC 3986

<johnarwe> RFC 3986 [RFC 3986] provides for base URI information to be embedded within a document. The rules for determining the base URI can be summarized as follows (highest priority to lowest):

<johnarwe> 1.

<johnarwe> The base URI is embedded in the document's content.

<johnarwe> 2.

<johnarwe> The base URI is that of the encapsulating entity (message, document, or none).

<johnarwe> 3.

<johnarwe> The base URI is the URI used to retrieve the entity.

<johnarwe> 4.

<johnarwe> The base URI is defined by the context of the application.

<johnarwe> Note:

<johnarwe> The term "entity" in points #2 and #3 above uses the RFC 3986 meaning of the term. Elsewhere in this document the term "entity" is used in the XML sense.

<johnarwe> This document specifies the details of rule #1 for embedding base URI information in the specific case of XML documents.

MSM: Currently we are allowing implementation to violate Web architecture (general structure of URI), but we should not allow this.

Sandy: Raises question of how this is related to our previous discussion in SML-IF.

Silence!!

<scribe> ACTION: Michael to draft text on applying XMLbase rules for absolutizing relative URIs in SML by 06/15/2008. [recorded in http://www.w3.org/2008/05/29-sml-minutes.html#action02]

<trackbot-ng> Created ACTION-192 - Draft text on applying XMLbase rules for absolutizing relative URIs in SML by 06/15/2008. [on Michael Sperberg-McQueen - due 2008-06-05].

<johnarwe> xml:base PER intro says: It is expected that a future RFC for XML Media Types will specify XML Base as the mechanism for establishing base URIs in the media types it defines.

<johnarwe> same PER Intro says: The deployment of XML Base is through normative reference by new specifications, for example XLink and the XML Infoset. Applications and specifications built upon these new technologies will natively support XML Base. The behavior of xml:base attributes in applications based on specifications that do not have direct or indirect normative reference to XML Base is undefined.

Ginny: If we want depend on XMLBase, then we need to say this explicitly, because it is not required by anything we require normatively.

MSM: Just saying we absolutize URIs that does not violate Web architecture does NOT specify things sufficiently.

It seems that I typed the date wrong on the action item, since it was supposed to be the 12th.

<johnarwe> I think Sandy is saying that the web arch allows redirection of URIs, "definitionally"

Meeting adjourned: 4:00

Last Scribe Date  Member Name               Regrets pending 
2008-03-13              Gao, Sandy                
2008-04-17              McCarthy, Julia          
2008-04-24              Kumar, Pandit 
2008-05-15              Smith, Virginia     
2008-05-22              Lynn, James               
2008-05-29              Wilson, Kirk             
Exempt                  Arwe, John                
Exempt                  Dublish, Pratul 
Exempt                  MSM 
Exempt                  PH