IRC log of tagmem on 2008-09-24

Timestamps are in UTC.

01:45:51 [noah]
noah has joined #tagmem
13:58:22 [RRSAgent]
RRSAgent has joined #tagmem
13:58:22 [RRSAgent]
logging to
13:58:23 [jar]
jar has joined #tagmem
13:58:45 [ht]
Meeting: TAG f2f, Wednesday morning 2008-09-24
13:58:51 [Stuart]
Stuart has joined #tagmem
13:59:12 [timbl]
timbl has joined #tagmem
13:59:51 [Norm]
Norm has joined #tagmem
14:00:12 [ht]
14:00:21 [ht]
Chair: Stuart Williams
14:00:28 [ht]
Scribe: Henry S. Thompson
14:00:33 [ht]
ScribeNick: ht
14:01:23 [DanC_lap]
DanC_lap has joined #tagmem
14:01:32 [ht]
Topic: 3.5 Self Describing Web
14:01:40 [ht]
14:02:07 [ht]
SW: Noah has produced a draft:
14:02:24 [DaveO]
DaveO has joined #tagmem
14:02:29 [ht]
NM: There are some specific things the group might want to concentrate on
14:03:08 [DanC_lap]
hmm... passive voice... "Web resource representations should be published using widely deployed standards and formats. "
14:03:22 [ht]
NM: We reviewed this in Bristol, we were close to agreement to publish, NW and SW appointed as reviewers after I produced another draft
14:03:27 [timbl]
""Error loading stylesheet: An XSLT stylesheet does not have an XML mimetype:"""
14:03:31 [noah]
14:04:30 [ht]
NM: There's an ednote there -- we have a choice here wrt RDF-XML, N3 or both for this example
14:04:52 [ht]
SW: SWBP uses N3 for their tutorials
14:05:11 [Norm]
noah, I suggest that you define a prefix for .../Employees# so that the example begins e:BobSmith rather than the full URI in angle brackets
14:05:35 [ht]
AM: Why not both?
14:05:40 [ht]
NM: longer
14:05:47 [ht]
DC: I think not
14:06:32 [DanC_lap]
hmm... hard to see this as a good-practice: "Representations provided directly in RDF, or those for which automated means can be used to discover corresponding RDF, contribute to the self-describing Semantic Web. "
14:07:11 [ht]
JR: N3 is easier to read
14:07:23 [ht]
... but is their a media-type registered for N3?
14:07:33 [ht]
TBL: It's in progress
14:07:52 [ht]
SW: Not a great example, then
14:08:00 [ht]
HT: That's a definitive 'no' for me
14:08:09 [DanC_lap]
hmm... s/information/data/? "RDFa should be used to make information conveyed in HTML self-describing. "
14:08:23 [ht]
DC: So that would be an unhelpful distraction at this time
14:08:35 [ht]
JR: Reluctantly, agreed
14:08:59 [DanC_lap]
missing quote: ">
14:09:24 [ht]
RESOLUTION: Request the editor to use the XML version only at the beginning of chapter 5
14:09:56 [ht]
NM: Next issue arose first at the Bristol f2f, to do with RDFa
14:10:01 [ht]
... in section 5.1
14:10:02 [Norm]
14:10:51 [noah]
From Norm's paraphrase of the Bristol minutes:
14:10:51 [ht]
NM: What is the RDFa 'follow-your-nose' story? I tried to implement the recommendation we arrived at in Bristol, but ran into trouble
14:10:56 [noah]
| - The paragraph starting "Even though this document is of media type
14:10:56 [noah]
| application/xhtml+xml " needs to be replaced with following your nose
14:10:56 [noah]
| through: application/xhtml+xml -> RFC 3236 -> HTML M12N ->
14:10:56 [noah]
| -> RDFa specification
14:11:47 [ht]
[That quote my understanding of the Bristol minutes, ratified by the scribe at the time, NW]
14:12:03 [ht]
s/[/NM: /
14:12:08 [ht]
14:13:44 [ht]
NM: But the problem is that that chain is not well-supported by the documents involved
14:14:17 [ht]
... email exchanges suggested that XHTML modularization isn't involved
14:14:56 [ht]
... and I haven't gotten a story from those exchanges which gave a full answer
14:15:46 [ht]
HT: Why can't you go straight to the namespace document, from application/____+xml
14:16:39 [ht]
NM: You may have uncovered another problem, because I don't see how 3023 licenses looking at namespace docs
14:16:54 [ht]
HT: Then you have a problem higher up in this document, don't you, in section 4.2.3?
14:17:28 [ht]
NM: Let's see -- the beginning of that is true, but not justified by 3023
14:18:51 [ht]
... Ah, actually, it does have a reference to namespace documents
14:19:25 [ht]
... So maybe I could/should back off from the XHTML modularization route, but I could go via 3023
14:20:05 [timbl]
q+ to ask why has no link under text/html
14:20:08 [ht]
JR: Does 3236 point to 3023?
14:20:13 [timbl]
14:20:14 [ht]
NM: Checking -- yes.
14:20:41 [DaveO]
q+ to say how about adding some of the proof statements, ala versioning..
14:20:42 [ht]
TBL: If we think it's necessary, we can always request changes that we need
14:21:18 [DanC_lap]
ack danc
14:21:18 [Zakim]
DanC_lap, you wanted to respond to concerns about various bits of prose with some notes about test cases
14:21:36 [timbl]
14:23:00 [ht]
TBL: I thought there was an issue here, but I guess it's OK
14:23:44 [ht]
DC: IANA are going to supply APIs to access this information: text, HTML and XML
14:23:51 [DanC_lap]
(resolution? I think the editor is collecting advice. hmm.)
14:24:23 [ht]
NM: So we're I'm going depends on the XHTML namespace document be updated, to document the use of RDFa within XHTML
14:24:38 [ht]
TBL: I thought I suggested the _schema_ should be updated
14:25:37 [ht]
DC: Namespace document not updated yet, either way
14:26:05 [DanC_lap]
(hunting for a pointer to these plans...)
14:26:11 [DanC_lap]
14:26:20 [timbl]
ack timbl
14:26:20 [Zakim]
timbl, you wanted to ask why has no link under text/html
14:26:26 [ht]
NM: I plan to update the RDFa section to refer to a planned update to the namespace doc for XHTML saying that RDFa in XHTML is to be interpreted
14:26:46 [ht]
... Does that work?
14:27:13 [ht]
TBL: In theory, yes. In practice, I would like to see the change to the NS doc. right away
14:27:22 [ht]
DC: Should have been a CR exit criterion, but too late
14:27:50 [ht]
NM: I would like to get this out now, not have it hostage to that change -- the impact on _this document_ is not great enough to justify delay
14:27:55 [DanC_lap]
I 2nd the (implicit?) proposal to approve this finding contingent on RDFa-related edits to the satisfaction of Noah and 2 other TAG members.
14:28:13 [ht]
TBL: It's a bug that this hasn't been addressed
14:28:39 [ht]
DC: An important point of this finding is to impact the RDFa spec.
14:28:57 [ht]
... It's part of the TAG's job to make that happen
14:29:10 [ht]
NM: They've said they will do it, I can explain to them why it matters
14:29:34 [ht]
NM: Can we agree to the above proposal, wrt this finding?
14:30:10 [ht]
TBL: We _also_ need an action to make sure the XHTML namespace change gets done
14:30:28 [DanC_lap]
14:30:28 [trackbot]
ACTION-130 -- Tim Berners-Lee to consult with Dan and Ralph about the gap between the XHTML namespace and the GRDDL transformation for RDFa -- due 2008-04-10 -- CLOSED
14:30:28 [trackbot]
14:30:36 [DanC_lap]
perhaps that's no longer done to timbl's satisfaction
14:31:19 [DanC_lap]
14:31:19 [trackbot]
ACTION-130 -- Tim Berners-Lee to consult with Dan and Ralph about the gap between the XHTML namespace and the GRDDL transformation for RDFa -- due 2008-04-10 -- OPEN
14:31:19 [trackbot]
14:31:32 [timbl]
Well, I consulted ... but I didn't get an action token back
14:31:35 [timbl]
from Ralph
14:31:43 [DanC_lap]
I thought you did, but I can't confirm
14:34:05 [ht]
Proposed resolution: To instruct the editor to move to a path via 3023 and a planned update to the namespace doc for XHTML saying that RDFa in XHTML is to be interpreted to fix the RDFa section
14:34:24 [ht]
TVR: That leaves actions dangling on other documents
14:34:57 [ht]
NM: There is another action now, on TBL, to make the necessary changes
14:35:21 [ht]
DC: I like TVR's story
14:35:24 [ht]
NM: Which is?
14:35:37 [ht]
DC: A pointer to the plan
14:35:48 [ht]
NM: Happy to include it
14:36:16 [DanC_lap]
+1 " to move to a path via 3023 ..."
14:37:53 [ht]
RESOLUTION: To instruct the editor to fix the RDFa section by moving to a path via 3023 and a planned update to the namespace doc for XHTML saying that RDFa in XHTML is to be interpreted, including a pointer to the plan
14:38:41 [ht]
NM: One more issue -- the Good Practice note about using RDFa
14:39:13 [ht]
... Is this too specific too early? Should I kill it?
14:39:40 [ht]
HT: I would prefer to kill it, as I would use GRDDL if I wanted to move my H
14:39:59 [ht]
s/my H/my HTML towards RDFa/
14:40:09 [ht]
TBL: It's ambiguous as written
14:40:50 [ht]
SW: RDFa allows you to put RDF in your document, but it's not necessarily descriptive of that document.
14:41:00 [DanC_lap]
DanC: RDFa is only specified for XHTML, so "in HTML" has a lot of subtlety that I'd rather we didn't into
14:41:12 [ht]
NM: This doesn't disagree, it just says you should do this one
14:42:20 [ht]
JR: I think you're using 'self-describing' in two different ways: one at e.g. the level of mime-types (which isn't so much descriptive as proscriptive), and the other the usage here
14:42:42 [ht]
... The first is about how to _interpret_ this document at all, the other is quite different
14:43:16 [ht]
TBL: Something with metadata at the top is 'self-describing' -- the thing here is more like 'grounded in the web'
14:43:54 [ht]
... I think JR is on to something important -- I'm not happy with e.g. the 3rd sentence in the abstract
14:44:16 [ht]
... We would be better off using 'grounded in the web'
14:44:29 [ht]
NM: This is a bit late in the process to make such a sweeping change
14:45:38 [ht]
TVR: Connecting back to yesterday, I'm uneasy about the reliance on a mixture of English and fully mechanically exploitable information
14:46:27 [timbl]
14:46:38 [ht]
JR: I think I know how to fix this
14:47:11 [ht]
... Leave most of the wording in the document alone, by making clear what you mean by 'self-describing'
14:47:29 [ht]
NM: So can we put this to one side while we work on the rest of the document
14:50:05 [timbl]
14:50:24 [ht]
q+ to make some points
14:50:44 [ht]
ack DaveO
14:50:44 [Zakim]
DaveO, you wanted to say how about adding some of the proof statements, ala versioning..
14:51:17 [ht]
DO: I share your pain wrt comments late in the day, but it's something we all have to live with that
14:51:57 [ht]
... I think the requested changes are worth it
14:53:06 [ht]
DO: Maybe you should at least once go through the specs the way we did it here today to establish in detail how the prose in the relevant specs connects everything together
14:53:13 [ht]
NM: In which examples?
14:53:24 [ht]
DO: Microformats maybe, XML itself
14:53:32 [ht]
NM: I thought I had the references
14:53:44 [ht]
DO: My suggestion is to look at actually pulling in the quotes
14:53:52 [ht]
NM: Useful idea, I'll have a look at doing that
14:53:56 [ht]
ack DanC
14:55:00 [ht]
DC: I'm concerned we're ignoring HTML5 at our peril -- the extensibility via URIs story just doesn't play with them
14:55:17 [ht]
... and they don't care about RDF either . . .
14:55:21 [ht]
NM: Change required?
14:55:24 [ht]
DC: Not sure
14:55:57 [ht]
DC: Several of the Good Practice notes are passive voice -- in AWWW we tried hard to identify _who_ is supposed to do things
14:56:07 [ht]
... I can live with these as they are
14:56:17 [ht]
NM: Should we fix this now?
14:56:20 [timbl]
14:56:25 [ht]
14:56:38 [ht]
SW: I didn't comment on that, no
14:56:56 [Norm]
I can live with the passive voice. I have a hard time weeding it out of my own writing
14:56:57 [ht]
JR: I did have a problem with the tone of the little boxes
14:57:48 [ht]
DC: The "Representations provided directly in RDF" doesn't describe a Good Practice at all. . .
14:57:56 [timbl]
14:59:26 [ht]
HT: We could reframe it as "In order to contribute to the self-describing Semantic Web, provide representations directly in RDF, or those for which autoamted means can be used to discover corresponding RDF."
14:59:38 [ht]
SW: Where did the middle clause come from?
14:59:47 [Norm]
With regrets, I have to step away for 60 minutes or so. Back ASAP
15:00:03 [DanC_lap]
q+ to note a comment from hsivonen that GRDDL goes against the principle of least power; I see LeastPower in the references section but no [LeastPower] in the body.
15:00:12 [ht]
NM: The preceding discussion of the tradeoffs between direct and e.g. GRDDL-mediated provision
15:00:49 [ht]
TBL: Is the distinction between what I think of as 'web-grounded' core of things, and the more extended notion of metadata in general?
15:05:03 [DaveO]
15:05:04 [Stuart]
15:05:59 [ht]
s/in general/in general there in the document/
15:06:46 [ht]
NM: 'web-grounded' is too geeky. . .
15:07:03 [DanC_lap]
ah. I think I see tim's point now... self-describing is a property of the Web as a whole, not as a document.
15:07:08 [ht]
TBL: JR is right that there is an important distinction here that you are blurring
15:07:25 [ht]
NM: I think I got this all in the document
15:08:06 [ht]
TBL: The crucial point is the the (short) list of things I have to know in advance
15:08:12 [ht]
q- tbl
15:08:17 [ht]
q- timbl
15:08:40 [ht]
TBL: What is the basic core, for someone who understands English?
15:09:12 [ht]
NM: see the end of section 2
15:10:16 [ht]
TBL: That looks like a different argument -- point is not using widely deployed, but what the bare minimum is that a newcomer needs beside the pure idea of follow-your-nose
15:11:00 [ht]
... It's not like there are any engineers who are confused about this, but to bullet-proof ourselves against someone saying "Oh no, I didn't mean this as a jpeg"
15:11:06 [Stuart]
15:11:11 [ht]
NM: So what change to the document do we need?
15:11:35 [ht]
TBL: Particularly, not applying 'self-describing' to documents, just to the Web as a whole
15:11:50 [ht]
NM: Are you optimistic that what JR proposes will fix the problem you have?
15:12:06 [ht]
TBL: The list of core documents isn't in that, is it
15:12:39 [ht]
... I want something like "If you have a message, the core specs [what are they], and a knowledge of English, you have all you need to interpret the message
15:12:45 [ht]
15:13:57 [ht]
DC: 's-d' applies well to the Web, but doesn't apply well to documents, is what TBL has been saying
15:14:00 [ht]
NM: And you?
15:14:34 [ht]
DC: I have been used to that usage, but I realise calling a message self-describing is wrong, because it doesn't describe itself
15:14:41 [ht]
NM: I explained it's a term of art
15:14:48 [ht]
DC: Yes, but it contradicts itself
15:15:10 [ht]
JR: I suggested a compromise, in order to get this published, but a bigger fix could be done
15:15:21 [noah]
15:15:25 [ht]
NM: I'd rather get it right if it makes a big difference
15:15:33 [Stuart]
ack ht
15:15:33 [Zakim]
ht, you wanted to make some points
15:15:44 [DanC_lap]
(surveying usage of "self-describing document" in a larger community)
15:16:22 [timbl]
The Web is designed to support flexible exploration of information by human users and by automated agents. For such exploration to be productive, information published by many different sources and for a variety of purposes must be comprehensible to a wide range of Web client software. HTTP and other Web technologies can be used to deploy resources that are grounded in the web, in the sense that the apropriate interpretation of a document follows by following a
15:16:31 [raman]
raman has joined #tagmem
15:17:09 [jar]
noah: Self-describingness is always a matter of degree
15:17:23 [jar]
ht: Self-describing may be a bad choice for a term of art
15:17:32 [DanC_lap]
(ew... scary... top hit for "self-describing document", after, is some patent stuff.)
15:18:15 [jar]
ht: Documents are self-contained if they don't require more than the core to ...
15:18:34 [Stuart]
15:18:43 [DanC_lap]
(what fix did noah just refer to?)
15:18:55 [timbl]
"HTTP and other Web technologies can be used to deploy resources that are grounded in the web, in the sense that the apropriate interpretation of a document follows by following a series of references in the web. Starting with a URI, there is a standard algorithm that a user agent can apply to retrieve and interpret a representation of such resources." <-- sugegsted text for bstract
15:19:02 [jar]
ht: An HTML document with RDFa is self-describing in the ordinary sense of the word
15:19:07 [noah]
15:19:47 [ht]
TBL: You could try to use 'self-describing' in your way to a web-arch-sophisticate
15:20:24 [ht]
NM: When you have an image/jpeg message and some bits, HST said that wasn't self-describing in the ordinary sense
15:20:30 [DanC_lap]
(I find this abuse of "self-describing document" is reasonably wide-spread. I think it's OK in this document.)
15:20:38 [DanC_lap]
ack danc
15:20:40 [Zakim]
DanC_lap, you wanted to note a comment from hsivonen that GRDDL goes against the principle of least power; I see LeastPower in the references section but no [LeastPower] in the
15:20:43 [Zakim]
... body.
15:20:57 [ht]
NM: But to me that feels like a matter of degree
15:21:13 [ht]
TBL: But an image can't be self-describing
15:21:37 [ht]
DC: Why is Least Power in the references section, but not in the body?
15:21:49 [timbl]
15:21:52 [ht]
NM: I think it was, but just hasn't been pruned
15:22:17 [timbl]
That is a document with a fix to the abstract and the phrase 'web-grounded" used
15:22:30 [ht]
DC: Henri Sivonen points out that GRDDL means you have to run a programme to interpret your document
15:23:07 [ht]
... So you should either delete the reference, or add some explanation
15:23:12 [jar]
An image can live inside a wrapper that holds metadata for the image. Customarily we don't make a distinction between the image and the container (.png file, etc) that carries it. ... so no the image isn't self-describing, the container isn't self-describing, but the container carries a description of the image ...
15:23:37 [ht]
TBL: I have done an alternative draft with 'web-grounded':
15:24:45 [DanC_lap]
(self-similar means it's elements-all-the-way-down...)
15:24:59 [ht]
DO: DC once said to me "XML isn't self-describing, it's self-similar" -- the core problem is that you need a definition of self-describing that works across the whole document
15:25:12 [timbl]
15:25:16 [ht]
... as in the way we drilled on the terms in the versioning findings
15:25:23 [ht]
q- DaveO
15:25:43 [ht]
DO: And that may mean some counterexamples
15:26:08 [ht]
NM: My problem is I don't yet hear clearly what the TAG is trying to get me to say
15:26:53 [ht]
DO: I'm happy for you to use 'self-describing' for documents, and for the Web, but with more clarity about what this means
15:27:07 [ht]
... This is our role as educating people
15:28:52 [DanC_lap]
(hmm... I missed that about "self-describing web")
15:28:59 [ht]
TBL: My preferred formulation is "resources that are _grounded in the web_, in the sense that the appropriate interpretation of a document follows by follwoing a series of referernces in the web."
15:29:29 [ht]
NM: But that means that my own private format is grounded in the web.
15:30:17 [ht]
TBL: It is, but the "use widely deployed standards" is a separate point, already made in AWWW
15:31:09 [ht]
NM: So I'm willing to explore a way to make this work, but it's going to take some work
15:31:21 [ht]
DC: I think we could finish this this week
15:31:29 [ht]
NM: I want more time
15:32:07 [ht]
DO: I don't like the proposed change, I think 'self-describing' is important not to lose. And I think the 'widely-deployed' does belong here
15:32:57 [DanC_lap]
(I think a pure definition of "self-describing" can be combined with a good-practice note about popular formats. I think that's pretty close to where the finding is now.)
15:33:18 [ht]
TBL: I disagree -- I'm interested in the pure question of whether it all connects up, and that's why I didn't want RDFa to go ahead until they had fixed their part in this
15:33:44 [ht]
HST: Yes, I think the point that anybody who fits into the chain has to acknowledge that and take responsibility for it
15:35:44 [ht]
NM: The follow-your-nose story really doesn't work unless what you hit as you go are widely deployed -- that's the main message, for me
15:36:00 [ht]
SW: Break time
15:36:34 [ht]
SW: I encourage TBL and NM to keep talking, and we can come back to this if we need a few minutes for a resolution
15:37:11 [ht]
NM: I'm concerned that we get DO and e.g. HST on the same page
16:05:47 [ht]
16:06:20 [ht]
Topic: 3.6 passwordsInTheClear-52 (ISSUE-52)
16:09:02 [ht]
s/3.6 passwordsInTheClear-52 (ISSUE-52)/3.4.4 HTTP And HTML/
16:09:15 [DanC_lap]
(hmm... something from the self-describing-web discussion in the break should be recorded as an action, probably. maybe later today...)
16:09:36 [ht]
TVR: Based on yesterday's discussion, this issue follows on from our 3rd discussion yesterday
16:10:07 [ht]
... There are ways in which what's happening in HTML5 interacts with other standards work
16:10:42 [DanC_lap]
(for reference... HTTPbis WG )
16:10:44 [ht]
... but rather than digging in to the specific technical issues, we should look at how to address the overlap/conflict problem
16:11:45 [ht]
TVR: I think the http-bis IETF group are doing good work, with a good broad and well-informed membership, although they are short on representatives from the browser vendors
16:12:33 [ht]
... I don't think we have much to offer beyond what that group, and the What-WG group, have in the way of technical expertise
16:13:27 [Stuart]
16:13:52 [ht]
DC: News to me that no browser participation in the http-bis work
16:14:08 [ht]
TVR: Not sure, although pretty sure that WHAT-WG are not in there
16:14:49 [ht]
DC: I got educated by the half-serious suggestion for an HTTP5, that there is tag soup in the HTTP header which the browsers fix up
16:15:16 [ht]
TVR: Thinking back to the error recovery topic, there are two aspects:
16:15:46 [ht]
... 1) There are always corner-cases where a spec. isn't completely clear, and different implementations go in different ways;
16:16:24 [ht]
... 2) The case where things are clearly wrong, but accepted anyway, and then the bad drives out the good
16:16:32 [DanC_lap]
Zakim, this is tag
16:16:32 [Zakim]
ok, DanC_lap; that matches TAG_f2f()10:00AM
16:16:38 [DanC_lap]
Zakim, who's on the phone?
16:16:38 [Zakim]
On the phone I see ??P0, Norm
16:16:43 [DanC_lap]
Zakim, ??P0 is KC
16:16:43 [Zakim]
+KC; got it
16:17:01 [ht]
... Once we turn to the HTTP spec, the situation is better, because when there is uncertainty, people just do what Apache does
16:17:39 [ht]
TVR: The hard case is at the intersection between HTTP and HTML, namely content-type sniffing
16:19:19 [ht]
HST: What should we do about Content Type Sniffing?
16:19:35 [ht]
DC: We have reopened the issue
16:19:58 [ht]
... Do people know what the browser vendors say when you tell them "get with the program"?
16:20:15 [ht]
NM: There's lots of deployed stuff
16:20:52 [ht]
DC: They will lose market share -- people will look at text/plain rendering of what's obvious (to them) HTML and say "your product is broken, get me one that works"
16:21:35 [ht]
TVR: There is a lot of broken stuff out there, and that has to be acknowledged, but the market share argument is spurious
16:21:56 [ht]
[scribe didn't understand why]
16:22:46 [ht]
TBL: Sniffing today is mostly on text/plain, which is taken as sort of a wildcard
16:23:39 [ht]
... Roy Fielding suggested we would be better if servers just left off the Content Type header if they didn't know the type, rather than sending text/plain
16:23:48 [ht]
... On this front, HTML5 is not unreasonable
16:24:09 [ht]
TVR: But browsers sniff on more than text/plain
16:25:31 [ht]
... Sam Ruby knows the details
16:26:03 [ht]
HST: I thought there was sniffing of text/html, the whole standards-mode vs. whatever stuff
16:26:11 [ht]
TBL: I didn't think so
16:26:51 [ht]
TBL: There's a bit in the HTML5 spec about maybe waiting 500bytes before deciding what to do
16:28:21 [ht]
DC: There is some negotiation for change: There's the whole "authorative: true" proposal, and Ian Hickson is in dispute with the browser vendors about how much sniffing will go into HTML5
16:29:02 [ht]
... One option is taking the state of the art wrt content type sniffing and freeze it -- not good, but better than the alternative?
16:29:10 [ht]
16:29:46 [ht]
TVR: The question for this meeting is: does the W3C want to play a role in getting out of this local minimum?
16:29:54 [ht]
DC: If we want to, then what?
16:30:33 [ht]
TVR: There's the conflict between servers trying to do the right thing and browsers trying to do the right thing
16:30:46 [ht]
... plus the lag in updating either one, and the long tail of legacy
16:31:12 [ht]
... What the TAG can do I don't know -- it's a function of what W3C wants to do.
16:34:00 [ht]
HST: Should we ask Apache to ship a "don't know, don't tell" policy wrt Content Type out of the box?
16:34:08 [ht]
DC: I think they already do
16:34:57 [ht]
TVR: Yes, Content Type is optional, but everybody _thinks_ Content Type is required because scripts always start "print 'text/html'"
16:36:12 [ht]
DC: The problem arises when a new technology emerges, and someone puts e.g. a foo.jar file on their server, and can't edit the server configuration, and it gets serves as 'text/plain'
16:36:55 [ht]
TVR: I don't think there's anything we can do, besides maybe talking to Apache, given the current structure of things
16:37:23 [ht]
NM: I'm not even sure that making the "don't know don't tell" move would help -- what would clients do?
16:37:44 [ht]
... It would be bad for us if things got worse instead of better
16:38:12 [ht]
DO: We need to do some due diligence research
16:38:41 [ht]
DC: I think Roy F. already convinced Apache to move on the default, so we'll just have to see what happens
16:39:14 [ht]
... The other place we could try to help is wrt Microsoft's decision that sniffing is a security hole, and want to fix it
16:39:25 [ht]
SW: Due diligence?
16:39:46 [ht]
DO: Finding out what browsers do with no Content Type
16:40:14 [ht]
DC: There's also the fact that some browsers now allow you to turn off sniffing
16:40:21 [ht]
SW: I think I've done that
16:41:46 [ht]
TVR: Are we assuming that the Web's growth has stop -- this is the justification for freezing the current state of error recovery
16:41:58 [ht]
... which will in turn ensure that the Web stops growing
16:43:08 [DanC_lap]
fielding on apache defaults (not quite clear on "don't know don't tell")
16:48:28 [ht]
HST: Should we be trying to help avoid this kind of problem in the next generation of (non-browser-based) distributed application development platform
16:49:05 [ht]
DC: But the HTML5 WG believe that HTML5 _is_ the non-proprietary next generation distributed application platform
16:49:23 [ht]
TVR: Not application development, but UI
16:49:59 [ht]
[scribing partial]
16:50:18 [ht]
TBL: role of SVG
16:51:09 [ht]
NM: Things such as Silverlight don't have SVG (or HTML+CSS) but they are trying to achieve the SVG+HTML+CSS vision more thoroughly, wrt mutual recursion
16:51:44 [ht]
TVR: We should have viewed SVG as the rendering language for HTML
16:53:23 [ht]
NM: XAML has a distinction between an abstract list, a default rendering (a stack of boxes), but the potential for hugely varied actual rendering (a succession of fly-in circles, for example)
16:53:36 [ht]
s/but the/and the/
16:54:31 [ht]
DC: HTML5 is intended to compete for developer mindshare against that stuff, yes
16:54:45 [ht]
... CSS+HTML as a Flash killer
16:55:50 [ht]
NM: Video is the real qualitative change -- when I can paint movies on a shape just like painting a gradient, we're in a new place
16:56:04 [ht]
... SVG just isn't in that place
16:58:18 [ht]
SW: Are we done on this topic?
16:59:09 [ht]
TBL: A common thread here -- there's a lot of investment in the development of a distributed UI/applications platform based on HTML + CSS + SVG
16:59:14 [ht]
16:59:21 [ht]
NM: Well SVG like
16:59:53 [ht]
HST: Well, SVG doesn't figure in the HTML5 WG's grand plan
16:59:57 [ht]
DC: It doesn't?
17:00:27 [ht]
TVR: Well, at least not as the styling language for HTML5
17:00:44 [ht]
NM: How does this relate to the canvas tag?
17:01:09 [ht]
s/doesn't?/doesn't? They seem to me to go back and forth on that./
17:01:52 [Stuart]
17:01:54 [ht]
NM: If people asked say Webkit should we use canvas or SVG, what would they say?
17:02:00 [Stuart]
q- timbl
17:02:01 [ht]
TVR: canvas
17:11:19 [ht]
SW: We reopened [the content type sniffing issue] -- what might we do?
17:11:37 [ht]
DC: We could add an appendix to the finding which says "Yeah, but what happens in practice is this: ..."
17:14:17 [ht]
HST: What would we be conveying as the conclusion to draw?
17:14:25 [ht]
DC: That this was unfortunate
17:14:32 [ht]
NM: I don't want to undercut it
17:16:57 [ht]
SW: DC, do you have an open action on this front?
17:17:10 [ht]
DC: I come back to what I said about Microsoft's concerns here
17:17:18 [ht]
NM: Would this finding help them?
17:21:51 [Zakim]
17:21:52 [Zakim]
17:21:52 [Zakim]
TAG_f2f()10:00AM has ended
17:21:52 [Zakim]
Attendees were Norm, KC
17:24:41 [ht]
SW: Adjourned for lunch
19:26:08 [DanC_lap]
DanC_lap has joined #tagmem
19:31:42 [timbl]
timbl has joined #tagmem
19:31:52 [Ashok]
Ashok has joined #tagmem
19:33:29 [noah]
noah has joined #tagmem
19:33:43 [noah]
scribenick: noah
19:34:01 [noah]
meeting: W3C TAG F2F Afternoon of 24 Sept 2008
19:34:13 [noah]
scribe: Noah Mendelsohn
19:34:25 [noah]
19:34:37 [noah]
topic: HTML5: Embedding And Embedability
19:34:47 [noah]
See: agenda item at
19:35:42 [noah]
TVR: You want to embed other languages (MathML) in HTML, but also to embed HTML in other languages (ATOM), and you want recursion. Question: do you only get to embed particular languages that the browser has planned for, or do you also get to experiment with other things.
19:37:05 [noah]
TVR: In the 1996-1997 timeframe the assumption for XHTML etc. was that the more general extensibility would be supported, typically with browser plugins. Now the direction is toward centralization through one working group and a few browser vendors. I think that's a bad idea and leads to bad language design. It gets harder over time to add new things. Question: are we going to grow linearly from here, or continue to grow exponentially.
19:37:23 [noah]
TVR: Real distributed extensibility need not necessarily be in terms of namespaces.
19:37:53 [noah]
TVR: Early versions of Opera provided some support for extensibility by loading CSS that styled new, nonstandard elements.
19:38:22 [noah]
TVR: So, that's both the context and my personal opinion.
19:39:30 [noah]
TVR: Things to be aware of socially: there is a strong community among some of the browser vendors who believe that the era of rapid growth in specs is over.
19:39:54 [noah]
DC: Internet explorer is dominant, has some namespace support, and is continuing to refine the design.
19:40:11 [noah]
DO: You can can register handlers for namespaces.
19:40:22 [noah]
HT: That's how XForms works in Firefox.
19:40:57 [noah]
TVR: Browser extensions need hooks, and I don't see the browser vendors on a path to support that.
19:41:32 [noah]
DC: Should canvas have been <apple:canvas>.
19:41:48 [noah]
DO: The claim was it's better without namespace, because the transition to standard status is much easier.
19:42:21 [noah]
TVR: I think it's flawed to let one or two or three vendors control.
19:47:08 [DanC_lap]
I think SKW means this message of mine on distributed extensibility during the ARIA discussion
19:47:11 [noah]
NM: Wondering if Dan has signaled an interesting middle ground, in which namespaces are there for experimentation <apple:canvas>, but HTML 6 (say) can announce that the apple prefix is no longer needed for canvas, and that <canvas> is now the preferred spelling of what was in earlier worlds <apple:canvas>. You get the ability for people to experiment, but have at least some path to moving those experiments to be part of the base language later.
19:47:59 [Stuart]
19:48:16 [noah]
SW: Related to email ?
19:50:06 [noah]
HT: There are a number of plausible approaches consistent with W3C preferred direction, e.g. Sam Ruby's, the SVG proposal to HTML5 WG, and the media-type based namespace binding idea. This constellation of approaches will likely not be explored by the current HTML 5 WG, but I think should be taken seriously.
19:56:25 [noah]
q+ noah
20:01:00 [DaveO]
Here's the issue 41 raised in public-html
20:01:27 [DaveO]
Henri's response:
20:19:17 [noah]
SW: What's the story with SVG and MATHML? What's the preferred way from the SVG & MATHML wgs, and what's preferred by the HTML 5 folks?
20:21:03 [noah]
TBL: I don't think the HTML 5 spec talks about SVG and MATHML, but it's been discussed in the group. I think at least two approaches have been mentioned: 1) pour all SVG tags into HTML or 2) use appearance of <SVG> to enable svg vocabularies in the children.
20:21:14 [noah]
DC: The SVG stuff is commented out.
20:21:31 [noah]
HT: The SVG group made a proposal which was basically to switch to XML mode when you hit an SVG tag.
20:22:17 [noah]
DC: I had thought HTML 5 provided for drawing a circle when you saw a <circle>, but it doesn't. I think it just parses the tag.
20:22:31 [noah]
NM: Is there any hook for pointing to a spec that does draw a circle.
20:22:34 [noah]
DC: Not sure.
20:28:27 [DanC_lap]
draft HTML WG agenda
20:30:56 [timbl]
I note that the XHTML namespace document has been updated
20:32:18 [noah]
JR: I'm not clear on the constituency for distributed extensibility.
20:32:29 [noah]
TBL: Facebook ML?
20:34:29 [noah]
TBL: Aria is an example. Facebook had to extend HTML to put FBML in.
20:35:59 [noah]
JR: How do you appropriately position this for the W3C?
20:36:12 [noah]
DC: The modern way to do this is to write a blog article and get 700 comments.
20:36:20 [noah]
NM: We have a blog.
20:38:05 [DaveO]
fbml is a namespaced language,
20:38:41 [DaveO]
And XFBML is the language that gets embedded in html,
20:41:35 [noah]
NM: I think, if we try to write something in this space, we need to decide whether we are being careful and trying to get to the definitive analysis that's helpful in the long term, or are we trying to start a discussion quickly, with the risk of not doing a balanced analysis? I think the choice of blog, vs. email vs. draft finding should follow from the decision on what we're trying to acheive. I think to do something "carefully", you almost have to take
20:41:47 [noah]
Dan starts drafting some points in notepad using the projector.
20:45:31 [noah]
TVR: I'd like to do something that's somewhat independent of particular technologies. E.g. talk about serving small communities.
21:13:09 [DaveO]
21:14:05 [raman]
raman has joined #tagmem
21:14:45 [DaveO]
21:15:04 [noah]
***10 Minute Break***
21:23:34 [jar]
jar has joined #tagmem
21:56:54 [DanC_lap]
DanC_lap has joined #tagmem
21:59:14 [noah]
After the debate there was more noodling at the whiteboard. So far no conclusive result to show for it.
22:02:23 [noah]
topic: Uniform access to metadata
22:03:59 [noah]
JR: The question I have now is the same I had earlier, I.e. how to proceed. There appears to be call from a number of quarters for a prototocol that, given a URI, provides uniform access to metadata. The metadata may or may not come from the "owner" of the resource, and is typically in the form of document. This comes up in many contexts, and inconsistent answers are being invented.
22:04:37 [noah]
JR: The latest I've read is XRDS Simple, which I had not been aware of when I last looked at this subject. Document is from March of this year, and came up with the XRI work.
22:05:38 [DanC_lap]
(is AM talking about ?)
22:05:53 [noah]
AM: I'm curious regarding which approaches do you like, and why?
22:06:38 [noah]
JR: I sent messages to www-tag a few days ago. I think I sort of like the link header, and for those who are concerned about round trips a caching strategy might be possible, but I could change my mind.
22:06:46 [noah]
TBL: A way forward would be to write a finding.
22:07:50 [DanC_lap]
22:08:42 [noah]
DC: The TAG is on record as saying link is great.
22:08:53 [noah]
JR: Going on longer about it might be worth doing.
22:09:53 [DanC_lap]
(ah... "a primer on the use of Link: for uniform access to metadata". hmm.)
22:11:35 [noah]
NM: I think a finding like this should start by setting out the perceived requirements and needs of various communities of interest. When a technical solution is proposed, we should indicate which of those requirements are or or are not addressed.
22:12:08 [DanC_lap]
trackbot, status
22:12:21 [noah]
ACTION: Jonathan to prepare initial draft of finding on uniform access to metadata.
22:12:22 [trackbot]
Created ACTION-178 - Prepare initial draft of finding on uniform access to metadata. [on Jonathan Rees - due 2008-10-01].
22:12:49 [noah]
HT: I think it's worth looking at the ark work, as it has some attractive characteristics.