IRC log of sml on 2008-03-31
Timestamps are in UTC.
- 20:06:13 [RRSAgent]
- RRSAgent has joined #sml
- 20:06:13 [RRSAgent]
- logging to http://www.w3.org/2008/03/31-sml-irc
- 20:06:37 [ginny]
- ginny has joined #sml
- 20:07:41 [Zakim]
- XML_SMLWG(F2F)10:00AM has now started
- 20:07:48 [Zakim]
- +James_Nurthen
- 20:07:59 [Kirk]
- Kirk has joined #sml
- 20:08:20 [sml]
- we're on the phone now\
- 20:08:42 [MSM]
- MSM has joined #sml
- 20:09:39 [MSM]
- type /nick Pratul
- 20:09:39 [pratul]
- Sandy, r u planning to dial in?
- 20:09:41 [MSM]
- zakim, this is sml
- 20:09:41 [Zakim]
- MSM, this was already XML_SMLWG(F2F)10:00AM
- 20:09:42 [Zakim]
- ok, MSM; that matches XML_SMLWG(F2F)10:00AM
- 20:09:43 [MSM]
- zakim, who's here?
- 20:09:43 [Zakim]
- On the phone I see James_Nurthen
- 20:09:44 [Zakim]
- On IRC I see MSM, Kirk, ginny, RRSAgent, pratul, Jordan, Zakim, Sandy, trackbot-ng
- 20:10:20 [MSM]
- zakim, James_Nurthen is really OracleMtgRm
- 20:10:20 [Zakim]
- +OracleMtgRm; got it
- 20:10:58 [Zakim]
- +Jordan
- 20:11:03 [Zakim]
- +??P16
- 20:11:14 [Sandy_]
- Sandy_ has joined #sml
- 20:11:16 [MSM]
- zakim, P16 is Sandy
- 20:11:16 [Zakim]
- sorry, MSM, I do not recognize a party named 'P16'
- 20:11:27 [Sandy_]
- zakim, ??P16 is me
- 20:11:27 [Zakim]
- +Sandy_; got it
- 20:11:48 [pratul]
- Agenda is at http://lists.w3.org/Archives/Public/public-sml/2008Mar/0083.html
- 20:22:41 [ginny_]
- ginny_ has joined #sml
- 20:31:09 [zeckert]
- zeckert has joined #sml
- 20:31:34 [ginny_]
- ginny_ has joined #sml
- 20:31:54 [MSM]
- meeting: SML face to face meeting
- 20:32:01 [MSM]
- scribe: Zulah Eckert
- 20:32:05 [MSM]
- scribenick: zeckert
- 20:35:24 [Sandy]
- http://www.w3.org/2008/03/27-sml-irc
- 20:35:26 [MSM]
- http://www.w3.org/Bugs/Public/show_bug.cgi?id=5541
- 20:36:37 [zeckert]
- chair: pratul
- 20:36:38 [zeckert]
- meeting: SML F2F
- 20:36:40 [zeckert]
- topic: http://www.w3.org/Bugs/Public/show_bug.cgi?id=5541
- 20:37:37 [zeckert]
- resolution: Marked as editorial as per resolution on 3/27/08 call
- 20:37:53 [zeckert]
- resolution: fixed as per comment #2 (see bug)
- 20:39:14 [zeckert]
- 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 [zeckert]
- topic: http://www.w3.org/Bugs/Public/show_bug.cgi?id=5587
- 20:44:17 [zeckert]
- ginny: could have been an editorial bug, but nervous about making that decision herself (in last call)
- 20:44:19 [zeckert]
- kumar: wants to mark as editorial
- 20:44:20 [zeckert]
- pratul: any objections to marking this bug as editorial?
- 20:44:22 [zeckert]
- resolution: group agrees to mark bug as editorial
- 20:45:27 [zeckert]
- topic: http://www.w3.org/Bugs/Public/show_bug.cgi?id=5341
- 20:46:26 [zeckert]
- pratul: we had a discussion on the 3/27/08 call.
- 20:46:28 [zeckert]
- Sandy: still reviewing. Will put remarks in bug report.
- 20:46:29 [zeckert]
- resolution: group will hold off until we get feedback from Sandy
- 20:46:38 [zeckert]
- topic: http://www.w3.org/Bugs/Public/show_bug.cgi?id=5283
- 20:54:31 [zeckert]
- kumar: discussion was should we call this interchange set or interchange model.
- 20:54:33 [zeckert]
- kumar: Sandy says prefix matching can be viewed as a form of dereferencing
- 20:54:34 [zeckert]
- 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 [zeckert]
- 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 [zeckert]
- pratul: any objections to changing interchange set to interchange model and creating a new bug for the alias redirection text issue?
- 20:54:39 [zeckert]
- 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 [zeckert]
- MSM: Tends to favor the word set which is more concrete than model. Prefers interchange set.
- 21:01:47 [zeckert]
- ginny: sees interchange set as the representation of the model that is being interchanged
- 21:01:48 [zeckert]
- 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 [zeckert]
- 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 [zeckert]
- 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 [zeckert]
- kumar: has a slight preference for set
- 21:01:54 [zeckert]
- MSM: can live with either has a slight preference for set
- 21:01:56 [zeckert]
- kumar: on the list, Kirk, Ginny, and Sandy preferred model
- 21:01:57 [zeckert]
- pratul: so we have two proposals, MSMs (above) and the proposal that we use model interchange only.
- 21:02:16 [zeckert]
- Kirk: abstains from the decision
- 21:03:45 [zeckert]
- Sandy: prefers interchange model. Does not see sufficient benefit for having two terms.
- 21:03:46 [zeckert]
- Jordan: agrees with Sandy
- 21:03:48 [zeckert]
- Zulah: prefers MSMs proposal however understands that the editors might not
- 21:04:13 [zeckert]
- pratul: resolution is to change it to model interchange
- 21:04:15 [zeckert]
- s/Zulah/zeckert/
- 21:05:28 [zeckert]
- resolution: updating bug to editorial and the term will be model interchange
- 21:05:56 [zeckert]
- topic: http://www.w3.org/Bugs/Public/show_bug.cgi?id=5298
- 21:06:27 [zeckert]
- pratul: bug is "consider using another term for URI scheme"
- 21:06:32 [MSM]
- http://www.w3.org/2008/03/27-sml-irc
- 21:07:35 [zeckert]
- resolution: mark decided and editorial
- 21:07:59 [zeckert]
- resolution: use "SML URI reference scheme"
- 21:08:26 [zeckert]
- topic: http://www.w3.org/Bugs/Public/show_bug.cgi?id=5513
- 21:18:41 [zeckert]
- Why does SML define sml:ref instead of using XLink
- 21:18:43 [zeckert]
- 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 [zeckert]
- 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 [zeckert]
- pratul: we have two separate issues from Henry's comment #5 - the XLink scheme and the XHTML ref scheme (seperate bug)
- 21:18:47 [zeckert]
- 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 [zeckert]
- MSM: the answer to (2) is that not all XLink:hrefs are sml:refs.
- 21:18:50 [zeckert]
- MSM: not sure which is being asked
- 21:18:52 [zeckert]
- 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 [zeckert]
- kumar: agrees
- 21:18:55 [zeckert]
- pratul: any objection to this resolution?
- 21:18:57 [zeckert]
- 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 [zeckert]
- 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 [zeckert]
- pratul: which is currently in a separate bug
- 21:21:17 [zeckert]
- topic:http://www.w3.org/Bugs/Public/show_bug.cgi?id=5520
- 21:22:05 [MSM]
- s/thinks about/thinks yet another/
- 21:23:28 [johnarwe]
- johnarwe has joined #sml
- 21:24:21 [zeckert]
- Why is document defined as a character sequence?
- 21:24:22 [zeckert]
- pratul: we had a long discussion of this on the last call
- 21:26:56 [Zakim]
- + +1.828.645.aaaa
- 21:29:16 [Julia]
- Julia has joined #sml
- 21:30:23 [johnarwe]
- zakim, aaaa is Julia
- 21:30:23 [Zakim]
- +Julia; got it
- 21:32:00 [MSM]
- 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 [zeckert]
- 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 [MSM]
- ... But for this particular bug report, I think I agree with MSM: changing it could make the spec awkward.
- 21:33:37 [zeckert]
- s/SG/Sandy/
- 21:34:29 [zeckert]
- MSM: infoset is not an interface
- 21:34:56 [Sandy]
- it's a tradeoff, between an easier to read spec, vs. a (in some sense) more complete specification.
- 21:35:30 [zeckert]
- MSM: the infoset spec defines a set of terms. It is a glossary.
- 21:36:20 [Sandy]
- 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 [Sandy]
- 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 [Sandy]
- i can live with proposals that somehow draw the connection to non-char-sequence representations, but will not insist on it.
- 21:40:57 [Zakim]
- -Sandy
- 21:41:01 [zeckert]
- 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 [zeckert]
- ginny: unsure whether note is an editorial note. That it is something that the editors create.
- 21:42:33 [zeckert]
- 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 [zeckert]
- 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 [zeckert]
- 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 [pratul]
- The note should clarify the relation between the XML document (character stream) and the non-character representations (SAX or DOM)
- 21:44:42 [zeckert]
- MSM: prefers to leave infoset out of note
- 21:46:24 [zeckert]
- resolution: note to the editors to mark this as needsReview after note has been drafted.
- 21:47:25 [zeckert]
- MSM: suggests that we create note prior to getting Henry's feedback.
- 21:47:57 [zeckert]
- topic: http://www.w3.org/Bugs/Public/show_bug.cgi?id=5527
- 21:48:18 [zeckert]
- Why is NCName optional?
- 21:48:55 [MSM]
- On Friday's call, the log says:
- 21:48:57 [MSM]
- 19:48:28 [ginny]
- 21:48:59 [MSM]
- Topic: Bug 5527
- 21:49:01 [MSM]
- 19:49:09 [JA]
- 21:49:03 [MSM]
- I meant MSM's discussion around what is provable wrt a given impl
- 21:49:05 [MSM]
- 19:50:24 [ginny]
- 21:49:07 [MSM]
- Kumar: namespace is optional because the function must be from a given namespace; nothing else is allowed
- 21:49:09 [MSM]
- 19:53:46 [MSM]
- 21:49:11 [MSM]
- [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 [MSM]
- 19:54:19 [ginny]
- 21:49:16 [MSM]
- Pratul: dropping it completely might be cleaner approach if required namespace is ugly
- 21:49:18 [MSM]
- 19:54:35 [ginny]
- 21:49:20 [MSM]
- Kumar: keep it the way it is or, if causing problems, make it mandatory
- 22:03:59 [zeckert]
- MSM: are there people here who are fundamentally opposed to using the prefix?
- 22:04:01 [zeckert]
- pratul: all of our examples have used prefixed names. Believes that this is also true for COSMOS work.
- 22:04:03 [zeckert]
- pratul: Believes that Henry would like us to make this mandatory
- 22:04:05 [zeckert]
- 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 [zeckert]
- MSM: however, in XSLT the prefix is required. Proposes this resolution.
- 22:04:08 [zeckert]
- kumar: has mild preference for making it optional but mandatory is okay
- 22:04:09 [zeckert]
- pratul: any objections to proposed resolution?
- 22:04:11 [zeckert]
- resolution: mark bug as decided and editorial. We will make prefix mandatory.
- 22:04:44 [zeckert]
- s/prefix/NCName/
- 22:04:46 [zeckert]
- http://www.w3.org/Bugs/Public/show_bug.cgi?id=5543
- 22:05:03 [zeckert]
- SML URI seems overconstrained
- 22:06:05 [zeckert]
- "SMLURI" == SML URI Reference Scheme
- 22:14:08 [zeckert]
- pratul: proposal to allow the use of bare names as a special case. This doesn't create a significant implementation burden.
- 22:14:10 [zeckert]
- resolution: agreed
- 22:14:17 [johnarwe]
- http://www.w3.org/TR/2003/REC-xptr-framework-20030325/
- 22:14:46 [zeckert]
- bare name == short hand pointer
- 22:31:23 [johnarwe]
- ex bare name: #xyz
- 22:32:13 [johnarwe]
- equiv(?) smlpath1() content: #//*[@barId='xyz']
- 22:34:59 [zeckert]
- johnarwe: can be DTD, schema, or user defined
- 22:35:00 [zeckert]
- s/short hand/shorthand/
- 22:35:02 [zeckert]
- s/bare name/barename/
- 22:35:03 [zeckert]
- johnarwe: could have floor and ceiling solution. You have to support smlxpath1() and you can choose to use barenames
- 22:35:05 [zeckert]
- kumar: thinks that this isn't deterministic
- 22:36:00 [johnarwe]
- 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 [johnarwe]
- another generally equivalent form: #smlxpath1( //*[id(xyz)=.] )
- 22:37:33 [johnarwe]
- the id(xyz)=. portion is not precisely correct ... it's shorthand
- 22:37:49 [johnarwe]
- the id(xyz)=. portion is not precisely correct
- 22:37:56 [johnarwe]
- it's shorthand
- 22:38:32 [johnarwe]
- it is shorthand (zakim, you dopey bot)
- 22:40:55 [johnarwe]
- ...so we may not have escaped the barename issue
- 22:41:01 [zeckert]
- s/resolution: agreed//
- 22:43:39 [zeckert]
- rssagent, generate minutes
- 22:44:05 [zeckert]
- rrsagent, generate minutes
- 22:44:05 [RRSAgent]
- I have made the request to generate http://www.w3.org/2008/03/31-sml-minutes.html zeckert
- 22:45:12 [sml]
- sml has joined #sml
- 22:48:32 [johnarwe]
- 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 [johnarwe]
- 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 [zeckert]
- ginny: at this point our conclusion is that you cannot simply, reliable, or correctly translate from barenames to xpath1.0
- 22:51:57 [zeckert]
- ginny: why would we not want barenames?
- 22:51:59 [zeckert]
- 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 [zeckert]
- MSM: either we define the convention or implementations do - which will lead to lock-in.
- 22:58:44 [zeckert]
- MSM: design clearly says already that we want deref to be usable outside of a validation context.
- 22:58:46 [zeckert]
- johnarwe: getting back to the floor ceiling proposal, why would we not allow barenames - is there a reason
- 22:58:47 [zeckert]
- MSM: if you ship an interchange model with barenames, you will not get the same interoperability.
- 22:58:49 [zeckert]
- 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 [zeckert]
- 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]
- 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 [zeckert]
- general agreement
- 23:06:24 [zeckert]
- pratul: proposal on the table is to not allow barenames, any objection?
- 23:06:25 [zeckert]
- 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 [zeckert]
- 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 [zeckert]
- MSM: reading of people here in the room and on the phone is not to make this more complicated
- 23:09:30 [zeckert]
- RESOLUTION: bug will be moved to decided and later. This should be considered for the next version.
- 23:09:31 [zeckert]
- s/resolution/RESOLUTION/g
- 23:10:31 [zeckert]
- s/topic:/Topic:/g
- 23:18:46 [zeckert]
- Topic: http://www.w3.org/Bugs/Public/show_bug.cgi?id=5544
- 23:18:48 [zeckert]
- Why does SML require that the target of SMLURI be an XML element?
- 23:27:17 [zeckert]
- 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 [zeckert]
- ginny: does a follow on group have to consider these?
- 23:27:21 [zeckert]
- MSM: this group cannot make any commitments for the next group. The groups charter could require that.
- 23:28:45 [zeckert]
- Topic: http://www.w3.org/Bugs/Public/show_bug.cgi?id=5546
- 23:28:47 [zeckert]
- Reconcile SML-IF with RFC 2557
- 23:31:25 [Zakim]
- -Jordan
- 23:36:36 [zeckert]
- 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 [zeckert]
- MSM:the latter is not the same as saying that this cannot be done.
- 23:36:39 [zeckert]
- pratul: it does say that cannot resolve a reference form and outside body part to an inside body part
- 23:36:40 [zeckert]
- MSM: date on RFC is 1999. Thought that RFCs expired after 6 months.
- 23:36:42 [zeckert]
- johnarwe: this has not been superceded.
- 23:36:43 [zeckert]
- ginny: has not make it through complete process.
- 23:54:41 [zeckert]
- MSM: so those of you involved in early development of SML, why did you not use RFC 2557 for SML-IF
- 23:54:42 [zeckert]
- pratul: created SMLIF after SML.
- 23:54:44 [zeckert]
- zeckert: RFC was never discussed
- 23:54:45 [zeckert]
- 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 [zeckert]
- pratul: cannot support multiple aliases per document
- 23:54:48 [zeckert]
- ginny: it seems odd to interchange in format that is not XML
- 23:54:50 [zeckert]
- zeckert: mentions charter (somewhat jokingly)
- 23:54:51 [zeckert]
- group agrees to have technical reasons and not use the charter
- 23:55:04 [pratul]
- We can use MIME since
- 23:55:19 [pratul]
- 1. MIME data streams are not XML documents and therefore can't be schema validated
- 23:55:34 [pratul]
- 2. MIME does not support multiples aliases for a body part
- 23:55:47 [pratul]
- 3. MIME format is not easily extensible
- 23:56:44 [ginny]
- s/can use/cannot use/