01:45:51 noah has joined #tagmem 13:58:22 RRSAgent has joined #tagmem 13:58:22 logging to http://www.w3.org/2008/09/24-tagmem-irc 13:58:23 jar has joined #tagmem 13:58:45 Meeting: TAG f2f, Wednesday morning 2008-09-24 13:58:51 Stuart has joined #tagmem 13:59:12 timbl has joined #tagmem 13:59:51 Norm has joined #tagmem 14:00:12 Agenda: http://www.w3.org/2001/tag/2008/09/f2fkc-agenda.html 14:00:21 Chair: Stuart Williams 14:00:28 Scribe: Henry S. Thompson 14:00:33 ScribeNick: ht 14:01:23 DanC_lap has joined #tagmem 14:01:32 Topic: 3.5 Self Describing Web 14:01:40 http://www.w3.org/2001/tag/2008/09/f2fkc-agenda.html#selfDescribingWeb 14:02:07 SW: Noah has produced a draft: http://www.w3.org/2001/tag/doc/selfDescribingDocuments-2008-09-08 14:02:24 DaveO has joined #tagmem 14:02:29 NM: There are some specific things the group might want to concentrate on 14:03:08 hmm... passive voice... "Web resource representations should be published using widely deployed standards and formats. " 14:03:22 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 ""Error loading stylesheet: An XSLT stylesheet does not have an XML mimetype:http://www.w3.org/2001/tag/doc/selfDescribingDocuments.xsl""" 14:03:31 http://www.w3.org/2001/tag/doc/selfDescribingDocuments-2008-09-08.html#RDF 14:04:30 NM: There's an ednote there -- we have a choice here wrt RDF-XML, N3 or both for this example 14:04:52 SW: SWBP uses N3 for their tutorials 14:05:11 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 AM: Why not both? 14:05:40 NM: longer 14:05:47 DC: I think not 14:06:32 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 JR: N3 is easier to read 14:07:23 ... but is their a media-type registered for N3? 14:07:33 TBL: It's in progress 14:07:52 SW: Not a great example, then 14:08:00 HT: That's a definitive 'no' for me 14:08:09 hmm... s/information/data/? "RDFa should be used to make information conveyed in HTML self-describing. " 14:08:23 DC: So that would be an unhelpful distraction at this time 14:08:35 JR: Reluctantly, agreed 14:08:59 missing quote: "http://example.org/GRDDL_For_employeeNS.xsl> 14:09:24 RESOLUTION: Request the editor to use the XML version only at the beginning of chapter 5 14:09:56 NM: Next issue arose first at the Bristol f2f, to do with RDFa 14:10:01 ... in section 5.1 14:10:02 -> http://www.w3.org/2001/tag/doc/selfDescribingDocuments-2008-09-08#UsingRDFa 14:10:51 From Norm's paraphrase of the Bristol minutes: 14:10:51 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 | - The paragraph starting "Even though this document is of media type 14:10:56 | application/xhtml+xml " needs to be replaced with following your nose 14:10:56 | through: application/xhtml+xml -> RFC 3236 -> HTML M12N -> 14:10:56 | http://www.w3.org/1999/xhtml -> RDFa specification 14:11:47 [That quote my understanding of the Bristol minutes, ratified by the scribe at the time, NW] 14:12:03 s/[/NM: / 14:12:08 s/NW]/NW/ 14:13:44 NM: But the problem is that that chain is not well-supported by the documents involved 14:14:17 ... email exchanges suggested that XHTML modularization isn't involved 14:14:56 ... and I haven't gotten a story from those exchanges which gave a full answer 14:15:46 HT: Why can't you go straight to the namespace document, from application/____+xml 14:16:39 NM: You may have uncovered another problem, because I don't see how 3023 licenses looking at namespace docs 14:16:54 HT: Then you have a problem higher up in this document, don't you, in section 4.2.3? 14:17:28 NM: Let's see -- the beginning of that is true, but not justified by 3023 14:18:51 ... Ah, actually, it does have a reference to namespace documents 14:19:25 ... So maybe I could/should back off from the XHTML modularization route, but I could go via 3023 14:20:05 q+ to ask why http://www.iana.org/assignments/media-types/text/ has no link under text/html 14:20:08 JR: Does 3236 point to 3023? 14:20:13 q? 14:20:14 NM: Checking -- yes. 14:20:41 q+ to say how about adding some of the proof statements, ala versioning.. 14:20:42 TBL: If we think it's necessary, we can always request changes that we need 14:21:18 ack danc 14:21:18 DanC_lap, you wanted to respond to concerns about various bits of prose with some notes about test cases http://lists.w3.org/Archives/Public/public-html/2008Jun/0335.html 14:21:36 http://www.iana.org/assignments/media-types/text/ 14:23:00 TBL: I thought there was an issue here, but I guess it's OK 14:23:44 DC: IANA are going to supply APIs to access this information: text, HTML and XML 14:23:51 (resolution? I think the editor is collecting advice. hmm.) 14:24:23 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 TBL: I thought I suggested the _schema_ should be updated 14:25:37 DC: Namespace document not updated yet, either way 14:26:05 (hunting for a pointer to these plans...) 14:26:11 q+ 14:26:20 ack timbl 14:26:20 timbl, you wanted to ask why http://www.iana.org/assignments/media-types/text/ has no link under text/html 14:26:26 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 ... Does that work? 14:27:13 TBL: In theory, yes. In practice, I would like to see the change to the NS doc. right away 14:27:22 DC: Should have been a CR exit criterion, but too late 14:27:50 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 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 TBL: It's a bug that this hasn't been addressed 14:28:39 DC: An important point of this finding is to impact the RDFa spec. 14:28:57 ... It's part of the TAG's job to make that happen 14:29:10 NM: They've said they will do it, I can explain to them why it matters 14:29:34 NM: Can we agree to the above proposal, wrt this finding? 14:30:10 TBL: We _also_ need an action to make sure the XHTML namespace change gets done 14:30:28 action-130? 14:30:28 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 http://www.w3.org/2001/tag/group/track/actions/130 14:30:36 perhaps that's no longer done to timbl's satisfaction 14:31:19 action-130? 14:31:19 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 http://www.w3.org/2001/tag/group/track/actions/130 14:31:32 Well, I consulted ... but I didn't get an action token back 14:31:35 from Ralph 14:31:43 I thought you did, but I can't confirm 14:34:05 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 TVR: That leaves actions dangling on other documents 14:34:57 NM: There is another action now, on TBL, to make the necessary changes 14:35:21 DC: I like TVR's story 14:35:24 NM: Which is? 14:35:37 DC: A pointer to the plan 14:35:48 NM: Happy to include it 14:36:16 +1 " to move to a path via 3023 ..." 14:37:53 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 NM: One more issue -- the Good Practice note about using RDFa 14:39:13 ... Is this too specific too early? Should I kill it? 14:39:40 HT: I would prefer to kill it, as I would use GRDDL if I wanted to move my H 14:39:59 s/my H/my HTML towards RDFa/ 14:40:09 TBL: It's ambiguous as written 14:40:50 SW: RDFa allows you to put RDF in your document, but it's not necessarily descriptive of that document. 14:41:00 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 NM: This doesn't disagree, it just says you should do this one 14:42:20 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 ... The first is about how to _interpret_ this document at all, the other is quite different 14:43:16 TBL: Something with metadata at the top is 'self-describing' -- the thing here is more like 'grounded in the web' 14:43:54 ... I think JR is on to something important -- I'm not happy with e.g. the 3rd sentence in the abstract 14:44:16 ... We would be better off using 'grounded in the web' 14:44:29 NM: This is a bit late in the process to make such a sweeping change 14:45:38 TVR: Connecting back to yesterday, I'm uneasy about the reliance on a mixture of English and fully mechanically exploitable information 14:46:27 q+ 14:46:38 JR: I think I know how to fix this 14:47:11 ... Leave most of the wording in the document alone, by making clear what you mean by 'self-describing' 14:47:29 NM: So can we put this to one side while we work on the rest of the document 14:50:05 q? 14:50:24 q+ to make some points 14:50:44 ack DaveO 14:50:44 DaveO, you wanted to say how about adding some of the proof statements, ala versioning.. 14:51:17 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 ... I think the requested changes are worth it 14:53:06 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 NM: In which examples? 14:53:24 DO: Microformats maybe, XML itself 14:53:32 NM: I thought I had the references 14:53:44 DO: My suggestion is to look at actually pulling in the quotes 14:53:52 NM: Useful idea, I'll have a look at doing that 14:53:56 ack DanC 14:55:00 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 ... and they don't care about RDF either . . . 14:55:21 NM: Change required? 14:55:24 DC: Not sure 14:55:57 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 ... I can live with these as they are 14:56:17 NM: Should we fix this now? 14:56:20 http://www.w3.org/2001/tag/doc/selfDescribingDocuments-2008-09-08-a.html 14:56:25 DC: SW, NW? 14:56:38 SW: I didn't comment on that, no 14:56:56 I can live with the passive voice. I have a hard time weeding it out of my own writing 14:56:57 JR: I did have a problem with the tone of the little boxes 14:57:48 DC: The "Representations provided directly in RDF" doesn't describe a Good Practice at all. . . 14:57:56 q? 14:59:26 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 SW: Where did the middle clause come from? 14:59:47 With regrets, I have to step away for 60 minutes or so. Back ASAP 15:00:03 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 NM: The preceding discussion of the tradeoffs between direct and e.g. GRDDL-mediated provision 15:00:49 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 q+ 15:05:04 q? 15:05:59 s/in general/in general there in the document/ 15:06:46 NM: 'web-grounded' is too geeky. . . 15:07:03 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 TBL: JR is right that there is an important distinction here that you are blurring 15:07:25 NM: I think I got this all in the document 15:08:06 TBL: The crucial point is the the (short) list of things I have to know in advance 15:08:12 q- tbl 15:08:17 q- timbl 15:08:40 TBL: What is the basic core, for someone who understands English? 15:09:12 NM: see the end of section 2 15:10:16 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 ... 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 q? 15:11:11 NM: So what change to the document do we need? 15:11:35 TBL: Particularly, not applying 'self-describing' to documents, just to the Web as a whole 15:11:50 NM: Are you optimistic that what JR proposes will fix the problem you have? 15:12:06 TBL: The list of core documents isn't in that, is it 15:12:39 ... 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 s/message/message"/ 15:13:57 DC: 's-d' applies well to the Web, but doesn't apply well to documents, is what TBL has been saying 15:14:00 NM: And you? 15:14:34 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 NM: I explained it's a term of art 15:14:48 DC: Yes, but it contradicts itself 15:15:10 JR: I suggested a compromise, in order to get this published, but a bigger fix could be done 15:15:21 q? 15:15:25 NM: I'd rather get it right if it makes a big difference 15:15:33 ack ht 15:15:33 ht, you wanted to make some points 15:15:44 (surveying usage of "self-describing document" in a larger community) 15:16:22 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 has joined #tagmem 15:17:09 noah: Self-describingness is always a matter of degree 15:17:23 ht: Self-describing may be a bad choice for a term of art 15:17:32 (ew... scary... top hit for "self-describing document", after w3.org, is some patent stuff.) 15:18:15 ht: Documents are self-contained if they don't require more than the core to ... 15:18:34 q? 15:18:43 (what fix did noah just refer to?) 15:18:55 "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 ht: An HTML document with RDFa is self-describing in the ordinary sense of the word 15:19:07 q? 15:19:47 TBL: You could try to use 'self-describing' in your way to a web-arch-sophisticate 15:20:24 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 (I find this abuse of "self-describing document" is reasonably wide-spread. I think it's OK in this document.) 15:20:38 ack danc 15:20:40 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 ... body. 15:20:57 NM: But to me that feels like a matter of degree 15:21:13 TBL: But an image can't be self-describing 15:21:37 DC: Why is Least Power in the references section, but not in the body? 15:21:49 http://www.w3.org/2001/tag/doc/selfDescribingDocuments-2008-09-08-a.html 15:21:52 NM: I think it was, but just hasn't been pruned 15:22:17 That is a document with a fix to the abstract and the phrase 'web-grounded" used 15:22:30 DC: Henri Sivonen points out that GRDDL means you have to run a programme to interpret your document 15:23:07 ... So you should either delete the reference, or add some explanation 15:23:12 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 TBL: I have done an alternative draft with 'web-grounded': http://www.w3.org/2001/tag/doc/selfDescribingDocuments-2008-09-08-a.html 15:24:45 (self-similar means it's elements-all-the-way-down...) 15:24:59 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 q+ 15:25:16 ... as in the way we drilled on the terms in the versioning findings 15:25:23 q- DaveO 15:25:43 DO: And that may mean some counterexamples 15:26:08 NM: My problem is I don't yet hear clearly what the TAG is trying to get me to say 15:26:53 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 ... This is our role as educating people 15:28:52 (hmm... I missed that about "self-describing web") 15:28:59 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 NM: But that means that my own private format is grounded in the web. 15:30:17 TBL: It is, but the "use widely deployed standards" is a separate point, already made in AWWW 15:31:09 NM: So I'm willing to explore a way to make this work, but it's going to take some work 15:31:21 DC: I think we could finish this this week 15:31:29 NM: I want more time 15:32:07 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 (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 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 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 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 SW: Break time 15:36:34 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 NM: I'm concerned that we get DO and e.g. HST on the same page 16:05:47 [Break] 16:06:20 Topic: 3.6 passwordsInTheClear-52 (ISSUE-52) 16:09:02 s/3.6 passwordsInTheClear-52 (ISSUE-52)/3.4.4 HTTP And HTML/ 16:09:15 (hmm... something from the self-describing-web discussion in the break should be recorded as an action, probably. maybe later today...) 16:09:36 TVR: Based on yesterday's discussion, this issue follows on from our 3rd discussion yesterday 16:10:07 ... There are ways in which what's happening in HTML5 interacts with other standards work 16:10:42 (for reference... HTTPbis WG http://www.ietf.org/html.charters/httpbis-charter.html ) 16:10:44 ... but rather than digging in to the specific technical issues, we should look at how to address the overlap/conflict problem 16:11:45 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 ... 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 q? 16:13:52 DC: News to me that no browser participation in the http-bis work 16:14:08 TVR: Not sure, although pretty sure that WHAT-WG are not in there 16:14:49 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 TVR: Thinking back to the error recovery topic, there are two aspects: 16:15:46 ... 1) There are always corner-cases where a spec. isn't completely clear, and different implementations go in different ways; 16:16:24 ... 2) The case where things are clearly wrong, but accepted anyway, and then the bad drives out the good 16:16:32 Zakim, this is tag 16:16:32 ok, DanC_lap; that matches TAG_f2f()10:00AM 16:16:38 Zakim, who's on the phone? 16:16:38 On the phone I see ??P0, Norm 16:16:43 Zakim, ??P0 is KC 16:16:43 +KC; got it 16:17:01 ... 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 TVR: The hard case is at the intersection between HTTP and HTML, namely content-type sniffing 16:19:19 HST: What should we do about Content Type Sniffing? 16:19:35 DC: We have reopened the issue 16:19:58 ... Do people know what the browser vendors say when you tell them "get with the program"? 16:20:15 NM: There's lots of deployed stuff 16:20:52 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 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 [scribe didn't understand why] 16:22:46 TBL: Sniffing today is mostly on text/plain, which is taken as sort of a wildcard 16:23:39 ... 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 ... On this front, HTML5 is not unreasonable 16:24:09 TVR: But browsers sniff on more than text/plain 16:25:31 ... Sam Ruby knows the details 16:26:03 HST: I thought there was sniffing of text/html, the whole standards-mode vs. whatever stuff 16:26:11 TBL: I didn't think so 16:26:51 TBL: There's a bit in the HTML5 spec about maybe waiting 500bytes before deciding what to do 16:28:21 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 ... 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 s/alternative/alternatives/ 16:29:46 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 DC: If we want to, then what? 16:30:33 TVR: There's the conflict between servers trying to do the right thing and browsers trying to do the right thing 16:30:46 ... plus the lag in updating either one, and the long tail of legacy 16:31:12 ... What the TAG can do I don't know -- it's a function of what W3C wants to do. 16:34:00 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 DC: I think they already do 16:34:57 TVR: Yes, Content Type is optional, but everybody _thinks_ Content Type is required because scripts always start "print 'text/html'" 16:36:12 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 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 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 ... It would be bad for us if things got worse instead of better 16:38:12 DO: We need to do some due diligence research 16:38:41 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 ... 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 SW: Due diligence? 16:39:46 DO: Finding out what browsers do with no Content Type 16:40:14 DC: There's also the fact that some browsers now allow you to turn off sniffing 16:40:21 SW: I think I've done that 16:41:46 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 ... which will in turn ensure that the Web stops growing 16:43:08 fielding on apache defaults (not quite clear on "don't know don't tell") http://lists.w3.org/Archives/Public/public-html/2008Jan/0258.html 16:48:28 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 DC: But the HTML5 WG believe that HTML5 _is_ the non-proprietary next generation distributed application platform 16:49:23 TVR: Not application development, but UI 16:49:59 [scribing partial] 16:50:18 TBL: role of SVG 16:51:09 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 TVR: We should have viewed SVG as the rendering language for HTML 16:53:23 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 s/but the/and the/ 16:54:31 DC: HTML5 is intended to compete for developer mindshare against that stuff, yes 16:54:45 ... CSS+HTML as a Flash killer 16:55:50 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 ... SVG just isn't in that place 16:58:18 SW: Are we done on this topic? 16:59:09 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 DC: SVG? 16:59:21 NM: Well SVG like 16:59:53 HST: Well, SVG doesn't figure in the HTML5 WG's grand plan 16:59:57 DC: It doesn't? 17:00:27 TVR: Well, at least not as the styling language for HTML5 17:00:44 NM: How does this relate to the canvas tag? 17:01:09 s/doesn't?/doesn't? They seem to me to go back and forth on that./ 17:01:52 q? 17:01:54 NM: If people asked say Webkit should we use canvas or SVG, what would they say? 17:02:00 q- timbl 17:02:01 TVR: canvas 17:11:19 SW: We reopened [the content type sniffing issue] -- what might we do? 17:11:37 DC: We could add an appendix to the finding which says "Yeah, but what happens in practice is this: ..." 17:14:17 HST: What would we be conveying as the conclusion to draw? 17:14:25 DC: That this was unfortunate 17:14:32 NM: I don't want to undercut it 17:16:57 SW: DC, do you have an open action on this front? 17:17:10 DC: I come back to what I said about Microsoft's concerns here 17:17:18 NM: Would this finding help them? 17:21:51 -Norm 17:21:52 -KC 17:21:52 TAG_f2f()10:00AM has ended 17:21:52 Attendees were Norm, KC 17:24:41 SW: Adjourned for lunch 19:26:08 DanC_lap has joined #tagmem 19:31:42 timbl has joined #tagmem 19:31:52 Ashok has joined #tagmem 19:33:29 noah has joined #tagmem 19:33:43 scribenick: noah 19:34:01 meeting: W3C TAG F2F Afternoon of 24 Sept 2008 19:34:13 scribe: Noah Mendelsohn 19:34:25 agenda: http://www.w3.org/2001/tag/2008/09/f2fkc-agenda 19:34:37 topic: HTML5: Embedding And Embedability 19:34:47 See: agenda item at http://www.w3.org/2001/tag/2008/09/f2fkc-agenda#html5Embedding 19:35:42 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 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 TVR: Real distributed extensibility need not necessarily be in terms of namespaces. 19:37:53 TVR: Early versions of Opera provided some support for extensibility by loading CSS that styled new, nonstandard elements. 19:38:22 TVR: So, that's both the context and my personal opinion. 19:39:30 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 DC: Internet explorer is dominant, has some namespace support, and is continuing to refine the design. 19:40:11 DO: You can can register handlers for namespaces. 19:40:22 HT: That's how XForms works in Firefox. 19:40:57 TVR: Browser extensions need hooks, and I don't see the browser vendors on a path to support that. 19:41:32 DC: Should canvas have been . 19:41:48 DO: The claim was it's better without namespace, because the transition to standard status is much easier. 19:42:21 TVR: I think it's flawed to let one or two or three vendors control. 19:47:08 I think SKW means this message of mine on distributed extensibility during the ARIA discussion http://lists.w3.org/Archives/Public/www-tag/2008Apr/0226.html 19:47:11 NM: Wondering if Dan has signaled an interesting middle ground, in which namespaces are there for experimentation , but HTML 6 (say) can announce that the apple prefix is no longer needed for canvas, and that is now the preferred spelling of what was in earlier worlds . 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 q? 19:48:16 SW: Related to email http://lists.w3.org/Archives/Public/www-tag/2008Apr/0226.html ? 19:50:06 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 q+ noah 20:01:00 Here's the issue 41 raised in public-html http://lists.w3.org/Archives/Public/public-html/2008May/0120.html 20:01:27 Henri's response: http://lists.w3.org/Archives/Public/public-html/2008May/0182.html 20:19:17 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 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 to enable svg vocabularies in the children. 20:21:14 DC: The SVG stuff is commented out. 20:21:31 HT: The SVG group made a proposal which was basically to switch to XML mode when you hit an SVG tag. 20:22:17 DC: I had thought HTML 5 provided for drawing a circle when you saw a , but it doesn't. I think it just parses the tag. 20:22:31 NM: Is there any hook for pointing to a spec that does draw a circle. 20:22:34 DC: Not sure. 20:28:27 draft HTML WG agenda http://lists.w3.org/Archives/Public/public-html/2008Sep/0303.html 20:30:56 I note that the XHTML namespace document has been updated http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2008Sep/0128.html 20:32:18 JR: I'm not clear on the constituency for distributed extensibility. 20:32:29 TBL: Facebook ML? 20:34:29 TBL: Aria is an example. Facebook had to extend HTML to put FBML in. 20:35:59 JR: How do you appropriately position this for the W3C? 20:36:12 DC: The modern way to do this is to write a blog article and get 700 comments. 20:36:20 NM: We have a blog. 20:38:05 fbml is a namespaced language, http://wiki.developers.facebook.com/index.php/FBML 20:38:41 And XFBML is the language that gets embedded in html, http://wiki.developers.facebook.com/index.php/XFBML 20:41:35 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 Dan starts drafting some points in notepad using the projector. 20:45:31 TVR: I'd like to do something that's somewhat independent of particular technologies. E.g. talk about serving small communities. 21:13:09 http://drop.io/uh9ijos 21:14:05 raman has joined #tagmem 21:14:45 http://drop.io/uh9ijos 21:15:04 ***10 Minute Break*** 21:23:34 jar has joined #tagmem 21:56:54 DanC_lap has joined #tagmem 21:59:14 After the debate there was more noodling at the whiteboard. So far no conclusive result to show for it. 22:02:23 topic: Uniform access to metadata 22:03:59 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 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 (is AM talking about http://www.hueniverse.com/hueniverse/2008/09/discovery-and-h.html ?) 22:05:53 AM: I'm curious regarding which approaches do you like, and why? 22:06:38 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 TBL: A way forward would be to write a finding. 22:07:50 q+ 22:08:42 DC: The TAG is on record as saying link is great. 22:08:53 JR: Going on longer about it might be worth doing. 22:09:53 (ah... "a primer on the use of Link: for uniform access to metadata". hmm.) 22:11:35 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 trackbot, status 22:12:21 ACTION: Jonathan to prepare initial draft of finding on uniform access to metadata. 22:12:22 Created ACTION-178 - Prepare initial draft of finding on uniform access to metadata. [on Jonathan Rees - due 2008-10-01]. 22:12:49 HT: I think it's worth looking at the ark work, as it has some attractive characteristics.