W3C SML Face to Face Meeting of 2008-04-01

01 Apr 2008

See also: IRC log


Michael (MSM), Kumar, Ginny, John, Kirk, Pratul, Zulah (in afternoon)
On Telephone
Julia, Jordan, Sandy
johnarwe, Pratul Dublish
Kirk Wilson (morning), Zulah Eckert (afternoon)




<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!

5598: http://www.w3.org/Bugs/Public/show_bug.cgi?id=5598

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.

5599: http://www.w3.org/Bugs/Public/show_bug.cgi?id=5599

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.

5600 http://www.w3.org/Bugs/Public/show_bug.cgi?id=5600

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.

Other reference schemes 5561 & 5562

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

http://www.w3.org/Bugs/Public/show_bug.cgi?id=5562 Cont.   

    SML should define an XHTML href Reference Scheme

<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

continuation of xhtml:a discussion - better than nothing ref scheme

<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: two ways to view this (1) sml ref gets resolved but it is not in the model => sml ref is bogus, (2) is this a resolved sml reference, no because it did not resolve to something in the model therefore it is not an sml ref.

    johnarwe: definition of sml ref is that it is in the model

    MSM: I can assume that it is an unresolved sml ref. Is this valid?

     kumar: thinks that we can meet both conditions - foo.tiff is in the model and this is an sml ref. The target of the sml ref is the surrogate document, not the element.

    MSM: Means neither foo.tiff or a surrogate - nothing that foo.tiff resolves to

    MSM: moving to a non-surrogate example. Illustrates point with SML URI that "points" to foo.xml. The document foo.xml is not in the model. Which must be the case, and what are the other possibilities. There is an error in the model because it points to something outside the model, and we have two cases :(1) inconsistent, (2) unresolved. Which case is it?

    johnarwe: must an error be raised?

    kumar: if the target doesn't exist it is unresolved.

    ginny: wants to know where spec says that a reference that is not in the model is required to be unresolved.

    kumar: this is defined for the URI scheme. Its in Section 4.3.1 bullet 2.b.

    ginny: spec is unclear on this.

    MSM: unless something makes explicit that you can only dereference things that are in the model. It is not clear from the test that you are required to behave in this way.

    kumar: but a model is a set of interrelated documents. This is stated in the spec, it does not have to be restated.

    Sandy: thinks that it is true that the spec is not that clear. Section 4.1.1-4.1.3.. Resolved means that you have established a link. Otherwise, the link is not resolved according to section 4.1.3.

    Sandy: (1) not bogus, just not resolved, (2) spec is unclear but is not resolved

    Sandy: clarify resolved and ...

    MSM: doesn't think that the conclusions follow from the spec as currently written. If we want this then (1) change definition of sml ref in terminology section to account more clearly for unresolved references and (2) rather than hack the definition of resolution, suggests changing item 2 in the list of 4.1.3 to reflect that something has to resolve to something in the model. Not sure how to...

    ...get a clearer definition of resolved. If something is outside of the model, then for our purposes it is an unresolved ref.

    MSM: to tell a consistent story, you have to agree that sml refs resolve to something and they are in the model or that it resolves to something that is not in the model and is therefore unresolved, or it does not resolve to something that is in the model.

    kumar: two changes then, resolves means to something in the model and we need to clarify what it means to be in the model. A priori fixed list, transitive closure.

    MSM: if we don't define what it means to be in the model then we have to be prepared for implementations to do inconsistent things.

    kumar: if we define these things, does it solve our problem.

<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.

    Sandy: agrees that defining resolution may be difficult and thinks that we could avoid the word all together

     MSM: concerned about using the term resolved consistently with the rest of the web community

<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.

    ginny, opened a bug for (1), (2), and (3) above
    Bug: http://www.w3.org/Bugs/Public/show_bug.cgi?id=5606

MSM: returning to the question that we were phrasing in terms of foo.tiff

MSM: from the sml point of view if the surrogate is not in the model then this is an unresolved ref

johnarwe: so returning to question 1 remaining: pre-lunch ex of html:a as an sml ref scheme, and how that plays in smlif and question 2 remaining: html:img and see if "better than nothing" ref scheme can cover/how well it covers images

<johnarwe> http://www.w3.org/TR/html4/struct/links.html#h-12.3

    MSM: If you wanted to convince someone that you could build a link checker, thinks you would need href on the a, images, and the link element.

    <link href='my.css" type='text/css' />

    <link href='my.n3' type='application/n3' />

    MSM: if I dereference either of these and I don't get the type specified, its an error.

    <xs:element name='link' type='linktype' targetRequired='true'
    targetType='ger:mime.css' />

    <css type=ger:mime.css' mimetype='text/css" /> <:-- generated as a surrogate for my.css -->

    MSM: when mine.css is dereferenced, I want to get back the mime type text/css

    MSM: two solutions - use conditional type assignment (schema 1.1)

    if @type='text/css' => ger:css

    if @type='____' => ger:...

    MSM: requires schema 1.1

    MSM: the other way is with schema 1.1 assertions or Schematron assertions

    ... apropos of link, you have the opportunity to check the expected value of the mime type against the received value. Because target type is statically determined this does not appear to be a viable solution, however assertions can do this.

    <link href='my.xsl' type='text/xsl' />

    johnarwe: suggests an xml wrapper with type as metadata

    ... if link is pointing to an XML resource, then if we want the mime type checking to work, then we will have to use a wrapper.

    kirk: does wrapper apply only to the links and not the tiff's and jpeg's?

    ginny: you could do this, depends on your application's choices.

    johnarwe: only going to push this far enough to solve each problem individually

<johnarwe> http://www.w3.org/TR/html4/struct/objects.html#h-13.2

    <img src=' '

    longdesc=' '

    ... />

    <img src=' ' />

    kumar: Suggests that preprocessing is a solution. Run the SML processor on something that is HTML like.

    MSM: in cases where we do not know what to do where a multiple links, thinks that bifocal validation works (img) and then so should tri-focal (Object). Bifocal and trifocal covered the cases discussed earlier, where we defined each new hypothetical ref schemes cover only a single URI-valued attribute e.g. one such ref scheme for src= and a separate one for longdesc=. A bifocal validator would recognize only one of these ref schemes on any given validation episode, therefore avoiding the "inconsistent reference" error that would be raised if a single episode recognized both ref schemes. Trifocal just extended this to 3 attributes.

    next up, XLink

<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.

    kumar: in dealing with a previous bug, we already said that we don't want all XLinks to be smlrefs.

    MSM: yes, there will be hyperlinks in the doc that are not sml refs

    on to extended links

    kumar: on extended links, we do not have a construct that corresponds the the extended links

    kumar: extended links do not have to reside in the documents that they link. In SML, both source and dest are in the model.

    MSM: if I am using extended links then the set of documents that are validated include documents where link ends are located and where the existence of links is asserted.

    pratul: it seems that we have a better story for XLink (than XHTML), would it be sufficeint to resolve bug and leave XHTML for future work?

    MSM: thinks that it might be a good idea to publish a note on XLink at some point

    MSM: we have established that for XLink, defining a reference scheme is straight forward. For XHTML it is much harder. Our problems with handling XHTML are similar to those that XLink had with XHTML.

    pratul: can we agree on the bug?

    MSM: would like to look at a the list of issues that we have raised prior to closing the bug. The group found that in working through the XHTML reference scheme, often the solution was crossing the boundary to putting too much on the resolver. Close to agreement.

    pratul: for http://www.w3.org/Bugs/Public/show_bug.cgi?id=5562, would you prefer to write this up or review?

    pratul: everyone can review the minutes, and then we will revisit this tomorrow afternoon.

Summary of Action Items

[End of minutes]