See also: IRC log
<MSM> http://www.w3.org/2005/02/minutes
<MSM> log at http://www.w3.org/2008/03/31-sml-irc.txt
<MSM> http://www.w3.org/2008/03/31-sml-irc.html
<johnarwe> Triage unclassified bugs - we have some new ones arriving from XQuery!
Add namespace prefix to deref function in section title
MSM: Add the word "The"
Ginny: recommends not fixing it. Makes title longer. Style objection to fixing the bug.
MSM: Prefers to add namespace prefix. (Kirk agrees.)
Sandy: We need to add it somewhere. First occurrence of namespace prefix is in section 5.
Ginny: We can mention it in the section.
Pratul: Proposal: fix according to the bug.
John: 4 votes (MSM, Kirk, Pratul, Sandy)
to make the change.
... Question is whether we should include "The".
The sense of the work group is not to add a "The" just to this title.
Ginny: Does not want to change all the titles.
RESOLUTION: Fix this bug as per bug and mark as editorial.
MSM: We need to turn acyclic on in cases
where sml:ref is not specified.
... Our response should be: This is clear from the text , we believe it
is necessary to allow this, and made clear in table 5-2.
... A sophisticated validator may detect a situation in which the
complex type would not be able to support an SML reference (e.g., no
attribute wild-card). A validator is free to identify this as an error.
... In the schema, one can specify:
... 1. sml:ref is specified with Fixed Value (true or false)
... 2. sml:ref explicitly declared as attribute as part of CT def.
"intent"
... 3. anyAttribute on ctd allows sml:ref
... 4. "silent" ==> sml:ref Forbidden
John: response to bug: acyclic is allowed
on any ctd.
...MSM: We should quote the text that it is allowed on any ctd element,
and from table 5.2.
MSM: There are no restrictions on the ctd elements that allow the sml:ref attribute.
RESOLUTION: The spec makes it clear that there are no restrictions on ctd elements that allow sml:ref attribute. Bug is marked Decided.
Need focused small examples in-line
Pratul: We had that and took them out!
MSM: Can say globally that examples are non-normative.
John: We could point to specific examples in the text.
Pratul: We say that we don't fix since we had it that way.
Ginny: They (XQuery wg) might be able to point out where they would add the examples.
MSM: Suggests putting in the short examples.
John: Proposal: To address bug by referring to the existing examples to the appendices from the text instead of writing new examples.
Ginny: Suggests putting anchors in existing examples to use more focused references.
RESOLUTION: WG agrees to insert references to the examples in the appendices within the text. They should let us know where examples would help. Moved to Editorial / Decided.
xlink: 5561: http://www.w3.org/Bugs/Public/show_bug.cgi?id=5561
references in XHTML: 5562: http://www.w3.org/Bugs/Public/show_bug.cgi?id=5562
Decision: let's start with 5562
John: This is a "paper exercise" to see
how easy it is to define SML reference schemes.
... Issue--what do we with this: publish as a note, just keep it to
ourselves as an exercise, or publish as part of spec.
... MSM prefers using this as part of spec (normative)
MSM: Two href ref schemes are possible: one that covers everything of interest and one that covers easy cases.
<MSM> http://www.w3.org/TR/html4/struct/objects.html#h-13.3
XHMTL: a formal, XML definition of HTML document.
<johnarwe> http://www.w3.org/TR/2000/REC-xhtml1-20000126/
MSM: easy one: href in <a>, <link>.
Pratul: Proposal: Attributes of the <object>Class Id, codebase, data, usemap whose values are of type anyURI, these are to be treated as SML reference provided that sml:ref="true" on the <object> element.
MSM: need targetType constraint on each of these attributes.
Hypothesis: could we define these as
different reference schemes for each attribute.
... BUT we can only use one targetType attribute.
... If we have two reference schemes on same <object> element,
then have different objects being referenced by a single SML ref element.
Violates SML ref semantics (consistency amongst ref schemes in single SML ref).
Discussion of our goals relative to this use case.
MSM: Our response had been that anyone could do this, easily. But we are now seeing that it is not possible.
Pratul: Henry only mentioned one attribute (href). We can do that.
MSM: Henry has asked if we can have link
checking.
... HTML is a widespread language. We can't say we have a tool that
doesn't work with the signature language of the W3C. We need to weigh
the tradeoffs.
... We need to support widely used references in widely used languages
as an important use case.
... The problem arises from an interaction between XML and our
decisions on SML Reference.
Issues regarding linking in XHTML:
1. If SML references are elements, HTML elements that carry multiple hyperlinks as is a problem.
scribe: a. If some hyperlinks are in children, we have a solution.
2. Where multiple hyperlinks are in attributes, this is a problem for current spec.
scribe: a. Problem is that there can be multiple objects pointed to by different attributes, thereby violating the consistency semantics of an SML ref. Treating them as instances of multiple ref schemes is a non-starter if a consumer understands >1 ref scheme amongst those used.
<Sandy> Example. <img> in HTML has 4 URL attributes
<Sandy> src URL The URL of the image to display
<Sandy> ismap URL Defines the image as a server-side image map
<Sandy> longdesc URL A URL to a document that contains a long description of the image
<Sandy> usemap URL Defines the image as a client-side image map. Look at the <map> and <area> tags to figure out how it works
MSM: Change conception of SML reference
to allow attributes; then treat element as having multiple references:
... Can we have constraints?
... Can we be selective about what attributes are SML references.
... Can that one attribute be an instance of multiple schemes?
<johnarwe> http://www.w3.org/TR/html4/struct/links.html#h-12.2
MSM: Can we describe a reference scheme for <a>. What do we need to say to make that work?
Pratul: We could just put all attributes we want on the <a> element.
Resolution Process: We need to say:
1. It is an <a> element with an href attribute, and sml.ref="true"
2. Rules for resolution: We need to specify that you
can use bare-names. You need to resolve to elements.
...Note: if href goes to something not an element, this is unresolved.
3. Target-complete identifier: Yes.
Discussion of resolution process:
...MSM: Use a termporary element that maps to the mime-type of what is
returned. Thus, you get an element back and you can correctly say that
the reference resolves, and correctly identifies when link fails.
<Sandy> question: is the "temporary element" considered as part of the model being processed/validated?
MSM: Map to a unique element for each different mime-type.
<pratul> It will be considered a part of model since we're evaluating constraints on it
<johnarwe> MSM: insight: as long as you can generate a complete list of types you do accept, then you can create a target type constraint to exclude others. if you cannot generate the complete list, not clear that we have a solution.
<pratul> Whether we want to allow models to contain non XML doc is an interesting issue
MSM: We want to use targetRequired, targetType could be used.
<Sandy> and that temporary element belongs to a document? and that document will be validated as part of the model validation?
<pratul> Sandy the short answer is no
MSM: Tentative result is that we can handle href on <a> .
<pratul> IMO, we should not allow non XML docs in an SML model
MSM: Sandy's first question: Yes, the
temp elements are considered parts of the model.
... This should follow what is required by the SML spec
... These special elements would have to be in model for this to work.
... SML-IF must include these elements in the package. . .WITH ALIASES
... SML, however, the link checker says "they are in the model".
... The "temporary" elements are elements in a document because we
require what is referenced has to be an XML document or fragment.
... Version 2 of HTML resolution scheme: You go to the net. Then that
is not interoperable. Have we violated any of the rules in our specs?
Should there be rules that prevent this.
Kumar: If target-complete we can do alias matching.
Pratul: Should the elements be part of the model?
MSM: What a priori knowledge are we
allowed to have with regard to an SML implementation regarding what is
in the model?
... One answer: A referenced document is in the model. I infer that the
document is in the documentl
... Other answer: We begin with the documents in the model, then
anything outside the model is not an SML reference.
<pratul> A model is a set of documents
<pratul> How this set is specified is implementation dependent
Sandy: We don't need to be clear, both should be allowed. You need a definition of your model before you start.
<pratul> So an implementation can take the transitive closure of the inter-doc references and use it to define the model
MSM: His point is to say one way or the other, or that it is implementation defined.
Sandy: Not an implementation choice. We should say: we don't care how you define your model. You just need a definition to start.
MSM: This is a matter of how processor behaves.
<pratul> Not sure how "we don't care" differs from "implementation defined"
Pratul: This is clear in SML-IF.
Kumar: Have we achieved the goal of having an href scheme?
<pratul> What I meant is that the defn of model is very clear in SML IF, which is needed to ensure interop
<pratul> There is no problem if two implementations allow users to specify models in different ways
<pratul> E.g., one may require explicit enumeration of documents
<pratul> another could compute transitive closure starting from a set of docs
MSM: We should walk through the example
on more time. We must be able to provide a persuasive description of
how an href scheme on <a> is processed. It seems that we are
close. We need to see how this works in IF.
... Dynamic adding of document is legal in SML, but not SML-IF.
Breaking for lunch 12:30.
<zeckert> scribe:zeckert
<scribe> scribenick: Zulah
<johnarwe> [zulah's iphone quacks] John agrees to scribe while Zulah takes call
<johnarwe> discussion of scope - how much sml needs to solve to be "interesting" or "useful"
<johnarwe> question 1 remaining: pre-lunch ex of html:a as an sml ref scheme, and how that plays in smlif
<johnarwe> question 2 remaining: html:img and see if "better than nothing" ref scheme can cover/how well it covers images
<johnarwe> single document with html:a elements containing hrefs, i.e. what is on the whiteboard in this room
<johnarwe> <a href="foo.tiff">
<johnarwe> <a href="my.html#here">
<johnarwe> <a href="my.jpg">
<johnarwe> what needs to be done in order to exchange this document/model; it has a base uri <base href="...">
<johnarwe> each of the <a href>'s above also has sml:ref=true
<johnarwe> i.e. they are sml refs
<johnarwe> if we _assume_ that we have 4 entities in the model (one for the document == base + 3 <a href= >) + 1 for each of the 3 refs, then what shows up when this is serialized to smlif?
<johnarwe> MSM: in the smlif instance, 4 inst docs show up: "the doc == b + 3 <a href= >", 1 <jpg/> w/ alias of my.jpg, 1 <tiff/> w/ alias of foo.tiff, ... what for my.html?
<johnarwe> choice - 1 if my.html is xhtml, serve it as xml. 2 if my.html not legal xml, but we want to in-line it so we make an xml surrogate (run it through tidy, producing xhtml). 3 not xml, don't care about int structure, so treat analogously to image files ( <html/> ).
<johnarwe> ginny notes that an smlif consumer receiving a pkg containing these surrogates for images will never go out to the network to find the images (it has slightly different info).
<johnarwe> MSM: in such a consumer, the resolution rule stating "recognize the ref scheme and substitute the surrogate documents for images in here" never fires. for an sml (vs smlif processor), the rule would fire.
<johnarwe> [zulah returns]
<MSM> SG and MSM agree (MSM thinks): (1) update definition of SML reference in 2.2 Terminology
<MSM> (2) change description of unresolved SML references in 4.1.3.
<MSM> MSM suggests just adding "to any element in the model" (assuming we are sticking with resolution only to elements)
<MSM> Alternative (SG suggested this earlier): make clear that "resolve" means only pointing to things in the model.
<MSM> Kirk, Kumar, various others: (3) and we also need to make clear (as agreed this morning) that the method of determining what documents are in the model is implementation-defined (or implementation-dependent): you can have an a priori list, you can take the transitive closure of documents referred to by SML references starting from documents known to be in the model, or you can do anything in between.
<johnarwe> http://www.w3.org/TR/html4/struct/links.html#h-12.3
<johnarwe> http://www.w3.org/TR/2001/REC-xlink-20010627/#link-locators
<pratul> The XLInk spec says if type="none" then
<pratul> When the value of the type attribute is "none", the element has no XLink-specified meaning, and any XLink-related content or attributes have no XLink-specified relationship to the element.