See also: IRC log
<pratul> Agenda is at http://lists.w3.org/Archives/Public/public-sml/2008Mar/0083.html
<MSM> scribe: Zulah Eckert
<MSM> scribenick: zeckert
RESOLUTION: Marked as editorial as per
RESOLUTION on 3/27/08 call
... fixed as per comment #2 (see bug)
ginny: this is a bug from Henry and needs to be marked editorial, decided or the editors will not do the right thing
ginny: could have been an editorial bug, but nervous about making that decision herself (in last call)
kumar: wants to mark as editorial
pratul: any objections to marking this bug as editorial?
There was no objection.
RESOLUTION: group agrees to mark bug as editorial
pratul: we had a discussion on the 3/27/08 call.
Sandy: still reviewing. Will put remarks in bug report.
RESOLUTION: group will hold off until we get feedback from Sandy
kumar: discussion was should we call this interchange set
or interchange model.
... Sandy says prefix matching can be viewed as a form of dereferencing
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.
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.
pratul: any objections to changing interchange set to interchange model and creating a new bug for the alias redirection text issue?
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?
... Tends to favor the word set which is more concrete than model.
Prefers interchange set.
ginny: sees interchange set as the representation of the model that is being interchanged
MSM: if one monitors packets, I can tell that these are XML documents. My ability to detect what they are modeling relies much more heavily on interpretation. My instinct is that set is more useful.
ginny: if we want to talk about representation of the model being interchanged, would use set. If we are talking about validation, then it is a model.
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, are used in different contexts.
kumar: has a slight preference for set
MSM: can live with either has a slight preference for set
kumar: on the list, Kirk, Ginny, and Sandy preferred model
pratul: so we have two proposals, MSMs (above) and the proposal that we use interchange model only.
Kirk: abstains from the decision
Sandy: prefers interchange model. Does not see sufficient benefit for having two terms.
Jordan: agrees with Sandy
zeckert: prefers MSMs proposal however understands that the editors might not
pratul: proposal is to change it to interchange model
There was no objection.
RESOLUTION: the group agrees to updating the bug to editorial and the term will be interchange model
pratul: bug is "consider using another term for URI scheme"
<MSM> http://www.w3.org/2008/03/27-sml-irc
RESOLUTION: mark decided and editorial
... use "SML URI reference scheme"
Why does SML define sml:ref instead of using XLink?
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.
... 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
pratul: we have two separate issues from Henry's comment #5 - the XLink scheme and the XHTML ref scheme (separate bug)
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.
... the answer to (2) is that not all XLink:hrefs are sml:refs.
... not sure which is being asked
... if you only use XLink as the addressing mechanism, fine but you
will still need to sml:ref attribute to mark references
kumar: agrees
pratul: any objection to this RESOLUTION?
There was no objection.
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"
MSM: in this bug, thinks yet another 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.
pratul: which is currently in a separate bug
Why is document defined as a character sequence?
pratul: we had a long discussion of this on the last call
<MSM> Sandy: I think I agree with Henry, in an ideal world. Talking to an interface is better than talking to a data format.
MSM:Propositions: (P1) document is equivalent to a character sequence. (P2) P1 forbids 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.
<Sandy> ... But for this particular bug report, I think I agree with MSM: changing it could make the spec awkward.
MSM: infoset is not an interface
<Sandy> it's a tradeoff, between an easier to read spec, vs. a (in some sense) more complete specification.
MSM: the infoset spec defines a set of terms. It is a glossary.
<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.
<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 place.
<Sandy> I can live with proposals that somehow draw the connection to non-char-sequence representations, but will not insist on it.
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.
ginny: unsure whether note is an editorial note. That it is something that the editors create.
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.
RESOLUTION: mark decided and editorial.
Editors will draft a note for group to review and mark the bug as needsReview after note has been
drafted. Decision is that the
note will be non-normative.
... note should clarify the relationship between character stream and
non-character interface is as described in those interfaces (SAX or
DOM).
<pratul> The note should clarify the relation between the XML document (character stream) and the non-character representations (SAX or DOM)
MSM: prefers to leave infoset out of note
MSM: suggests that we create note prior to getting Henry's feedback.
Why is NCName optional?
<MSM> On Friday's call, the log says:
<MSM> 19:48:28 [ginny]
<MSM> 19:49:09 [JA]
<MSM> I meant MSM's discussion around what is provable wrt a given impl
<MSM> 19:50:24 [ginny]
<MSM> Kumar: namespace is optional because the function must be from a given namespace; nothing else is allowed
<MSM> 19:53:46 [MSM]
<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."]
<MSM> 19:54:19 [ginny]
<MSM> Pratul: dropping it completely might be cleaner approach if required namespace is ugly
<MSM> 19:54:35 [ginny]
<MSM> Kumar: keep it the way it is or, if causing problems, make it mandatory
MSM: are there people here who are fundamentally opposed to using the prefix?
pratul: all of our examples have used prefixed names.
Believes that this is also true for COSMOS work.
... Believes that Henry would like us to make this mandatory
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).
... however, in XSLT the prefix is required. Proposes this RESOLUTION.
kumar: has mild preference for making it optional but mandatory is okay
pratul: any objections to proposed RESOLUTION?
There are no objections.
RESOLUTION: mark bug as decided and editorial. We will make NCName mandatory.
SML URI seems overconstrained
"SMLURI" == SML URI Reference Scheme
pratul: proposal to allow the use of bare names as a special case. This doesn't create a significant implementation burden.
<johnarwe> http://www.w3.org/TR/2003/REC-xptr-framework-20030325/
bare name == shorthand pointer
<johnarwe> ex barename: #xyz
<johnarwe> equiv(?) smlpath1() content: #//*[@barId='xyz']
johnarwe: can be DTD, schema, or user defined
... could have floor and ceiling solution. You have to support
smlxpath1() and you can choose to use barenames
kumar: thinks that this isn't deterministic
<johnarwe> gen equiv form: #smlxpath1( id(xyz) ) ... but assertion is that function call (id()) outside of predicate is disallowed by xpath's LocationPath production
<johnarwe> another generally equivalent form: #smlxpath1( //*[id(xyz)=.] )
<johnarwe> the id(xyz)=. portion is not precisely correct ... it's shorthand
<johnarwe> ...so we may not have escaped the barename issue
<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.
<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.
ginny: at this point our conclusion is that you cannot
simply, reliably, or correctly translate from barenames to xpath1.0
... why would we not want barenames?
MSM: one reason is that it opens the door to application
specific rules which would be difficult from the perspective of SML
validators.
... either we define the convention or implementations do - which will
lead to lock-in.
... design clearly says already that we want deref to be usable outside
of a validation context.
johnarwe: getting back to the floor ceiling proposal, why would we not allow barenames - is there a reason
MSM: if you ship an interchange model with barenames, you
will not get the same interoperability.
... 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.
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.
zeckert: indifferent on this. For management, broad interoperability is important. Could see that for a W3C standard, that having this in could make the overall specification more general.
general agreement
pratul: proposal on the table is to not allow barenames, any objection?
MSM: see rationale. 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.
... 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.
... reading of people here in the room and on the phone is not to make
this more complicated
There are no objections.
RESOLUTION: bug will be moved to decided and later. This should be considered for the next version.
Why does SML require that the target of SMLURI be an XML element?
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.
ginny: does a follow on group have to consider these?
MSM: this group cannot make any commitments for the next group. The next group's charter could require that.
Reconcile SML-IF with RFC 2557
kumar: conceptually RFC 2557 is similar. Issues: Cannot have multiple aliases per document. Cannot have references between two subtrees (for interdocument references)
MSM: the latter is not the same as saying that this cannot be done.
pratul: it does say that cannot resolve a reference from an outside body part to an inside body part
MSM: date on RFC is 1999. Thought that RFCs expired after 6 months.
johnarwe: this has not been superseded.
ginny: has not made it through complete process.
MSM: so those of you involved in early development of SML, why did you not use RFC 2557 for SML-IF
pratul: created SMLIF after SML.
zeckert: RFC was never discussed
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)
pratul: cannot support multiple aliases per document
ginny: it seems odd to interchange in format that is not XML
zeckert: mentions charter
group agrees to have technical reasons and not use the charter
<pratul> We cannot use MIME since
<pratul> 1. MIME data streams are not XML documents and therefore can't be schema validated
<pratul> 2. MIME does not support multiples aliases for a body part
<pratul> 3. MIME format is not easily extensible