17:55:24 RRSAgent has joined #sml 17:55:24 logging to http://www.w3.org/2008/07/24-sml-irc 17:55:31 Zakim has joined #sml 17:59:39 zakim, this will be sml 17:59:39 ok, MSM; I see XML_SMLWG()2:00PM scheduled to start in 1 minute 18:00:40 Kirk has joined #sml 18:01:08 XML_SMLWG()2:00PM has now started 18:01:09 zakim, please call MSM-617 18:01:10 ok, MSM; the call is being made 18:01:15 +Kirk 18:01:46 zakim, please call MSM-617 18:01:46 ok, MSM; the call is being made 18:01:47 -Kirk 18:01:47 +Kirk 18:01:47 +MSM 18:01:59 +Kumar 18:02:08 +[Microsoft] 18:02:25 Zakim, Microsoft is me 18:02:25 +pratul; got it 18:02:26 chair: Pratul Dublish 18:02:27 Kumar` has joined #sml 18:02:51 scribenick: Kirk 18:02:56 +Sandy 18:03:01 scribe: Kirk Wilson 18:03:01 Kumar` has joined #sml 18:03:06 Julia sent her regrets 18:03:10 Sandy has joined #sml 18:03:18 regrets: Jim 18:03:35 rrsagent, make log public 18:03:50 regrets:Julia 18:04:11 regrets+ Jim 18:04:11 regrets+: Jim 18:04:54 zakim, who's on the phone? 18:04:54 On the phone I see Kirk, MSM, Kumar, pratul, Sandy 18:05:34 ginny has joined #sml 18:05:59 TOPIC: Approval of Minutes 18:06:23 +Ginny_Smith 18:06:34 Minutes of 7/17 18:06:45 Minutes approved without objection 18:07:09 TOPIC: How are SML URIs absolutized: 5542 18:07:43 Pratul: Henry has submitted comments, MSM essentially agreed. 18:08:02 Pratul: comment 1 was dropped from John's proposal. 18:09:31 Kumar has joined #sml 18:09:43 MSM: Curious as why point 1 of John's proposal was dropped. Why is it dropped from document level? 18:10:14 Kumar: based on point 3, since it optional 18:10:33 Ginny: based on what implementations are doing. 18:10:43 s/comment/point 18:12:13 MSM: Point 1 helps support the eventual dropping of sml:baseURI together. 18:12:29 ...Would prefer not to project more of existing code than needs to be protected. 18:12:36 Ginny: Agrees. 18:12:40 s/project/protect/ 18:19:29 Kirk3 has joined #sml 18:20:00 zakin, Kirk3 is Kirk 18:20:11 zakim, Kirk3 is Kirk 18:20:11 sorry, Kirk3, I do not recognize a party named 'Kirk3' 18:21:08 scribe: Kirk3 18:22:01 Kumar: MS will continue to support sml:baseURI. These should not be part of interop cases. 18:27:24 Ginny: Henry wants a stronger statement of deprecation than the proposal makes. 18:28:11 Kumar: If allow only on model, scenarios for which we introduced sml:baseURI will not work. 18:29:45 s/sml:baseURI will/smlif:baseURI per document will/ 18:30:45 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 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 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 Pratul: Does anyone want this to be reopened? 18:32:53 No requests to reopen the issue. 18:33:12 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 Pratul: Let's look at Henry's comment. 18:34:17 Sandy: Questions whether a consumer can support neither form of baseURIs 18:35:22 Ginny: Expressed objection last week. 18:35:40 Pratul: Whole issue should be considered? 18:36:12 Ginny: Would like to discuss point 5. 18:37:10 Sandy and Ginny requested that we reopen the discussion on 5542 18:37:37 MSM: Sandy and Ginny are suggesting a point 6: Consumers must support one or the other 18:38:34 Ginny: IS anticipating agreement with Henry's comments. 18:39:20 [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 [That would have the consequence that to get universal guarantees of readability I don't have to absolutize all URIs.] 18:40:01 [This helps IF packages avoid being verbose and illegible.] 18:40:10 kirk has joined #sml 18:40:22 [Is that about right?] 18:40:26 scribe: Kirk 18:41:11 Kumar: There is no intention to remove sml:baseURI. Probably same for COSMOS. 18:41:26 s/There is/MS has/ 18:41:46 Ginny: It is hard for the producer to know if the model is interoperable. 18:43:49 ...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 +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 Kumar: This is not a special with regarding to optional features. 18:45:33 Sandy: Agrees that every optional features has this problem, which is why we try to limit optional features. 18:46:17 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 Pratul: Have a statement that one of the other must be submitted? 18:46:37 ...Sandy agrees. 18:46:43 s/submitted/supported/ 18:47:05 s/one of/at least one of 18:47:17 Proposal: add point 6: Consumers are required to support at least one of xml:base and smlif:baseURI 18:47:48 s/Proposal/PD proposal (as MSM heard it)/ 18:49:36 Pratul: compatible with this point 6 and deprecating smlif:baseURI. 18:49:57 MSM: Doesn't see incompatibility 18:50:09 s/compatible with/incompatible with 18:50:51 MSM: Weird but not a logical contradiction. Gives direction for those using smlif:baseURI. 18:51:55 Pratul: Consumer must support must at least one smlif:baseURI and xsml:base. Then say that smlif:baseuURI is deprecated. 18:53:27 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 MSM: What this means in practice, people who want to preserve feature CANNOT claim that it will break current implementation. 18:57:34 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 ...The first meaning is what Henry is interested is trying to get at. 19:00:00 Kumar: Word "deprecated" causes confusion. Just say explicitly what it means. 19:00:29 Ginny: The statement would not be as strong as "deprecated". 19:00:37 MSM: Agree with Ginny. 19:01:16 ...We should define "deprecated" but use the word. 19:01:51 ...The word "Deprecated" carries the connotation: It is advisable not to use it. 19:02:23 What I believe HT is suggesting (and what I would support) is addition of a Note saying something like: 19:02:33 s/Note/sentence/ 19:02:35 One interestin definition of deprecate - Archaic. to pray for deliverance from. 19:03:23 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 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 -- end of proposal -- 19:05:12 Pratul: First proposal is preferred. 19:05:43 Pratul: Is everyone happy with this proposal? 19:05:54 No objection. 19:06:24 Pratul: Are we happy with saying consumers must support either smlif:baseURI / xml:base. 19:06:31 No objection 19:06:49 Consumer must support must at least one smlif:baseURI and xml:base. 19:06:59 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 Pratul: Any objection? 19:07:22 No objection. 19:07:46 Ginny: There is still comment 7b: 19:08:51 Pratul: 7b applies to situation in which consumers supports both. 19:09:46 Sandy: Compute from xml:base, if that fails, use smlif:baseURI 19:13:19 RESOLUTION: Mark 5542 as Editorial, needsReview. 19:13:51 Pratul will send email to Henry to get his approval on our approach to comments 7a and 7b. 19:14:16 TOPIC: SML URI seems overconstrained (barenames) 5543 19:15:10 Review of comment #7. 19:15:23 MSM: Assume same thing to be true of DTD-validation. 19:15:36 Pratul: This sound reasonable. 19:15:44 s/sound/sounds 19:16:11 Kumar: Proposal is not to do DTD validation. 19:16:23 MSM: No. 19:19:14 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 ...Or does it mean something else? 19:21:44 Model validators MUST support schema-determined IDs for barename processing, any additional behavior is implementation defined. 19:21:44 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 MSM: This does not exclude elements. 19:23:47 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 s/The difference/One difference/ 19:28:19 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 Sandy: Implementation-defined whether to expose the DTD information. 19:29:51 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 ...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 Pratul: Use the wording suggested by Kumar above for resolution of this issue. 19:32:17 Model validators MUST support schema-determined IDs for barename processing, any additional behavior is implementation defined 19:32:25 No objections 19:33:02 [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 RESOLUTION: Add the preceding text to the issue. Mark as Editorial, needsReview. 19:33:38 Pratul will close the loop with Henry. 19:34:05 TOPIC: fix errors in schematron variable substitution support text & example 5680 19:36:21 Ginny: Example seems OK to use deref(). But in subsequent context, it is not. 19:36:41 Pratul: Let's skip this issue. 19:36:52 Ginny: Agrees. 19:37:10 TOPIC: SML validity appeal to schema-validity is underspecified 5797 19:38:17 Kumar: It seems that it is OK to make strict-wildcard the default. 19:39:49 MSM: In practice, all processor support this mode of invocation. But schema spec does not constrain the invocation model. 19:40:25 No one has reason to disbelieve that these are supported in the stack. 19:40:56 Pratul: Thus there is no dependence on Schema 1.1 19:43:07 MSM: Suspected that we would allow unknown validity only when we fall back to lax-processing. 19:43:12 The processor starts from Schema-Validity Assessment (Element) (§3.3.4.6) 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 assessment is performed. 19:46:56 MSM: We need to rules for when we except an applicable schema there is one or none. 19:47:29 ...easiest why to describe these rules with with strict-/lax-wildcard processing. 19:53:04 Kumar: We only say that the root element must not be invalid. 19:53:32 MSM: This is lax-wildcard mode. 19:55:07 MSM: What do what do we want behavior of SML validator to be? 19:55:47 Discussion of these issue with MSM and Kumar. 19:56:13 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 MSM: From SML point of view, then strict wild-card requires [validity] property to be VALID. 19:59:27 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 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 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 MSM: Difference in the terms is used to reflect the difference in the attitude of the caller. 20:01:32 ...Do we want one behavior or two behaviors. Understood convergence of the group to be two behaviors. 20:04:24 ...Recollection from F2F: we want more complex behavior. We in the business of what we want the spec to say. 20:04:58 Kumar: Not change section 8, but an issue of how the schema processor is invoked. 20:05:53 -MSM 20:05:53 -Kumar 20:05:55 -Ginny_Smith 20:05:57 -Sandy 20:05:58 -pratul 20:06:01 Ginny: Agree with MSM's description of what the group was considering. 20:06:15 -Kirk 20:06:16 XML_SMLWG()2:00PM has ended 20:06:19 Attendees were Kirk, MSM, Kumar, pratul, Sandy, Ginny_Smith 20:06:21 Pratul: While take this up at next meeting. 20:06:33 Adjournment: 4:06 ET. 20:06:45 rrsagent, generate minutes 20:06:45 I have made the request to generate http://www.w3.org/2008/07/24-sml-minutes.html kirk 20:10:54 rrsagent, make log public 20:48:28 Zakim has left #sml