See also: IRC log (member-confidential), agenda, 13 Jun PM minutes, TAG home
<DanC_lap> Scribe: DC
<DanC_lap> ScribeNick: DanC_lap
VQ convenes... reviews agenda, meeting goals... all present, despite distance from large international airports...
scribes... DC Mon AM; ER Mon PM; HT Tue AM; TVR Tue PM; DO Wed AM; NM Wed PM
Review of minutes
<DanC_> minutes 30 May, corrected
<DanC_> minutes 6 Jun
RESOLUTION: to accept 6 Jun minutes, amended to point to 0057 for record of previous week and to show regrets from Ed.
PROPOSED: to meet next 20 Jun... many conflicts (regrets: Noah, Norm, Tim, Dave). Postponed to Weds.
review of agenda... considering moving 4.3.4. Issue URNsAndRegistries-50 and/or 4.3.1. Issue metadataInURI-31 from Weds to Monday.
summer schedule... VQ: we took most of Aug off last summer. Plans?
RESOLUTION: to cancel 4 Jul
11 Jul: 3 regrets
18 Jul: 3 regrets
25 Jul: OK
RESOLUTION: to cancel 1 Aug
8 Aug: Dan C. to chair
15 Aug: chair TBD
22 Aug: chair TBD
29 Aug: OK
confirmed: 4-5 Oct 2006, Vancouver, BC, Canada
DO: not yet urgent to make a hotel booking. Rates looking reasonable.
RESOLUTION: to meet 11-13 Dec in Boston at MIT. 2.5 days. stop early on 13 Dec. TimBL/Amy to host at CSAIL.
<DanC_> DRAFT TAG Finding 24 05 2006
VQ: reviewers were DO, NDW...
DO: haven't written mine down
NDW: looks good to me.
<ht> alternatives-discovery.html (from ACLs DB)
<ht> member access.
DO: looks like a good
... in the intro... 'single web', 'one web', 'facets..' seem unfamiliar.
... define them? use different terms?
<noah> I had exactly the same concern with "facet" in particular.
TVR: I'm inclined to define them
DO: for the use cases, I'd like to see the story form...
HT: the form here seems OK
DO: in "The owners of http://example.com/ubiquity would like to publish their content to a wide variety of end-user devices ranging from desktop Web browsers to mobile devices such as cell-phones and PDAs.", I got disoriented... perhaps discuss other aspects before introducing the URI?
TVR: I hope the 3 use cases to
contribute to one point in the best practices section.
... what have in mind for section 3...
... (1) smart context-based redirects e.g. content negotiation
... (2) discoverable links that bots etc. can find
... so in the example, there are 2 kinds of links: <a>, which is visible to a person, <link> which isn't. To the computer, these give the same structure...
... so you need both (1) and (2) [darn]
HT: I like what you just explained, but subpar 4 of 2.1 needs more detail to complete the story at the same level of detail
TVR: ah, yes.
DO: I would have thought... somewhat like in the state finding... there's stuff used to pick out a representation...
TVR: but that doesn't give
... neither the (1) context mechanism nor (2) links are new... . But doing only (1) the context stuff doesn't make those links discoverable.
DO: whatever information is used, e.g. passed in a message to determine which representation, a URI should be minted that [corresponds?]
TVR: yes, that's a good summary
[though the scribe mangled it a bit]
... ... one part is that whatever representation gets chosen gets its own URI...
... and also that this representation has links to the ones that were not chosen.
... that's the practice that I'm advocating.
DO: this seems similar to the discussion of URI minting for bank accounts etc. in the state finding
<noah> Actually, there's a very similar discussion in the metadataInURI draft
TVR: but in that case, the web of
bank accounts is not something that should be
... this is also similar to Noah's metadataURI draft, with the case of Boston and other cities...
<noah> In fact, the guessing the bank account number example is in section 2.8 of that draft (http://www.w3.org/2001/tag/doc/metaDataInURI-31-20060609.html#hideforsecurity)
TVR: I can see the overlap with the state finding, but I want these techniques to be available without being mixed up with too much other stuff
HT: yes, the discovery aspect should be emphasized
TVR: yes, I'll definitely do that. Discoverability was so much on my mind that I left it implicit.
<Zakim> timbl, you wanted to suggest that term "representation" should not be used for that identified by a URI. It tends to be used for a something-specific resource.
TBL: this draft seems to use
"representation" in a different way than webarch does...
... so rather than "there's a representation-independent URI", say "there are language-independent..." or "device-independent..."
... consider a case of 2 languages and large/small display... you could have one URI for the whole generic thing, one for each row, one for each column, and one for each cell... 9, in all...
TVR: good example, not crazy at all. "don't be shy with minting URIs. if 9 make sense, then mint 9, and make them discoverable by links"
TBL: right... but the rows are not representations... let's call them resources
<noah> How about introducing a few examples, and then saying: "In this finding, we use the term 'style' to refer to the users specific content style preferences, e.g. for a particular language, target device, etc." Then we can say "A style-independent URI". (except I don't like the word style)
TVR: ok, I'll look for where I should change "representation" to "resource"
<timbl> Not representation-independent, but device-independent (or language-indeopendent, etc)
<Zakim> noah, you wanted to briefly express some unhappiness with the word "facet"
NM: I'm also not happy with
... don't have a replacement handy, unfortunately...
... re "Ensure that the One Web enables the easy exchange of resources (and pointers to resources) across its different facets." it suggests "facets" will get a top-level treatment...
... but I think you meant it informally
TVR: yes, I meant it informally
<DanC_> (I don't see why not give it a top-level heading)
NM: hmm... I thought about "context" and "context-independent URI", but all URIs are supposed to be context-independent, so I'm not so happy about that...
<noah> Raman likes the word "context" where I used "style" above. Then we can refer to "context-independent URI".
TVR: suppose... [missed much]... we may have to head down that explanation of context
<noah> Noah says: yeah, I liked context too, except that there's a sense in which >all< URIs are to be context independent, in that all of them refer to the same resource regardless of from where the reference is uttered.
(discussion... on how the sense of "context free" cuts 2 ways...)
DC: consider a case of doc, doc.en, and doc.fr ... doc.en is in some sense more context-free, in that it gives english regardless of language context.
TVR: so... overall?
<noah> Right. I think the context we're talking about is user expectation, in the limited sense that an English-speaking user is less likely to >want< to use a URI for the Japanese language version of a resource. None of us question that, if he actually does retrieve from that URI, he like everyone else will get the Japanese version.
<scribe> ACTION: TVR revise genericResources draft, incorporating resource/representation, complete 2.4.x story better, emphasize discoverability, incorporate DO's comments, attempt best practice draft 3 [recorded in http://www.w3.org/2006/06/12-tagmem-irc]
NM: going to try discoverability best practice?
... for a Tuesday telcon, when do folks want/need it?
DanC: Fri before
Dan: Noah, does the action capture it?
Noah: good enough for now. It could if you like call out adding GPNs, especially for discoverability.
TVR: target Fri before 27 Jun telcon, i.e. 23 Jun
<noah> Ah...best practice...didn't see that.
DO: status... we had some
discussion in Cannes... I did some updates, showing 2
[which?]... worked toward separating the XML layer from
... lots of the text refers to XML, so it turns out to be a big chunk, then URNs/Registries, state preempted this work.
... I hope to get back to versioning as the XML Schema WG is picking up relevant work
... in the context of XML Schema 1.1
... NM, HT, and I are involved in that.
HT: yeah, I'm interested to pick up the ontology work...
<scribe> ACTION: HT to accepted on 22 Sep 2005: Make sure that what he is doing with ontology of XML infoset fits with what DanC is doing on ontology of Language etc. [CONTINUES] [recorded in http://www.w3.org/2006/06/12-tagmem-irc]
HT: at the IRW2006 workshop there were some relevant papers, by DanC and some Italian researchers, and I'd like to integrate those.
DC: apologies for no progress on the SMIL action... maybe we could do one of these... maybe the CSS part... as a group?
DO: I've done some work on the ontology part of the versioning finding, but didn't publish it because of the lagging text on XML
<dorchard> that's because you don't mind saying "make it non-xml again" :-)
<Zakim> noah, you wanted to say I don't mind if you publish
(discussion of which parts to discuss, publish, or review when...)
NM: I'm happy for an update even though only some of it shows the xml/generic split
<scribe> ACTION: DO to accepted on 22 Sep 2005: Update finding with ext/vers [WITHDRAWN] [recorded in http://www.w3.org/2006/06/12-tagmem-irc]
<scribe> ACTION: DO to accepted on 22 Sep 2005: With NM continue and extrapolate the versioning work DO et al have been doing already, updating the terminology section. [CONTINUES] [recorded in http://www.w3.org/2006/06/12-tagmem-irc]
TBL: perhaps there are several
... a generic level about languages in general, where you can't say much, except stuff like "back compatible" which we defined in a diagram in Edinburgh...
... then an XML level... where it's best to talk in XML-specific terms, element/attribute...
DO: there's also versioning XML itself, e.g. XML 1.1
TBL: yes, that's
... then there's more one can say about more specific languages like CSS, or HTML/CDF...
... e.g. "must understand" has more specific meaning w.r.t. CSS cascading rules
<DanC_> (I'd like to talk thru the CSS case in this meeting)
<noah> I wanted to note that, even in XML languages, it's not just the markup for which the rules evolve; the rules for the text content changes too. So, to really have a story even about languages built in XML, we need a story about versioning languages built of character sequences in general. So, there's a recursion. XML is serialized is a sequence of characters, which carries abstractions for markup and element/attr content. The element/attr content is eac
TBL: I think one of the reasons it's so hard to discuss the XML level is that XML is so generic.
ER: yeah, maybe we could define major/minor revision at the top level...
DC: oh? I don't think there's a major/minor version concept that works across languages.
<timbl> I dont think there is a generic model for major and minor versions.
ER: major versions can break compatibility.
DO: there are other definitions, related to amount of work...
ER: isn't it our job to say "those are wrong"?
DC: that's a coherent position, but lots of [social] work...
HT: yes, that goes beyond the constituency we have a reasonable chance to influence
NM: [discussion of the general case...]
<noah> To add a bit of detail on what I said: I think there's a separation of concerns.
DO: sometimes version numbers
refer to the capability of processors/software rather than the
features used in a language
... e.g. the version signal in the HTTP protocol
<noah> Separate (a) does the set of documents accepted by language 1 overlap with that of language2?; (b) Do the same documents or constructs mean the same thing in both languages?; (c) was there a historical connection between the two languages, I.e. was one designed as a delta off the other, is the ancestry linear or do you cross bread from many ancestors, etc.?
HT: to a large community, the
answer to "how many versions of the <p> element are
there?" is 1. But to an audience focussed on namespaces, there
... we have no way of saying XHTML 1.x p is the same as HTML 4's p... [?]
TimBL: however, in RDF, you can.
NM: yes, that shows how the answers to (a) (b) (c) are different at the RDF level...
TimBL: in fact, the questions are different...
<noah> On RDF: you know it all better than I, I'm sure you're right.
<noah> Dan: can we dig into CSS versioning "with teeth"?
<EdRice> DO: let me update the doc, we can do after lunch
<scribe> WITHDRAWN: DO, accepted on 5 Dec 2005: Produce a new draft of his versioning finding by the end of the year in favor of #2
(#2 is perhaps not "With NM")
<scribe> ACTION: DO to accepted on 21 Feb 2006: Provide two diagrams: one XML-ignorant, one XML-aware [DONE] [recorded in http://www.w3.org/2006/06/12-tagmem-irc]
<scribe> ACTION: VQ, accepted on 3 Mar 2006: Write to www-tag about CSS versioning being a problem "levels" [CONTINUES] [recorded in http://www.w3.org/2006/06/12-tagmem-irc]
<scribe> ACTION: DC, accepted on 3 Mar 2006: Look at the document and see if it is good for informing on this SMIL problem of multiple namespaces [CONTINUES] [recorded in http://www.w3.org/2006/06/12-tagmem-irc]
DanC: I hope we get to this later today. I'm struggling to find sufficient energy to make progress on it on my own
break for lunch
back... 1pm? 1:30pm?
back at 1:30pm.
<dorchard> Versioning update at http://lists.w3.org/Archives/Public/www-archive/2006Jun/0012.html
<Norm> Northampton, MA
<EdR> Scribe: ER
<EdR> ScribeNick: EdR
<DanC_lap> looking at http://lists.w3.org/Archives/Public/www-archive/2006Jun/att-0012/vers-v3.html
Partial update to versioning finding
discussion around contextural diagram, while its clear its a bit hard to follow.
Noah: i think we very carefully in Edinburough is more than a set of string; its for a set of strings and their interpretation.
DO: so you dont want vocaulary?
Henry: This diagram works well to discuss what Noah is pointing out.
Dan: you can define all these relationships without using vocabularies at all.
Noah: I agree.
Dan: Until we have a better word for membership we wont be comfortable.
Timbl: String sets.
... We miss out the symantics if we leave it out, but later on you talk about it so I think its important to make it clear.
Noah: tell me about Production. I assume its production in the terms of Grammer and DNS.
Henry: no, its in respect to a language with respect to some information.
Noah: The information appears to only come up in response to impact. The text of the digits 1,2,3 have the value of one hundred twenty three.
Dan: No, you could write it in decimal, I could read it in Octal and come up with a very differant message.
Noah: I want a diagram that I can read before anyone writes a language.
DO: so when I said we elete this notion its because we didnt draw a line between information and semantics.
Noah: Why not between text and semantics?
(diagram: These terms and their relationships are shown below;)
Henry: There isnt more detail here because this is a very generic diagram. Its so abstract so I dont know how to be more complete than this.
Dan: The whole point is that
there can be one text produced in one language and read in
... Henry, I think one of 'semantics' and one of 'text' equals 'information'.
Henry: We have a label for a set
of all strings 'membership'.. we dont have a label for a set of
all information and we need that.
... In order to say 3 > 2 you need to have the sum of the logic.
Timbl: Your saying information is a context of a message.
Henry: its a sentance but it also has an interpretation.
Noah: I think models should fit in.. If I send Tim a message with 3 in it, he should agree its greater than 2 so we can have a discussion about it.
Henry: The sentance is; 3>2
and 1<5. The information content should be in that box we're
referring to and its not in the model.
... Thats a derrived consiquence of the model, but its not spelled out in the model.
Noah: Looking at the left side, information only shows up in the story in which a particular instance is conveyed and consumed.
DO: you want to be able to tell a story about production but you dont want to use text?
Henry: Let me propose; Leaving Production/information/consumption to one side. If you've got a language, two of the things you have is its string set and its interpretation set.
Timbl: when you say 'stuff' you really mean the semantics.
Henry: What you really find is that syntax has semantics in it.
Noah: You really need to quantify all possible versions of production.
Dan: hold on, there are stories about a particular version.
Noah; yes, but I dont want to tell them both in the same box.
Noah: I think where we're going is a good handle. I think we're going to talk about this language definition, then we're going to talk about another.. then we'll talk about a production.
DO: I'm trying to capture what Henry was talking about.
Henry: I proposed a change. Dan
proposed a second change.
... Dan's change is a 2nd change.
... we should take them one at a time.
Dan: I'm happy with both boxes or neither box.
<Zakim> ht, you wanted to say we need vocabulary==alphabet, or we can't define what a string is
Henry: Dan you said you didnt make any use of vocabulary and term. How did you define what the strings are then?
Dan: It never comes up.
discussion of diagram continues..
Timbl: Proposed we will remove Term and Vocabulary from the diagram.
<DanC_lap> i don't think that was a TAG decision; I abstain if it was.
Henry: yes, but we'll need to add term and vocabulary back in at a later time.
<DanC_lap> (Ed, I think all of this is advice to dave, the editor of the finding. The TAG has, to date, not made any decisions re versioning.)
<Zakim> Norm, you wanted to say s/production/produces/ and s/consumption/consumes/ and to also ask about the lines between semantics, interp, interp set, and information
discussion of diagram continues.
<DanC_lap> (every change to a word in this diagram is a substantive change.)
<Zakim> DanC_lap, you wanted to suggest s/Membership/String Set/ or /Text Set/
<Zakim> ht, you wanted to ask about how syntax and semantics are related and to argue we need the semantics->interpretation set
<DanC_lap> (ternary relation? more specifically, it's a function from 2 classes to 1, right, timbl?)
<DanC_lap> HT: interpretation set is the set of things you can mean by a message in a language
<DanC_lap> (brainstorming on that... Meanings?)
Active discussion continues..
break until 12:30
<Zakim> DO, you wanted to ask about constraint
<tvraman> we're still way lost in the weeds.
<tvraman> the interesting challenges on the web today are to ask the versioning questions,
<Zakim> ht, you wanted to add the philos. of language use of the words 'meaning' and 'interpretation' to the mix
DO: to update diagrams, definitions, xml version of the diagram. There was a suggestion that we show this diagram as an instance (fred and barny) story.
<noah> Noah suggests that Fred and Barney in particular will likely raise copyright issues. Though it would be fun, we should probably choose other names. Sigh.
DO: discusses Fred/Barney diagram
Vincent: Estimated time to update?
DO: no idea right now..
... we'll hold off on publishing the new diagram until the document is updated. We can fire off a png as a result of what we've talked about and then I'll integrate it in later.
<DanC_lap> DO's action to update finding continues.
Attempting to Time box to 20 minutes.
Dan: The W3C has a report that shows which documents are out of compliance from most popular down.
TV: we're overloading content
... By saying something is class=geography, you can now product two differant documents with the same html but two differant style sheets. One that knows nothing about geography, one that knows about geography but hides it and a third which knows about geography and does something special with it.
Noah: I think we have two
interesting things to talk about.
... Lets give them memorable and differant names.
Dan: css language
... TV's issue is stylesheet versioning.
Noah: if the css language was versioned in the wrong way, it could also cause a problem. Like if CSS said RED is now not rendered than that would cause another problem.
Dan: Pole; CSS3 <> bear distinct version info at 'the top' from css2 documents.
1-should, 4-must, 1-should not, 2 must not
DO: I made when I cast my note, I made the assumption that a css document would fail. If they're fully forward compatible then I would change my vote to 'must not'.
Dan: most the time there are good CSS rules, that why I said Should not.
TV: Right, that why I said 'most not' because today there are many versions of a p-element for no good reasons.
<dorchard> There's something close in the ext/vers document that says no version identifier and no new namespace, strategy #3 in http://lists.w3.org/Archives/Public/www-archive/2006Jun/att-0012/vers-v3.html#ident
Noah: I went went pretty close to
must not with possible may, I think version attributes are to
be used when absolutly needed. Its one more thing to worry
about, its one more thing to have mistaken assumptions about.
However, I do think there are times when its a nessisary evil.
This is breaking for a predictable reasons, so this document
your sending me may not be interpreted correctly.
... I like systems in which a language does not build in assumptions about who changes it.
Tim: So, the way to work this out
is.. you have to ask a question, the cost/benefit of all
... a person writes a)css2 b)css3 and another reads 1) css3 and 2)css3 and they (a) do (b) use them from the other languages. The cost is $___, the liklihood is ____ (frustrated persons per million per year). Then you do a cost benefit analysis you'll see if its worth while.
Henry: More information is
better. If i'm authoring a particular version of a spec, its
useful for me and I'm one of the ones who will come back and
read it, and see what I was doing at the time. I'm not making
any assumptions as to what would or would not fail as a basis
of that version.
... I also believe in validators. The css validator has limited utility because it doesnt have any way for the document to tell it what I meant.
<Norm> "Must not" baffles me. Forwards compatibility is a good thing, but to prevent me from knowing if the reason I don't understand your stuff is painful. I want to know if there's a subtle syntax error or if you're writing in V.next and I should expect not to understand.
<noah> OK, makes sense. I think that's why I can live with a "may". I remain reluctant about centralizing the assignment of version ids, which is not to say I'm always against it, just pointing out that there's a downside.
Norm: Preventing me from knowing the reasons I validate the stuff is painful. I want to be able to tell if there is some subtle thing has changed. Must is not the wrong answer.
<noah> Maybe I'm being convinced that "may" is the right answer.
Dan: I think the validator case is the wrong answer so 'should not' is the right answer. because I dont want my great grandchildren to have to keep using css3 because thats all that they've ever used.
Norm: Motion to extend.
<not passed but we're doing it anyway :))
Norm: But we need to know what interpretation you have to have.
Timbl: so if I write ssl2 style sheet but its read by an ssl1 style sheet would it be tossed out?
Norm: No, the SSL1 style sheet was created for a reason.
Timbl: I agree both that validators are useful in determining the syntax. So I think the HTML language needs to be defined by the semantics of that very large string.
Henry: thats consistant with the xsl story.
DO: So, what your saying is something that we dont have a good explaination for yet. The CSS language may be 'this big' but the terms is a smaller sub-set.
<noah> I think Tim said something slightly different. I think he said "Languages like CSS and HTML accept a very broad range of strings with interspersed content that they effectively ignore. We as the TAG should clearly make the point that in the formalism we're evolving, the 'languages' include that very broad range of strings."
<dorchard> I believe that the string set gets smaller as versions increase AND the vocabulary gets larger.
<dorchard> What happens is terms are added and they replace extensibility points.
<dorchard> Where this goes, is that a language consists of BOTH the allowable strings AND the terms. First gets smaller, second gets bigger
TV: After banging my head against the validator so many times, I dont have much sympathy for it.
Dan: Yes, but it sets the standard.
TV: I'd dispute that 10,000 hits a day sets the standard.
Dan: Well, I'd agree that we should fix the validator.
Henry: I like the way dave
responded to what Tim said, but I have a differant take.
... in the story/terms that we were using, the semantics dont care which string sets your in they care about which equivelance set we're in. They are about the cononicle one.
Dan: <p> <p x='1'> <p x='2'>
Noah: I think validation is great. I just think that sometimes validation is ok, but its also ok if I look at it and say its 'xxx'.
Vincent will continue his action, and try and write something in July.
Vincent: lets move on.
Henry: I did my changes on top of DO so he should go first.
DO: I went through and did a
compare of the oasis URN rules and compared against the
reliable messaging team which uses a HTTP URI
... comparative identifiers, when does a user get a 404, how does it happen etc.
... then took a look at the persistant document setting and took the XRI example of a .pdf document
<see document for story>
DO: I updated section 4,5,6 of xri.
Henry: I took Dave's work and
tried to respond to the points that were made to sections
... I used myrI for my descripter since it doesnt collide with anything out there.
... I looked at the info-scheme and it provided some useful discussion so I added a few things because of that.
... I decided I couldnt write section 2.8 and then lightly edited sections 4,5,6 for consistant terminology for consistancy with 1,2,3
Vincent: ok, lets hear from the reviewers.. Dan?
Dan: some editorial stuff, only one technical disagreement.
Noah: I think there are given a URI a set of things you can do with it. A set of information you can do without having to retrieve it and more you can get when you do retrieve it. But in principle they're web resources.
Dan: I can sense the tension of
writing for two differant audiences. The ones who just want the
answers right away and will work from there. The others are the
ones who need to be convinced and for those the answer at the
top is a bit of a turn-off.
... I'm sending the full feedback now so it will be in the in-box shortly.
Vincent: The other reviewer is Ed. He sent a message yesterday.
<noah> Ed's review is at: http://lists.w3.org/Archives/Public/www-tag/2006Jun/0039.html
Ed: discusses the hp job design hp.com/go/jaserjet resolving to the much longer product URL as a reasonable example where two URI's poing to the same resource. The discussion agreed that this is a reasonable method and result.
Tim: The BBC also has a page about Tim (above).
<Zakim> noah, you wanted to say I'm not convinced we're really addressing the concerns of communities like XRI
Noah: I had a few comments; I read the XRI document in some detail.
Noah: I actually am not that
happy in using a tag finding in responding to some alternative
... A tag findng should layout good practice and have any response to their technology seperate.
... I think if we did want to reply, I think we're reading past them a little bit.
... But if you look at what they have in XRI, you can see a lot about who contributed to what authority.
Vincent: we're running out of
... I'll keep the que for tomorrow. (Tim, Henry, then Dave).
... The meeting is scheduled for 9:00 tomorrow.