IRC log of sml on 2008-07-24

Timestamps are in UTC.

17:55:24 [RRSAgent]
RRSAgent has joined #sml
17:55:24 [RRSAgent]
logging to
17:55:31 [Zakim]
Zakim has joined #sml
17:59:39 [MSM]
zakim, this will be sml
17:59:39 [Zakim]
ok, MSM; I see XML_SMLWG()2:00PM scheduled to start in 1 minute
18:00:40 [Kirk]
Kirk has joined #sml
18:01:08 [Zakim]
XML_SMLWG()2:00PM has now started
18:01:09 [MSM]
zakim, please call MSM-617
18:01:10 [Zakim]
ok, MSM; the call is being made
18:01:15 [Zakim]
18:01:46 [MSM]
zakim, please call MSM-617
18:01:46 [Zakim]
ok, MSM; the call is being made
18:01:47 [Zakim]
18:01:47 [Zakim]
18:01:47 [Zakim]
18:01:59 [Zakim]
18:02:08 [Zakim]
18:02:25 [pratul]
Zakim, Microsoft is me
18:02:25 [Zakim]
+pratul; got it
18:02:26 [Kirk]
chair: Pratul Dublish
18:02:27 [Kumar`]
Kumar` has joined #sml
18:02:51 [Kirk]
scribenick: Kirk
18:02:56 [Zakim]
18:03:01 [Kirk]
scribe: Kirk Wilson
18:03:01 [Kumar`]
Kumar` has joined #sml
18:03:06 [pratul]
Julia sent her regrets
18:03:10 [Sandy]
Sandy has joined #sml
18:03:18 [Kirk]
regrets: Jim
18:03:35 [Kirk]
rrsagent, make log public
18:03:50 [pratul]
18:04:11 [Sandy]
regrets+ Jim
18:04:11 [Kirk]
regrets+: Jim
18:04:54 [Kirk]
zakim, who's on the phone?
18:04:54 [Zakim]
On the phone I see Kirk, MSM, Kumar, pratul, Sandy
18:05:34 [ginny]
ginny has joined #sml
18:05:59 [Kirk]
TOPIC: Approval of Minutes
18:06:23 [Zakim]
18:06:34 [Kirk]
Minutes of 7/17
18:06:45 [Kirk]
Minutes approved without objection
18:07:09 [Kirk]
TOPIC: How are SML URIs absolutized: 5542
18:07:43 [Kirk]
Pratul: Henry has submitted comments, MSM essentially agreed.
18:08:02 [Kirk]
Pratul: comment 1 was dropped from John's proposal.
18:09:31 [Kumar]
Kumar has joined #sml
18:09:43 [Kirk]
MSM: Curious as why point 1 of John's proposal was dropped. Why is it dropped from document level?
18:10:14 [Kirk]
Kumar: based on point 3, since it optional
18:10:33 [Kirk]
Ginny: based on what implementations are doing.
18:10:43 [Kirk]
18:12:13 [Kirk]
MSM: Point 1 helps support the eventual dropping of sml:baseURI together.
18:12:29 [Kirk]
...Would prefer not to project more of existing code than needs to be protected.
18:12:36 [Kirk]
Ginny: Agrees.
18:12:40 [MSM]
18:19:29 [Kirk3]
Kirk3 has joined #sml
18:20:00 [Kirk3]
zakin, Kirk3 is Kirk
18:20:11 [Kirk3]
zakim, Kirk3 is Kirk
18:20:11 [Zakim]
sorry, Kirk3, I do not recognize a party named 'Kirk3'
18:21:08 [Kirk3]
scribe: Kirk3
18:22:01 [Kirk3]
Kumar: MS will continue to support sml:baseURI. These should not be part of interop cases.
18:27:24 [Kirk3]
Ginny: Henry wants a stronger statement of deprecation than the proposal makes.
18:28:11 [Kirk3]
Kumar: If allow only on model, scenarios for which we introduced sml:baseURI will not work.
18:29:45 [Kumar`]
s/sml:baseURI will/smlif:baseURI per document will/
18:30:45 [Kirk3]
MSM: Two reasons: (1) less important for moving to xml:baseUri, (2) If I want to guarantee interoperability if both are option, then I would absolutize URIs.
18:31:34 [Kirk3]
MSM: No positions have changed; I have asked for explanation. If no minds have been changed, we should leave the proposal as is.
18:32:27 [MSM]
s/less important for moving to xml:baseUri,/the situation SG described seems less important to me than the principle of encouraging people to move to xml:base,/
18:32:42 [Kirk3]
Pratul: Does anyone want this to be reopened?
18:32:53 [Kirk3]
No requests to reopen the issue.
18:33:12 [MSM]
s/I have asked for explanation./I have asked for an explanation, and have now gotten it, for which I thank the WG./
18:33:22 [Kirk3]
Pratul: Let's look at Henry's comment.
18:34:17 [Kirk3]
Sandy: Questions whether a consumer can support neither form of baseURIs
18:35:22 [Kirk3]
Ginny: Expressed objection last week.
18:35:40 [Kirk3]
Pratul: Whole issue should be considered?
18:36:12 [Kirk3]
Ginny: Would like to discuss point 5.
18:37:10 [pratul]
Sandy and Ginny requested that we reopen the discussion on 5542
18:37:37 [Kirk3]
MSM: Sandy and Ginny are suggesting a point 6: Consumers must support one or the other
18:38:34 [Kirk3]
Ginny: IS anticipating agreement with Henry's comments.
18:39:20 [MSM]
[If I'm understanding this correctly, the consequence would be that if I produce an IF package with *both* smlif:baseURI and xml:base, then all consumers will be guaranteed to understand the package correctly.]
18:39:46 [MSM]
[That would have the consequence that to get universal guarantees of readability I don't have to absolutize all URIs.]
18:40:01 [MSM]
[This helps IF packages avoid being verbose and illegible.]
18:40:10 [kirk]
kirk has joined #sml
18:40:22 [MSM]
[Is that about right?]
18:40:26 [kirk]
scribe: Kirk
18:41:11 [kirk]
Kumar: There is no intention to remove sml:baseURI. Probably same for COSMOS.
18:41:26 [MSM]
s/There is/MS has/
18:41:46 [kirk]
Ginny: It is hard for the producer to know if the model is interoperable.
18:43:49 [kirk]
...Thus both become useless for "pure" interoperability (i.e., producer doesn't know who the consumer is). Neither of these are useful.
18:44:48 [MSM]
+1 to Ginny's argument, as I understand it, that this is one barrier to interoperability that we do not have to impose. I think the versions of external specs are a special case; this one is just internal to our spec.
18:44:51 [kirk]
Kumar: This is not a special with regarding to optional features.
18:45:33 [kirk]
Sandy: Agrees that every optional features has this problem, which is why we try to limit optional features.
18:46:17 [MSM]
I suppose there are two ways to apply the floor/ceiling analysis: require xml:base for consumers, or require one-or-the-other.
18:46:30 [kirk]
Pratul: Have a statement that one of the other must be submitted?
18:46:37 [kirk]
...Sandy agrees.
18:46:43 [MSM]
18:47:05 [Sandy]
s/one of/at least one of
18:47:17 [MSM]
Proposal: add point 6: Consumers are required to support at least one of xml:base and smlif:baseURI
18:47:48 [MSM]
s/Proposal/PD proposal (as MSM heard it)/
18:49:36 [kirk]
Pratul: compatible with this point 6 and deprecating smlif:baseURI.
18:49:57 [kirk]
MSM: Doesn't see incompatibility
18:50:09 [kirk]
s/compatible with/incompatible with
18:50:51 [kirk]
MSM: Weird but not a logical contradiction. Gives direction for those using smlif:baseURI.
18:51:55 [kirk]
Pratul: Consumer must support must at least one smlif:baseURI and xsml:base. Then say that smlif:baseuURI is deprecated.
18:53:27 [kirk]
Kumar: Clarifies the meaning of "deprecation": smlif:baseURI is continued to be supported in SML 1.1, in future version support MAY be dropped.
18:54:17 [kirk]
MSM: What this means in practice, people who want to preserve feature CANNOT claim that it will break current implementation.
18:57:34 [kirk]
MSM: Clarifies that the current proposal (deprecation today), then it might be removed in NEXT version. If statement says (last week), deprecated in next version, then it is still supported in THAT version, and will not go away in a subsequent version after that.
18:58:15 [kirk]
...The first meaning is what Henry is interested is trying to get at.
19:00:00 [kirk]
Kumar: Word "deprecated" causes confusion. Just say explicitly what it means.
19:00:29 [kirk]
Ginny: The statement would not be as strong as "deprecated".
19:00:37 [kirk]
MSM: Agree with Ginny.
19:01:16 [kirk]
...We should define "deprecated" but use the word.
19:01:51 [kirk]
...The word "Deprecated" carries the connotation: It is advisable not to use it.
19:02:23 [MSM]
What I believe HT is suggesting (and what I would support) is addition of a Note saying something like:
19:02:33 [MSM]
19:02:35 [pratul]
One interestin definition of deprecate - Archaic. to pray for deliverance from.
19:03:23 [MSM]
The smlif:baseURI feature is supported in this version of this specification for compatibility reasons. It is, however, deprecated and may be removed in a future version of this specification.
19:04:11 [MSM]
or possibly: it is, however, deprecated: it may be removed in a future version of this specificaiton, and users of this specification are advised to avoid using it if possible.
19:04:18 [MSM]
-- end of proposal --
19:05:12 [kirk]
Pratul: First proposal is preferred.
19:05:43 [kirk]
Pratul: Is everyone happy with this proposal?
19:05:54 [kirk]
No objection.
19:06:24 [kirk]
Pratul: Are we happy with saying consumers must support either smlif:baseURI / xml:base.
19:06:31 [kirk]
No objection
19:06:49 [pratul]
Consumer must support must at least one smlif:baseURI and xml:base.
19:06:59 [pratul]
The smlif:baseURI feature is supported in this version of this specification for compatibility reasons. It is, however, deprecated and may be removed in a future version of this specification
19:07:12 [kirk]
Pratul: Any objection?
19:07:22 [kirk]
No objection.
19:07:46 [kirk]
Ginny: There is still comment 7b:
19:08:51 [kirk]
Pratul: 7b applies to situation in which consumers supports both.
19:09:46 [kirk]
Sandy: Compute from xml:base, if that fails, use smlif:baseURI
19:13:19 [kirk]
RESOLUTION: Mark 5542 as Editorial, needsReview.
19:13:51 [kirk]
Pratul will send email to Henry to get his approval on our approach to comments 7a and 7b.
19:14:16 [kirk]
TOPIC: SML URI seems overconstrained (barenames) 5543
19:15:10 [kirk]
Review of comment #7.
19:15:23 [kirk]
MSM: Assume same thing to be true of DTD-validation.
19:15:36 [kirk]
Pratul: This sound reasonable.
19:15:44 [kirk]
19:16:11 [kirk]
Kumar: Proposal is not to do DTD validation.
19:16:23 [kirk]
MSM: No.
19:19:14 [kirk]
MSM: Barenames for things identified as ID. Things are identified as ID by Schema-validiation, DTD-validation. It is implementation define whether you use Schema or DTD-validation?
19:19:40 [kirk]
...Or does it mean something else?
19:21:44 [Kumar`]
Model validators MUST support schema-determined IDs for barename processing, any additional behavior is implementation defined.
19:21:44 [MSM]
i.e. Is this a correct understanding of the convergence identified in comment #7? (1) Barenames must be supported for attributes recognized as IDs. (2) Attributes can be recognized as IDs either by means of DTD or by means of schema-validity assessment. (3) Except as otherwise specified in this spec, the circumstances under which DTD-validation and schema-validity assessment are performed (and thus: the circs under which bare names are supported in practice).
19:23:40 [kirk]
MSM: This does not exclude elements.
19:23:47 [MSM]
The difference at issue is: is it / should it be implementation-defined whether a processor which does perform DTD-based validation supports barename references using IDs declared in the DTD? I take Sandy's propposal to lean toward saying no, in that case you really are expected to support them.
19:24:01 [MSM]
s/The difference/One difference/
19:28:19 [kirk]
MSM: Should proposal state about what a DTD processor should do? Is it implementation-defined what to do here; or is the recognition implementation-defined.
19:28:53 [kirk]
Sandy: Implementation-defined whether to expose the DTD information.
19:29:51 [kirk]
MSM: Complexity of explaining this is getting to high; therefore preferring Kumar's explanation. Would prefer more interoperability, but this is too complex.
19:30:49 [kirk]
...All aspects of DTD validation is implementation-defined. Let's not worry about what happens if a DTD process does not--all processors tend to do this.
19:32:03 [kirk]
Pratul: Use the wording suggested by Kumar above for resolution of this issue.
19:32:17 [pratul]
Model validators MUST support schema-determined IDs for barename processing, any additional behavior is implementation defined
19:32:25 [kirk]
No objections
19:33:02 [MSM]
[I would be glad if the minutes could show that my first preference would be for a simpler and more general statement that barenames must be supported. I don't think XML processors that don't expose attribute types are worth supporting as components of an SML system. But I can live with this resolution in the interests of compromise and moving forward, and I rather hope that Henry will be able to live with it too, though I do not speak for him.]
19:33:23 [kirk]
RESOLUTION: Add the preceding text to the issue. Mark as Editorial, needsReview.
19:33:38 [kirk]
Pratul will close the loop with Henry.
19:34:05 [kirk]
TOPIC: fix errors in schematron variable substitution support text & example 5680
19:36:21 [kirk]
Ginny: Example seems OK to use deref(). But in subsequent context, it is not.
19:36:41 [kirk]
Pratul: Let's skip this issue.
19:36:52 [kirk]
Ginny: Agrees.
19:37:10 [kirk]
TOPIC: SML validity appeal to schema-validity is underspecified 5797
19:38:17 [kirk]
Kumar: It seems that it is OK to make strict-wildcard the default.
19:39:49 [kirk]
MSM: In practice, all processor support this mode of invocation. But schema spec does not constrain the invocation model.
19:40:25 [kirk]
No one has reason to disbelieve that these are supported in the stack.
19:40:56 [kirk]
Pratul: Thus there is no dependence on Schema 1.1
19:43:07 [kirk]
MSM: Suspected that we would allow unknown validity only when we fall back to lax-processing.
19:43:12 [Kumar`]
The processor starts from Schema-Validity Assessment (Element) (§ with no stipulated declaration or definition. If the ·validation root· and the schema determine an element declaration (by the name of the element), an attribute declaration (by the name of the attribute), or a type definition (via xsi:type), then ·strict· validation is performed; if they do not identify any declaration or definition, then no schema-validity
19:43:12 [Kumar`]
assessment is performed.
19:46:56 [kirk]
MSM: We need to rules for when we except an applicable schema there is one or none.
19:47:29 [kirk]
...easiest why to describe these rules with with strict-/lax-wildcard processing.
19:53:04 [kirk]
Kumar: We only say that the root element must not be invalid.
19:53:32 [kirk]
MSM: This is lax-wildcard mode.
19:55:07 [kirk]
MSM: What do what do we want behavior of SML validator to be?
19:55:47 [kirk]
Discussion of these issue with MSM and Kumar.
19:56:13 [MSM]
Note: ... In typical cases strict wildcard validation will be performed when the invoking process expects the ·validation root· to be declared and valid and will otherwise report an error to its environment. If the absence of a declaration for the ·validation root· counts as a successful outcome of validation, then it is preferable to use lax wildcard validation instead.
19:57:46 [kirk]
MSM: From SML point of view, then strict wild-card requires [validity] property to be VALID.
19:59:27 [MSM]
Note: From the point of view of schema-validity assessment and the resulting ·post-schema-validation infoset·, lax and strict wildcard validation produce the same result. The distinction is provided in order to provide two different terms to express the different expectations of the invoking process.
19:59:27 [MSM]
In typical cases strict wildcard validation will be performed when the invoking process expects the ·validation root· to be declared and valid and will otherwise report an error to its environment. If the absence of a declaration for the ·validation root· counts as a successful outcome of validation, then it is preferable to use lax wildcard validation instead.
19:59:27 [MSM]
The name for this method of invocation reflects the fact that it is analogous to the validation of an element information item which matches a strict wildcard.
20:00:09 [kirk]
MSM: Difference in the terms is used to reflect the difference in the attitude of the caller.
20:01:32 [kirk]
...Do we want one behavior or two behaviors. Understood convergence of the group to be two behaviors.
20:04:24 [kirk]
...Recollection from F2F: we want more complex behavior. We in the business of what we want the spec to say.
20:04:58 [kirk]
Kumar: Not change section 8, but an issue of how the schema processor is invoked.
20:05:53 [Zakim]
20:05:53 [Zakim]
20:05:55 [Zakim]
20:05:57 [Zakim]
20:05:58 [Zakim]
20:06:01 [kirk]
Ginny: Agree with MSM's description of what the group was considering.
20:06:15 [Zakim]
20:06:16 [Zakim]
XML_SMLWG()2:00PM has ended
20:06:19 [Zakim]
Attendees were Kirk, MSM, Kumar, pratul, Sandy, Ginny_Smith
20:06:21 [kirk]
Pratul: While take this up at next meeting.
20:06:33 [kirk]
Adjournment: 4:06 ET.
20:06:45 [kirk]
rrsagent, generate minutes
20:06:45 [RRSAgent]
I have made the request to generate kirk
20:10:54 [kirk]
rrsagent, make log public
20:48:28 [Zakim]
Zakim has left #sml