20:06:13 RRSAgent has joined #sml 20:06:13 logging to http://www.w3.org/2008/03/31-sml-irc 20:06:37 ginny has joined #sml 20:07:41 XML_SMLWG(F2F)10:00AM has now started 20:07:48 +James_Nurthen 20:07:59 Kirk has joined #sml 20:08:20 we're on the phone now\ 20:08:42 MSM has joined #sml 20:09:39 type /nick Pratul 20:09:39 Sandy, r u planning to dial in? 20:09:41 zakim, this is sml 20:09:41 MSM, this was already XML_SMLWG(F2F)10:00AM 20:09:42 ok, MSM; that matches XML_SMLWG(F2F)10:00AM 20:09:43 zakim, who's here? 20:09:43 On the phone I see James_Nurthen 20:09:44 On IRC I see MSM, Kirk, ginny, RRSAgent, pratul, Jordan, Zakim, Sandy, trackbot-ng 20:10:20 zakim, James_Nurthen is really OracleMtgRm 20:10:20 +OracleMtgRm; got it 20:10:58 +Jordan 20:11:03 +??P16 20:11:14 Sandy_ has joined #sml 20:11:16 zakim, P16 is Sandy 20:11:16 sorry, MSM, I do not recognize a party named 'P16' 20:11:27 zakim, ??P16 is me 20:11:27 +Sandy_; got it 20:11:48 Agenda is at http://lists.w3.org/Archives/Public/public-sml/2008Mar/0083.html 20:22:41 ginny_ has joined #sml 20:31:09 zeckert has joined #sml 20:31:34 ginny_ has joined #sml 20:31:54 meeting: SML face to face meeting 20:32:01 scribe: Zulah Eckert 20:32:05 scribenick: zeckert 20:35:24 http://www.w3.org/2008/03/27-sml-irc 20:35:26 http://www.w3.org/Bugs/Public/show_bug.cgi?id=5541 20:36:37 chair: pratul 20:36:38 meeting: SML F2F 20:36:40 topic: http://www.w3.org/Bugs/Public/show_bug.cgi?id=5541 20:37:37 resolution: Marked as editorial as per resolution on 3/27/08 call 20:37:53 resolution: fixed as per comment #2 (see bug) 20:39:14 ginny: this is a bug from Henry and needs to be marked editorial, decided or the editors will not do the right thing 20:41:17 topic: http://www.w3.org/Bugs/Public/show_bug.cgi?id=5587 20:44:17 ginny: could have been an editorial bug, but nervous about making that decision herself (in last call) 20:44:19 kumar: wants to mark as editorial 20:44:20 pratul: any objections to marking this bug as editorial? 20:44:22 resolution: group agrees to mark bug as editorial 20:45:27 topic: http://www.w3.org/Bugs/Public/show_bug.cgi?id=5341 20:46:26 pratul: we had a discussion on the 3/27/08 call. 20:46:28 Sandy: still reviewing. Will put remarks in bug report. 20:46:29 resolution: group will hold off until we get feedback from Sandy 20:46:38 topic: http://www.w3.org/Bugs/Public/show_bug.cgi?id=5283 20:54:31 kumar: discussion was should we call this interchange set or interchange model. 20:54:33 kumar: Sandy says prefix matching can be viewed as a form of dereferencing 20:54:34 MSM: When you talk about doing dereferencing during SML validation, you are allowed to do this but SML is silent about this - so there is no guarantee. 20:54:36 kumar: there was no disagreement about changing interchange set to interchange model. We could resolve that. And if we wanted new text inserted about alias redirection, we could open a new bug for that. 20:54:37 pratul: any objections to changing interchange set to interchange model and creating a new bug for the alias redirection text issue? 20:54:39 MSM: it is clear that these terms denote the same thing (interchange model and interchange set). They do seem to have a different connotation. So is the difference in connotation useful or not? 20:54:40 MSM: Tends to favor the word set which is more concrete than model. Prefers interchange set. 21:01:47 ginny: sees interchange set as the representation of the model that is being interchanged 21:01:48 MSM: if one monitors packets, I can tell that these are XML documents. My ability to detect that they are modeling relies much more heavily on interpretation. His instinct is that set is more useful 21:01:50 ginny: if we want to talk about representation of the model being interchange, would use set. If we are talking about validation, then its a model. 21:01:51 MSM: we are exchanging a set of representations in order to exchange the abstraction that they represent. It can be useful to use the two terms which while they denote the same thing, but that are used in different contexts. 21:01:53 kumar: has a slight preference for set 21:01:54 MSM: can live with either has a slight preference for set 21:01:56 kumar: on the list, Kirk, Ginny, and Sandy preferred model 21:01:57 pratul: so we have two proposals, MSMs (above) and the proposal that we use model interchange only. 21:02:16 Kirk: abstains from the decision 21:03:45 Sandy: prefers interchange model. Does not see sufficient benefit for having two terms. 21:03:46 Jordan: agrees with Sandy 21:03:48 Zulah: prefers MSMs proposal however understands that the editors might not 21:04:13 pratul: resolution is to change it to model interchange 21:04:15 s/Zulah/zeckert/ 21:05:28 resolution: updating bug to editorial and the term will be model interchange 21:05:56 topic: http://www.w3.org/Bugs/Public/show_bug.cgi?id=5298 21:06:27 pratul: bug is "consider using another term for URI scheme" 21:06:32 http://www.w3.org/2008/03/27-sml-irc 21:07:35 resolution: mark decided and editorial 21:07:59 resolution: use "SML URI reference scheme" 21:08:26 topic: http://www.w3.org/Bugs/Public/show_bug.cgi?id=5513 21:18:41 Why does SML define sml:ref instead of using XLink 21:18:43 kumar: studied XLink proposal and we could define this using XLink, but not clear why we would do this. SML is not in the business of defining schemes. 21:18:44 kumar: one way is to say that all sml:refs are XLinks but we need a way to distinguish the XLinks that aren't sml:refs because not all are going to be and the ones that are have different semantics 21:18:46 pratul: we have two separate issues from Henry's comment #5 - the XLink scheme and the XHTML ref scheme (seperate bug) 21:18:47 MSM: Thinks that there is a conflating of (1) why use this syntax rather than that for addressing - and - (2) why not use XLink:href as the way to identify the set of interdocument references that are being validated. 21:18:49 MSM: the answer to (2) is that not all XLink:hrefs are sml:refs. 21:18:50 MSM: not sure which is being asked 21:18:52 MSM: if you only use XLink as the addressing mechanism, fine but you will still need to sml:ref attribute to mark references 21:18:54 kumar: agrees 21:18:55 pratul: any objection to this resolution? 21:18:57 resolution: move bug to decided, with comment "sml:ref is used to identify an SML reference and is orthogonal to the mechanism used to carry an address" 21:21:14 MSM: in this bug, thinks about issue is being raised which is (3) why can't I use this to validate HTML? Issue is that you want to validate pointers to non-XML documents. 21:21:16 pratul: which is currently in a separate bug 21:21:17 topic:http://www.w3.org/Bugs/Public/show_bug.cgi?id=5520 21:22:05 s/thinks about/thinks yet another/ 21:23:28 johnarwe has joined #sml 21:24:21 Why is document defined as a character sequence? 21:24:22 pratul: we had a long discussion of this on the last call 21:26:56 + +1.828.645.aaaa 21:29:16 Julia has joined #sml 21:30:23 zakim, aaaa is Julia 21:30:23 +Julia; got it 21:32:00 SG: I think I agree with Henry, in an ideal world. Talking to an interface is better than talking to a data format. 21:32:41 MSM: (P1) document is equivalent to a character sequence. (P2) P1 fobids a DOM interface. Does not believe that this is true (P3) P2 is false. (P4) P1 leaves holes in the conformance story for a DOM interface. 21:32:45 ... But for this particular bug report, I think I agree with MSM: changing it could make the spec awkward. 21:33:37 s/SG/Sandy/ 21:34:29 MSM: infoset is not an interface 21:34:56 it's a tradeoff, between an easier to read spec, vs. a (in some sense) more complete specification. 21:35:30 MSM: the infoset spec defines a set of terms. It is a glossary. 21:36:20 in reality, if our spec only covers character sequences, then most reasonable people will understand what should be expected for other representations of XML. so the benefit of having a "complete" spec may not have that big a benefit. 21:37:08 so on balance, with sympathy to Henry's suggestion, I think our spec stands a better chance to succeed without having "information items" all over the places. 21:37:59 i can live with proposals that somehow draw the connection to non-char-sequence representations, but will not insist on it. 21:40:57 -Sandy 21:41:01 MSM: proposes resolution. Seem to be converging on the view that we don't want to change our definition. Record our intent not to change the substance of the spec and instruct the editors to draft a note for review. 21:42:31 ginny: unsure whether note is an editorial note. That it is something that the editors create. 21:42:33 MSM: thinks kumar said "note" and he is echoing that. Believes that the text kumar was proposing was not intended to change the substance - non-normative note. 21:44:39 resolution: mark decided and editorial. Editors will draft a note for group to review. Decision is that the note will be non-normative. 21:44:40 resolution: note should clarify the relationship between character stream and non-character interface is as described in those interfaces (SAX or DOM). 21:44:40 The note should clarify the relation between the XML document (character stream) and the non-character representations (SAX or DOM) 21:44:42 MSM: prefers to leave infoset out of note 21:46:24 resolution: note to the editors to mark this as needsReview after note has been drafted. 21:47:25 MSM: suggests that we create note prior to getting Henry's feedback. 21:47:57 topic: http://www.w3.org/Bugs/Public/show_bug.cgi?id=5527 21:48:18 Why is NCName optional? 21:48:55 On Friday's call, the log says: 21:48:57 19:48:28 [ginny] 21:48:59 Topic: Bug 5527 21:49:01 19:49:09 [JA] 21:49:03 I meant MSM's discussion around what is provable wrt a given impl 21:49:05 19:50:24 [ginny] 21:49:07 Kumar: namespace is optional because the function must be from a given namespace; nothing else is allowed 21:49:09 19:53:46 [MSM] 21:49:11 [For the record, Michael Kay's book on XSLT 1.0 says (p. 452) "extension functions provided by ... third parties should always be in a different namespace and will need to have a namespace prefix when called."] 21:49:14 19:54:19 [ginny] 21:49:16 Pratul: dropping it completely might be cleaner approach if required namespace is ugly 21:49:18 19:54:35 [ginny] 21:49:20 Kumar: keep it the way it is or, if causing problems, make it mandatory 22:03:59 MSM: are there people here who are fundamentally opposed to using the prefix? 22:04:01 pratul: all of our examples have used prefixed names. Believes that this is also true for COSMOS work. 22:04:03 pratul: Believes that Henry would like us to make this mandatory 22:04:05 MSM: can think of one technically sound reason to make it optional (1) because we want to put it into the anonymous name space (the same as with other built in functions). 22:04:06 MSM: however, in XSLT the prefix is required. Proposes this resolution. 22:04:08 kumar: has mild preference for making it optional but mandatory is okay 22:04:09 pratul: any objections to proposed resolution? 22:04:11 resolution: mark bug as decided and editorial. We will make prefix mandatory. 22:04:44 s/prefix/NCName/ 22:04:46 http://www.w3.org/Bugs/Public/show_bug.cgi?id=5543 22:05:03 SML URI seems overconstrained 22:06:05 "SMLURI" == SML URI Reference Scheme 22:14:08 pratul: proposal to allow the use of bare names as a special case. This doesn't create a significant implementation burden. 22:14:10 resolution: agreed 22:14:17 http://www.w3.org/TR/2003/REC-xptr-framework-20030325/ 22:14:46 bare name == short hand pointer 22:31:23 ex bare name: #xyz 22:32:13 equiv(?) smlpath1() content: #//*[@barId='xyz'] 22:34:59 johnarwe: can be DTD, schema, or user defined 22:35:00 s/short hand/shorthand/ 22:35:02 s/bare name/barename/ 22:35:03 johnarwe: could have floor and ceiling solution. You have to support smlxpath1() and you can choose to use barenames 22:35:05 kumar: thinks that this isn't deterministic 22:36:00 gen equiv form: #smlxpath1( id(xyz) ) ... but assertion is that function call (id()) outside of predicate is disallowed by xpath's LocationPath production 22:36:59 another generally equivalent form: #smlxpath1( //*[id(xyz)=.] ) 22:37:33 the id(xyz)=. portion is not precisely correct ... it's shorthand 22:37:49 the id(xyz)=. portion is not precisely correct 22:37:56 it's shorthand 22:38:32 it is shorthand (zakim, you dopey bot) 22:40:55 ...so we may not have escaped the barename issue 22:41:01 s/resolution: agreed// 22:43:39 rssagent, generate minutes 22:44:05 rrsagent, generate minutes 22:44:05 I have made the request to generate http://www.w3.org/2008/03/31-sml-minutes.html zeckert 22:45:12 sml has joined #sml 22:48:32 Ginny notes that, absent very complete knowledge of the vocabulary being processed, there is no reliable way to deterministically transform from barename to an xpath expression. 22:49:32 This is because two attributes (fooID and barID) can be derived from ID. The xpath predicate would have to choose between fooID and barID, but it has no way to know this up front. 22:51:56 ginny: at this point our conclusion is that you cannot simply, reliable, or correctly translate from barenames to xpath1.0 22:51:57 ginny: why would we not want barenames? 22:51:59 MSM: one reason is that it opens the door to application specific rules which would be difficult from the perspective of SML validators. 22:58:43 MSM: either we define the convention or implementations do - which will lead to lock-in. 22:58:44 MSM: design clearly says already that we want deref to be usable outside of a validation context. 22:58:46 johnarwe: getting back to the floor ceiling proposal, why would we not allow barenames - is there a reason 22:58:47 MSM: if you ship an interchange model with barenames, you will not get the same interoperability. 22:58:49 MSM: doesn't see a reason to outlaw barenames. Unless we think that allowing them is too much of an interoperability issue. However feels that the floor ceiling proposal is reasonable. We have good reason not to require barename support. 22:59:47 kumar: SML URI scheme is written with interoperability in mind. This is a reason not to allow it in the interoperability scheme. Can live with this being allowed but not required but would prefer that it not be allowed. 23:06:20 zeckert: indifferent on this. For management, broad interoperability if important. Could see that for a W3C standard, that having this in could make the overall specification more general. 23:06:22 general agreement 23:06:24 pratul: proposal on the table is to not allow barenames, any objection? 23:06:25 MSM: see rational. There could be pushback and this could be about whether the SML group is making the right trade offs between the management space vs. other more general domains. We can make the case that we are not trying to solve all of the worlds problems. 23:06:27 MSM: thinks that this will be a real issue when we have non-XML document. If the charter says that we are dealing with things that point to XML documents, we can perhaps put this off to another version. 23:06:28 MSM: reading of people here in the room and on the phone is not to make this more complicated 23:09:30 RESOLUTION: bug will be moved to decided and later. This should be considered for the next version. 23:09:31 s/resolution/RESOLUTION/g 23:10:31 s/topic:/Topic:/g 23:18:46 Topic: http://www.w3.org/Bugs/Public/show_bug.cgi?id=5544 23:18:48 Why does SML require that the target of SMLURI be an XML element? 23:27:17 RESOLUTION: mark bug as decided and later. When the issue is marked resolved, it will be resolved later. The group could consider this for the next version. 23:27:19 ginny: does a follow on group have to consider these? 23:27:21 MSM: this group cannot make any commitments for the next group. The groups charter could require that. 23:28:45 Topic: http://www.w3.org/Bugs/Public/show_bug.cgi?id=5546 23:28:47 Reconcile SML-IF with RFC 2557 23:31:25 -Jordan 23:36:36 kumar: conceptually RFC 2557 is similar. Issues: Cannot have multiple aliases per document. Cannot have references between two subtrees (for interdocument references) 23:36:37 MSM:the latter is not the same as saying that this cannot be done. 23:36:39 pratul: it does say that cannot resolve a reference form and outside body part to an inside body part 23:36:40 MSM: date on RFC is 1999. Thought that RFCs expired after 6 months. 23:36:42 johnarwe: this has not been superceded. 23:36:43 ginny: has not make it through complete process. 23:54:41 MSM: so those of you involved in early development of SML, why did you not use RFC 2557 for SML-IF 23:54:42 pratul: created SMLIF after SML. 23:54:44 zeckert: RFC was never discussed 23:54:45 MSM: Could it have been used? issues: needed some additional layering (i.e., interdocument references), the RFC is not an XML format (i.e., charter and MIME which cannot be schema validated) 23:54:47 pratul: cannot support multiple aliases per document 23:54:48 ginny: it seems odd to interchange in format that is not XML 23:54:50 zeckert: mentions charter (somewhat jokingly) 23:54:51 group agrees to have technical reasons and not use the charter 23:55:04 We can use MIME since 23:55:19 1. MIME data streams are not XML documents and therefore can't be schema validated 23:55:34 2. MIME does not support multiples aliases for a body part 23:55:47 3. MIME format is not easily extensible 23:56:44 s/can use/cannot use/