W3C

TAG F2F day 3 -- 25 Sep 2009

25 Sep 2009

See also: IRC log

Attendees

Present
jar, masinter, noahm, DanC, noah, TimBL, ht, johnk, raman
Regrets
Chair
Noah Mendelsohn
Scribe
Ashok Malhotra, Jonathan Rees

Contents


<Ashok> scribe: Ashok Malhotra

<Ashok> scribenick: Ashok

Noah: reviews the agenda
... I would like to spend majority of our time on HTML
... skip TAG Priorities
... Let's do admin right after lunch

Jar: Let's ask people what they are gonna do

Noah: Let's use Action Item list

HTML Issues

HTML

Noah: What should be next topic for discussion

Larry: I thought were close to consensus on sniffing

Noah: Let's do it on a telcon

Larry: I think we could come up with a position on it.

HT: I have action to propose pushback or accept status quo

Noah: Who wants to discuss sniffing now?

<DanC_lap> action-309?

<trackbot> ACTION-309 -- Henry S. Thompson to s. to bring back proposed TAG pushback on sniffing and HTTP bis draft http://trac.tools.ietf.org/wg/httpbis/trac/export/663/draft-ietf-httpbis/latest/p3-payload.html, or his recommendation that we leave it alone -- due 2009-10-01 -- OPEN

<trackbot> http://www.w3.org/2001/tag/group/track/actions/309

HT: My inclination is to ask them for a health warning

Larry: I would like to discuss for 10 mts

Poll 3 to 1 ... not now

Noah: What next item to discuss

DC: Data facilities

HT: I would like to report what I found out wrt item 13

HT to give 3 minute report on item 13

HT: I took the binary attribute case

Tim: Boolean

HT: I explored that whereever there was an error there should be error recovery case
... I sent mail and was told "No, what you say goes in the DOM"

<DanC_lap> (ht, did you say "it's all in public-html"? I don't see it in http://lists.w3.org/Archives/Public/public-html/2009Sep/thread.html )

HT: Reason is -- this is an extensibility point

<DanC_lap> (false advertising. this is discussion. not clarification)

Larry: Is input disabled or is it not?

<DanC_lap> ah... found it: Where is processing of binary attributes covered? Henry S. Thompson (Wednesday, 23 September) http://lists.w3.org/Archives/Public/public-html-comments/2009Sep/0064.html

HT: It IS disabled
... Binary attributes are true if present, false if not present

Larry: So, disabled = false results in TRUE

HTML Data Facilities

Tim: 2 overlapping concerns --- how should data be handled in HTML, --- overlap with extensibility of tags
... it's important to put RDF into HTML
... RDFa spec tells you how to do that.
... Hixie said removing namespaces was a goal, and it's hard to use RDFa without namespaces.

Noah: Shall we separate extensibility concerns?

Tim: I'm happy to discuss microdata and Hixie's special data format

<jar> 'rdfh' ... I'd like to hear more about this

Tim writes on board --- RDF in HTML, RDF, microformats, Data-Attributes, ---- no NS in HTML, Extension Tags

photo of whiteboard

Tim: These are various positions people have taken

<noahm> We are using the queue

<noahm> I think

jar: Has anyone articulated that you might do RDF in HTML w/o namespaces?

DC: There is a proposal

<jar> the answer was: Yes, data-... does RDF in HTML, but only an (albeit useful) subset.

Tim: Some say don't bother with namespaces; others say give me the namespaces tool

<DanC_lap> TBL: the blobs [in the whiteboard diagram] are positions; the x's are issues.

Larry: HTML5 now has a data format based on no known experience

DC: No deployment of the data stuff

<DanC_lap> blobs = RDF in HTML, RDFa, Need NS in HTML, microformats, data-*, No NS in HTML, Extending Tags

jar: You could extract triples from data-attributes

DC: That code has been written

Discussion about whether data- or item-property

Noah opens HTML spec

DC: 5.2 Microdata

<DanC_lap> http://dev.w3.org/html5/spec/Overview.html#encoding-microdata 5.2 Encoding microdata

<DanC_lap> http://dev.w3.org/html5/spec/Overview.html#custom-data-attribute 3.2.3.8 Embedding custom non-visible data

DC: Custom data attributes: 3.2.3.8

Noah: What is difference between data- and the item stuff
... if you do data- you get a Javascript object with that name

DC: What's the motivation?

Noah: Extends that data space for Javascript programmers

HT: It's a way of extending attribute space
... The para after the note is the justification

Noah: How [?] different from item-
... is there a glimmer of a comment here?

JK: There may be another position --- no NS mapping rather than no NS

Noah: There is third position ... just use short names and handle collisions

Tim: The item- maps to a URI

JK: Section 5.1.3 in WHATWG spec
... says "As URLs"

Larry: This section is non-normative

Tim: This is a competing proposal to RDFa
... subject is where it is attached to

Looking a frag in 5.1.2

Tim: Item property can be a URI or a reverse[d] domain name thingie

Noah: Both data- and item overlap with RDFa
... could extract RDFa from this

jar: That is not a usecase

<Zakim> johnk, you wanted to note that I believe "no namespace prefix mapping" is more accurate than "no namespace"

Discussion on whether RDFa can be represented in this form

Tim: Go to 5.1.4 and look at example
... 2 properties of Hedral

JK: Section 5.2.3
... Associating names with Items

HT: In 5.1.1 near the end --- properties don't have to be given as descendents of the element with item attribute
... They can be associated with a specific item using the itemfor attribute which takes the ID of the element with the item attribute

DC: There is a well-known pattern for licenses for images. Is that expressible in this syntax.

<timbl> http://dev.w3.org/html5/spec/microdata.html#overview

HT: Properties that also have values that are URLs. This is achieved by using the a element and the href attribute, ....

Tim: 5.5.2 RDF ...

<ht> Looks to me that <img src="....." item /> <div style="display: hide"><a href="xxxxx" itemprop="[CCREL]"></a></div> will do it

Tim: We could make a comment about the process

<Zakim> ht, you wanted to ask about <script type="text/rdf+xml">...</script>

HT: Minor aspect of script which says the script item is used to introduce script or data ... type of data is given by type attr of script

<Zakim> noahm, you wanted to say, I claimed this stuff was related to GRDDL more than RDFa and to

HT: does not say what you can do with the data

<jar> ben a: " it makes things much more roundabout to write since itemprop applies to both (either?) @href and the element content"

HT: The item I put in IRC log will do what jar asks
... I left out the ID and the item4

<ht> <img src="....." item id="photo7" /> ... <div style="display: hide"><a href="xxxxx" itemprop="[CCREL]" subject="photo7"></a></div>

Tim: Critiques the algorithm

<ht> more recent draft uses 'itemfor' for 'subject'

Tim: There is incredible tension between communities expressed on the board
... TAG could perform useful function.
... is it functionally equivalent to RDFa, or not?

<DanC_lap> ht, we could try out the example you made...

<DanC_lap> [10:17] <Philip> DanC_lap: http://philip.html5.org/demos/microdata/demo.html ?

<DanC_lap> [10:18] <Philip> Also http://james.html5.org/microdata/

Larry: I'm concerned about us not driving to statements

<DanC_lap> [10:17] <Philip> DanC_lap: http://philip.html5.org/demos/microdata/demo.html ?

<DanC_lap> [10:18] <Philip> Also http://james.html5.org/microdata/

Larry: I have a process suggestion
... create statements and choose between them

DC: That may be helpful

Larry: 10 minutes to solicit things we may say

<noahm> JAR: One thing we might say [straw man] is: "HTML has to adopt namespaces and RDFa" (not sure I believe that, but it's one thing we might want to say)

<jar> or reject

<DanC_lap> LMM: I see no justification for reverse[d] domain name labels where URIs would solve the problem

<DanC_lap> tbl 2nds

Larry: No justification for introducing reverse[d] domain-based namespace mechanisms are adequate

<jar> (jar was confused by 'reverse DNS' - I think what's meant is "reversed domain names" and is not related to reverse DNS lookup)

Tim: RDFa and item- are almost identical functionality
... so they create fragmentation which is always damaging

<johnk> Notes: http://www.balisage.net/Proceedings/vol3/html/Quin01/BalisageVol3-Quin01.html on "automatic XML namespaces"

HT: Introducing a new unimplemented and untried design where there is an implemented tried design is not helpful

<Zakim> DanC_lap, you wanted to say we might say that RDFa should have no special status just because it's a REC, since W3C allowed it to go thru CR without coordination with HTML 5

<jar> is there a requirements statement for item, itemprop etc? is rdf capture a requirement? where articulated?

Noah: The item- is simpler syntactically ... I'm half-convinced about this

<johnk> ... and http://lists.xml.org/archives/xml-dev/200907/msg00157.html "pragmatic XML namespaces"

Noah: not enough justification for duplication

<DanC_lap> (re "would anybody use microdata?" there's a relevant thread at http://lists.w3.org/Archives/Public/public-html/2009Jun/thread.html#msg732 )

Tim: RDF is REALLY simple
... first notation for mapping RDF to XML was really complicated

<johnk> "How to make namespaces in XML easier": http://ln.hixie.ch/?start=1151612438

<noahm> I heard Tim say the opposite; I heard him say RDF as a model is inherently very simple, but RDFa (and also RDF/XML) is suprisingly complicated

Tim: there is a lot of parser state to be carried along

<noahm> For those curious about my "Tim said the opposite" comment, our scribes used log edits to fix what Tim said. I do not believe said the opposite of the fixed comment.

<timbl> ... aka /opposite/d

BREAK till 10:50

<timbl> I said that RDF/XML was surprisingly complicated, people saying that that came from its attempt to look like "colloquial XML"; that we had a few other attempts at syntaxes, including N3, and then in *ML again we had RDFa, maybe the fourth, which to me was surprisingly complicated, involving a surprising amount of state to be held by the parser duriung its recursive descent, and now we have RDFb (lets call it) whcih attempts the same thing, and again is surprisingly

<timbl> complicated when you look at the algorithm. Is there a fundamental difficulty to this challenge?

JK: I pasted a link about distributed extensibility above

<noahm> Chair notes that we are filling some time talking about proposals that are floating around for namespace-based extensibility until Tim gets back.

JK: there are other proposals: Liam Quin and Tim Bray's delta on Micah Dubinko's proposal

<johnk> http://www.balisage.net/Proceedings/vol3/html/Quin01/BalisageVol3-Quin01.html

<noahm> JK: First proposal is Balisage proposal from Liam Quin

<masinter> references include pointer to http://ln.hixie.ch/?start=1151612438

HT: This says we are going to associate NSs with some elements. Does away with prefixes

DC: There is some outboard doc that gives the mapping

HT: Processors will bake in a version of the doc they support

Noah: Some will be baked in, others [specified] in an outboard doc

DC: Does this work like static scoping?
... if elements indicate namespaces then it's like static scoping

<johnk> xml-dev collated proposal http://www.dpawson.co.uk/namespaces/index.html

JK: This where the thread that Micah started ended up ... this has notion of reverse[d] domain syntax
... Micah's email

<johnk> http://lists.xml.org/archives/xml-dev/200907/msg00157.html

HT: This is too disruptive, so it's a non-starter

Noah: Do we continue on Data Facilities? or move to other topics?

<Zakim> DanC_lap, you wanted to say that complexity for the parser is often anti-correlated with complexity for the author

<Zakim> danc2, you wanted to ask who are the daily minutes-editors

DC: There are 2 kinds of complexity: for authors and for parser writers

Tim: If it's hard to write the parser it's hard for authors

<noahm> In about 7 minutes, which will be ~ halfway through, I will stop discussion to see if we are closing in on next steps.

<jar> danc: Syntactic sugar and defaults make authoring easier but parsing harder

Discussion about syntactic sugar

Tim: 2 pieces --- triples and triple state

<DanC_lap> TBL: both [sorts of complexity] make learning the language harder

<masinter> and also that 'data' and 'metadata' are really the same

DC: Do users grok or not .... people pick up RDFa and use it. People don't use microdata

<masinter> and also that i think the charter of the group and the right answer is that neither RDFa nor data should be part of HTML spec and are out of scope for group's charter, group was charatered to produce extensibility

Larry: HTML WG was not chartered to do any of this work .... this ought to be out of scope
... area should be able to evolve independently from the HTML language

<timbl> http://www.w3.org/TR/rdfa-syntax/

Larry: HTML is not usually written by humans; it is generated from database tools
... complicated tool chains
... one of the proplems with NSs is that NS-based markup does not cut and paste well

<Zakim> masinter, you wanted to talk about complexity for tools for generating, ability to mash-up, ability to copy-paste

<masinter> without moving to dom

<Zakim> danc3, you wanted to note complexity discussion currently

DC: There are various threads about complexity of HTML5. Opportunity to get involved in current discussion

<Zakim> johnk, you wanted to ask Larry if he thinks that's true with XHTML changes

<DanC_lap> Complexity of HTML5 (was Re: The Complexity Argument) Maciej Stachowiak (Sunday, 20 September) http://lists.w3.org/Archives/Public/public-html/2009Sep/0814.html

JK: Asks about charter? Should it still be true given that XHTML is winding down.
... there are specific needs to do the extensibility

<Zakim> DanC_lap, you wanted to note sympathy with the "add an extensibility mechanism, not RDFa nor microdata directly" position; GRDDL was based on the head/@profile extensibility

Larry: W3C should charter a group on Metadate .... how to add Metadata to HTML

DC: Talks about GRDDL as an example

Tim: Are people using GRDDL?

<johnk> DC: notes that GRDDL extensibility is achieved by use of the HTML profile attribute

JAR: There are (this is irrelevant) XSLT that parse RDF/XML and produces triples

DC: Community not supporive of my suggestions on extensibility

Tim: Talk about problem with cut/paste of NS-based markup

<Zakim> timbl, you wanted to say that to have a de-prefixed from for cut and paste woul dbe reasonable.. this works with attributavalues abut not alas with element names. You can for

Tim: Are there oher reasons why people do not like Namespaces

Noah: We need an Action

<timbl> More generally, to get more arcs in a motivation graph to elaborate what is on the whiteboard.

<DanC_lap> timbl, another rationale behind the the "no URI prefix" position is: what happens when you mutate the DOM?

Larry: The HTML WG has pointed out a flaw in XML and we should puch back on XML's syntax on Namespaces
... TAG could encourage re-examination of Namespaces

<Zakim> noahm, you wanted to try and focus discussion and to talk about exploring namespaces

Noah: Some sympathy but efforts like that may fail
... suggests some TAG action
... Should TAG analyze the situation?

Larry: The TAG could endorse ongoing work outside and encourage a W3C activity to look into revising Namespaces

HT: What is the flaw in XML which HTML has called attention to?

<timbl> DanClap, re "no uri prefix" a reasonable position is that the prefix is just a shorthand, and the DOM is the data model, so the DOM should have the full URI. (Like the RDF model does). It is then a serialization option as o whether you se a prefix shorthand.

Noah: Problems with Namespaces ... cut and paste problems, typing stuff with namespaces turns out to be harder than typing stuff without

<Zakim> ht, you wanted to ask LM to expand on "HTML requirements" for XML namespace design

DC: DOM modifications

JK: Sympathetic to Larry's proposal but we need to do our homework. We should speak to people at Balisage.

Noah: Tries to clarify proposals

HT: We misunderstood Larry use of the word "endorse".

Noah: We need to do homework first

Tim: Reminded of Cambridge Communique time

Noah: Need specific actions

Larry: We could ask XML Core to do some homework

HT: This would require a charter change

Noah: Worries about skill set. Needs knowledge of use of Namespaces in different contexts

HT: Flaws in XML are not addressed by any of these proposals

<johnk> HT: I heard two proposals - i) propose changes to XML Core ii) bring together HTML and XML folks to make a namespace proposal acceptable to both

HT: Requirements did not have anything to do with HTML

Larry: HTML WG found that current XML infoset serialization is too difficult for them.
... we should examine what infoset would meet their needs and also allow distributed extensibility

<masinter> there is precedent for W3C working on alternative serializations of XML

Larry: This is not a short-term comment to HTML WG. There is some long-term work that W3C should take up to prevent communities from forking off

<masinter> this isn't the 'solution', but I am very concerned about W3C endorsing two separate forks of HTML on the one hand and XML on the other, and that perhaps this is 'research', but that the TAG should lead effort toward convergence

<masinter> i don't want the default answer to be "oh well, i guess they're different, let's just leave them going off in different directions"

Tim: XML Model, HTML model and RDF model is a triangle. Trying to harmonize may be a mistake. Should be arms-lenghth relationship
... Narrow the scope to attribute values, not attribute or element names

Noah: Please type possible actions into IRC log

<johnk> I am suggesting that I talk to those who went to Balisage, and ask what was discussed regarding the namespace-focused work there, and report back to TAG

<timbl> In other words like microdata and RDFa, use the *ML DOM as it is and putthings in the attribute values.

<DanC_lap> maybe invite advocates of a few of the positions tbl put on the board (see "blobs" above) to a TAG meeting to discuss them.

<timbl> +1 to JohnK anyway

<masinter> i suggest johnk also float the idea of further work specifically on this, and that we ask also HT to explore the questions with XMLCore

<masinter> i suggest the tag also put out a position that we would like to see work in this area

<noahm> Larry offers to take action to draft message that the TAG will endorse

<masinter> possibility of coming up with a new serialization of infoset, which would be acceptable to HTML community, please explore

HT: Larry phrased a new serialzation of the Infoset . I can ask XMLCore. Asking them to chamge XML would be much more contentious

<masinter> "please ask the XMLCore group what in the area of discovering and meeting HTML's requirements they would be willing to do, and what prerequisites they would have for doing it"

<masinter> i propose Henry do what I just typed

Noah: Will you take an action to come back to TAG with a proposal for whether and how TAG should interact with XML Core re. Infoset serialization

HT: I don't know what HTML's requirements are

Tim: Too vague ....

HT: I will think about that

<johnk> ACTION: John to talk to Balisage participants about XML namespace work, discuss TAG interest in this area, and summarize [recorded in http://www.w3.org/2009/09/25-tagmem-irc]

<trackbot> Created ACTION-313 - Talk to Balisage participants about XML namespace work, discuss TAG interest in this area, and summarize [on John Kemp - due 2009-10-02].

DC: Any volunteers to get the concerned players together?

JK: I can ask the Balisage players

<johnk> DC: That's not who I meant

HT: No, the players for the consitituencies on the board

Suggestions - invite Ben Adida, Manu

Larry: Possibility of meeting at TPAC?

BREAK for LUNCH

Reconvene at 1:15 PM

<jar> scribe: Jonathan Rees

<jar> scribenick: jar

dan does wed cleanup

ht does thu cleanup

jar does fri minutes cleanup

noah will collate / link all minutes

Reconvening.

<ht> TV, dial in to discuss next meeting, please?

<ht> Raman?

<ht> T.V.?

<timbl> People in the room wave to Raman.

noah: admin review. note, membership is turning over a bit

ht: All please think about who should stand for membership

TAG admin (TPAC logistics, future meetings)

noah: Future meetings: TPAC and Dec 8-10

Dec 8-10 will be at MIT again

<DanC_lap> (anybody want to offer, here in IRC, to host a meeting? at least tentatively?)

After that: An idea: co-locate TAG and IETF, Anaheim, March ?

AC meeting is at MIT Mar 21-23

Mar 21-23 is Sun-Tue. LM proposes TAG just before that

scribe: more discussion of meeting planning ...

Noah: MIT Mar 17-19 ?

ashok: too early to tell

(no one is saying they can't make that)

Passed - subject to possible future modification - but for now let's plan on MIT Mar 17-19

RESOLUTION: TAG F2F, MIT, Mar 17-19

<scribe> ACTION: noah Check with Amy on room availability and suggest to Ian that he mention this meeting in TAG election call for nominations [recorded in http://www.w3.org/2009/09/25-tagmem-irc]

<trackbot> Created ACTION-314 - Check with Amy on room availability and suggest to Ian that he mention this meeting in TAG election call for nominations [on Noah Mendelsohn - due 2009-10-02].

<noahm> Who will be @ TPAC?

<noahm> Henry, Dan, Ashok, Larry

<noahm> TPAC regrets: John and Jonathan and Tim

noahm: We will meet Mon am, Fri am; available to meet with other WGs at other times

noah: We used to have TAG progress reports, that stopped at some point, any interest now? (probably not)
... Any WGs we want to reach out to?
... The meeting at plenary in France was really good

<scribe> ACTION: DanC to follow up on best plan for HTML / TPAC [recorded in http://www.w3.org/2009/09/25-tagmem-irc]

<trackbot> Created ACTION-315 - Follow up on best plan for HTML / TPAC [on Dan Connolly - due 2009-10-02].

<amy> i confirm I've reserved space for 17 March in G449 (Kiva); 18 March in room 346 (Kiva and Star were not available) and on 19 March in G449 (Kiva)

<ht> Amy ++

DanC: Re ECMA, Sam suggested Friday, but there was a conflict

noah: Meet separately with ECMA folks?

lm: primary discussion around ecma is around process, as much around technical work. we can make ourselves available of course

action-310

<DanC_> action-310?

<trackbot> ACTION-310 -- Noah Mendelsohn to check with Sam Ruby on ECMA/W3C activities at TPAC -- due 2009-10-01 -- OPEN

<trackbot> http://www.w3.org/2001/tag/group/track/actions/310

TAG priorities

sort actions by owner

<DanC_> action-116?

<trackbot> ACTION-116 -- Tim Berners-Lee to align the tabulator internal vocabulary with the vocabulary in the rules http://esw.w3.org/topic/AwwswDboothsRules, getting changes to either as needed. -- due 2009-08-01 -- OPEN

<trackbot> http://www.w3.org/2001/tag/group/track/actions/116

<DanC_> action-116 due 1 Dec

<trackbot> ACTION-116 Align the tabulator internal vocabulary with the vocabulary in the rules http://esw.w3.org/topic/AwwswDboothsRules, getting changes to either as needed. due date now 1 Dec

Timbl: It's good to be reminded of it

<DanC_> close action-24

<trackbot> ACTION-24 clarify http://www.w3.org/2003/04/iri , perhaps by using N3 closed

timbl: (refers to new IRI spec drafts)

<DanC_> action-24: withdrawn in Cambridge. TBL suggests LMM consider stuff in this area

<trackbot> ACTION-24 clarify http://www.w3.org/2003/04/iri , perhaps by using N3 notes added

lm: The new drafts should not influence whatever action is implied by this action item

timbl: Would like to drop it.

<DanC_> close action-24

<trackbot> ACTION-24 clarify http://www.w3.org/2003/04/iri , perhaps by using N3 closed

Dan's actions:

ACTION-307?

<trackbot> ACTION-307 -- Dan Connolly to raise issue of work items moving between W3C working groups and also with IETF -- due 2009-09-30 -- OPEN

<trackbot> http://www.w3.org/2001/tag/group/track/actions/307

lm: This is a process issue, I don't think it's finished
... Hypertext coordination group might take this on?

danc: If I don't get this done today I don't want to carry it

action-299?

<trackbot> ACTION-299 -- Dan Connolly to notify the TAG when the HTML WG gets closer to closing issue-4 html-versioning -- due 2009-09-10 -- OPEN

<trackbot> http://www.w3.org/2001/tag/group/track/actions/299

<DanC_> action-299 due 15 Oct

<trackbot> ACTION-299 Notify the TAG when the HTML WG gets closer to closing issue-4 html-versioning due date now 15 Oct

action-295

action-295 due is 1 week

<trackbot> ACTION-295 Monitor geolocation response to IETF GEOPRIV comments on last call and report to the TAG due date now is 1 week

danc: Discussion is out of order
... of the actions that is
... (Generally, not action) HTML validation software dev work that I might do

(danc was addressing JAR's request to hear from everyone re tag work they planned for this fall)

action-308?

<trackbot> ACTION-308 -- John Kemp to propose updates to Authoritative Metadata and Self-Describing Web to acknowledge the reality of sniffing, due 2009-10-20 -- due 2009-10-01 -- OPEN

<trackbot> http://www.w3.org/2001/tag/group/track/actions/308

action-308 due 20 october

<trackbot> ACTION-308 Propose updates to Authoritative Metadata and Self-Describing Web to acknowledge the reality of sniffing, due 2009-10-20 due date now 20 october

lm: i don't like this action. you should refuse to do it

danc: Out of order

action-313?

<trackbot> ACTION-313 -- John Kemp to talk to Balisage participants about XML namespace work, discuss TAG interest in this area, and summarize -- due 2009-10-02 -- OPEN

<trackbot> http://www.w3.org/2001/tag/group/track/actions/313

action-313 due 20 october

<trackbot> ACTION-313 Talk to Balisage participants about XML namespace work, discuss TAG interest in this area, and summarize due date now 20 october

<DanC_> action-313 due 20 Oct

<trackbot> ACTION-313 Talk to Balisage participants about XML namespace work, discuss TAG interest in this area, and summarize due date now 20 Oct

action-281?

<trackbot> ACTION-281 -- Ashok Malhotra to keep an eye on progress of link header draft, report to TAG, warn us of problems (ISSUE-62) -- due 2009-10-30 -- OPEN

<trackbot> http://www.w3.org/2001/tag/group/track/actions/281

ashok: ongoing

action-304?

<trackbot> ACTION-304 -- Larry Masinter to draft summary of the larger issue -- due 2009-09-30 -- OPEN

<trackbot> http://www.w3.org/2001/tag/group/track/actions/304

noah: This is worth pursuing; need to look at minutes to see what it's about

johnk: This was about the references in the HTML spec. HT had one action, LM suggested there was a larger issue around references

action-304 due in one week

<trackbot> ACTION-304 Draft summary of the larger issue due date now in one week

johnk: What the web platform looks like.

lm: I remember - I was going to add it to the versioning document

<noahm> action-304?

<trackbot> ACTION-304 -- Larry Masinter to larger around Web Platform Definition regarding references in HTML 5 document -- due 2009-09-30 -- OPEN

<trackbot> http://www.w3.org/2001/tag/group/track/actions/304

<masinter> regarding the definition of the 'web platform' with regard to specs defined in the HTML5 document

action-action-306?

action-306?

<trackbot> ACTION-306 -- Larry Masinter to work with JK and AM to update Web APplication architecture outline based on discussions at TAG meetings -- due 2009-09-30 -- OPEN

<trackbot> http://www.w3.org/2001/tag/group/track/actions/306

<masinter> the general idea is that the web platform consists of a set of interfaces, HTML, DOM, URI, RDF, images, etc., and that an overall spec defining the platform should then make reference to versionless versions of specs and alternatives

close action-306

<trackbot> ACTION-306 Work with JK and AM to update Web APplication architecture outline based on discussions at TAG meetings closed

reopen action-306

<trackbot> ACTION-306 Work with JK and AM to update Web APplication architecture outline based on discussions at TAG meetings re-opened

ashok: Let's meet at the end of next month

<DanC_> action-306: this is a follow-on action

<trackbot> ACTION-306 Work with JK and AM to update Web APplication architecture outline based on discussions at TAG meetings notes added

<DanC_> action-306?

noah: Please annotate the action in tracker?

<trackbot> ACTION-306 -- Larry Masinter to work with JK and AM to update Web APplication architecture outline based on discussions at TAG meetings -- due 2009-09-30 -- OPEN

<trackbot> http://www.w3.org/2001/tag/group/track/actions/306

action-311?

<trackbot> ACTION-311 -- Noah Mendelsohn to schedule discussion of a persistent domain name policy promotion -- due 2009-10-01 -- OPEN

<trackbot> http://www.w3.org/2001/tag/group/track/actions/311

ht: This was to follow up on Tim's plea to do something about persistence of w3.org or persistent domains generally

[well that's not exactly what henry said.]

<DanC_> action-311: tbl notes http://www.w3.org/DesignIssues/PersistentDomains

<trackbot> ACTION-311 Schedule discussion of a persistent domain name policy promotion notes added

action-285 due in 2 weeks

<trackbot> ACTION-285 Make sure TPAC logistics are straight due date now in 2 weeks

<DanC_> action-285?

<trackbot> ACTION-285 -- Noah Mendelsohn to make sure TPAC logistics are straight -- due 2009-09-25 -- OPEN

<trackbot> http://www.w3.org/2001/tag/group/track/actions/285

action-292?

<trackbot> ACTION-292 -- Noah Mendelsohn to alert group to review HTML Authoring Drafts [trivial] [self-assigned] -- due 2009-10-13 -- OPEN

<trackbot> http://www.w3.org/2001/tag/group/track/actions/292

noah will schedule discussion on this

action-284?

<trackbot> ACTION-284 -- Jonathan Rees to flesh out the Web Application ( http://www.w3.org/2001/tag/2009/06/webAppsTOC.html ) outline with as many sentences as he can -- due 2009-09-15 -- OPEN

<trackbot> http://www.w3.org/2001/tag/group/track/actions/284

<DanC_> ACTION-292: LMM notes Mike Smith's HTML spec is relevant

<trackbot> ACTION-292 Alert group to review HTML Authoring Drafts [trivial] [self-assigned] notes added

close action-284

<trackbot> ACTION-284 Flesh out the Web Application ( http://www.w3.org/2001/tag/2009/06/webAppsTOC.html ) outline with as many sentences as he can closed

awwsw is talking about tag dec f2f as a 'delivery date'

action-312 due 1 december

<trackbot> ACTION-312 Find a path thru the specs that I think contradicts Dan's reading of webarch due date now 1 december

action-312 due in one week

<trackbot> ACTION-312 Find a path thru the specs that I think contradicts Dan's reading of webarch due date now in one week

action-201 due on 1 december

<trackbot> ACTION-201 Report on status of AWWSW discussions due date now on 1 december

action-278 due 15 october

<trackbot> ACTION-278 Draft changes to 2.7 of Metadata in URIs to cover the "Google Calendar" case due date now 15 october

<DanC_> action-282: jar says this is his project for the fall

<trackbot> ACTION-282 Draft a finding on metadata architecture. notes added

action-33 due 15 october

<trackbot> ACTION-33 revise naming challenges story in response to Dec 2008 F2F discussion due date now 15 october

<DanC_> (larry, is there a draft of HTTPbis which has advice on conneg?)

action-232 due in 4 days

<trackbot> ACTION-232 Follow-up to Hausenblas once there's a draft of HTTPbis which has advice on conneg due date now in 4 days

<masinter> (DanC, my proposed revision hasn't been incorporated yet)

<DanC_> (tx)

action-232 due on 29 september

<trackbot> ACTION-232 Follow-up to Hausenblas once there's a draft of HTTPbis which has advice on conneg due date now on 29 september

<masinter> danc http://lists.w3.org/Archives/Public/ietf-http-wg/2009JulSep/0792.html

action-163 due 31 october

<trackbot> ACTION-163 Coordinate with Ted to build a sample catalog due date now 31 october

discussion of action-295

noah: Back to the spreadsheet

http://www.w3.org/2001/tag/2009/09/HTMLIssues.xls

HTML issue: text/html mime type

<masinter> http://tools.ietf.org/html/rfc2854

lm: RFC2854 is current definition of text/html. written by lm and danc
... history ... mime types are allocated by IETF. Registration at top level requires IETF consensus
... you designate a change controller. for text/html, it's W3C
... I assume that means rec, not a WG last call

<DanC_> http://www.ietf.org/rfc/rfc2854.txt The 'text/html' Media Type

lm: The proposal in HTML5 is to replace registration with something *not* including any history [background]
... anything you 'should' need to know is contained in the rec, anything else is a bug

noah: What is typical?

danc: There be dragons

lm: It's typical to include history, making updates less of an issue
... One reason given is to revoke the permission to serve XML-expressed HTML as text/html

noah: Breaks our agendas and minutes?

danc: Probably not, since they match the syntax and semantics of HTML5

timbl: The notion that there is an XML language that is an HTML language is important as a matter of principle
... and that you can serve it as text/html

noah: The new spec correctly interprets [XHTML] content

lm: (no...)

noah: You shouldn't take stuff that's widely deployed and break it

danc: Depends on what you consider 'widely deployed'

lm: Purpose of mime type is give an out of band description of what the sender intended
... It's not normative, it indicates intent

noah: Self-describing web has a story about answering the question "did so and so serve a document x that can be interpreted according to such and such interpretation rules" (jar's paraphrase)

lm: E.g. the profile attribute of head isn't in html5.

Receiver has no clue what the sender might have meant by a profile attribute.

If the mime type registration doesn't give history, receiver doesn't have a chance.

danc: There is some former-features explanation

timbl: Safest thing to do might be to make a historical RFC...

(someone:) how would that help follow your nose?

ht: At the moment we have hearsay, can we have some references? Nothing in the July draft that looks like a mime type registration... up to date reference?

<DanC_> http://dev.w3.org/html5/spec/Overview.html#iana-considerations

<DanC_> 12.1 text/html

<ht> What's the issue number for discussion of this?

[scribe notes that this is not a dated file. may change]

timbl: Bold and emphasized text - that must be a funny story

ht: You're now no longer allowed to serve some xml with this label. The question is whether reinterpreting as html changes the document in any visible way

<masinter> there were 5 different specifications and languages and mulitiple implementations that the previous RFC made reference to... these languages were more or less coherent and correlated. Writing the history of each element piece by piece is not the same

danc: table with tr right underneath it - tbody gets implicitly added by html at parse time - so different dom

<DanC_> (hmm... looking for a historical explanation of head/@profile, I don't see that, but I see "must not be used by authors" with what to do instead; it says "unnecessary; omit it altogether, and register the names.")

lm: there used to be many html versions... the fact that someone might meant one of those is lost when you chop it up feature by feature. you lose the sense that someone was using a particular dialect (language version).
... The intent is to outlaw declarations that a document is HTML 4 (etc)
... Rewriting history is absurd. That's what I think the TAG response should be

ht: Is there any precedent for this? Has something like this happened before?

<ht> ACTION: Henry S. to draft for tag@w3.org proposed TAG feedback on the text/html media type registration in the 25 September draft of HTML5 [recorded in http://www.w3.org/2009/09/25-tagmem-irc]

<trackbot> Created ACTION-316 - S. to draft for tag@w3.org proposed TAG feedback on the text/html media type registration in the 25 September draft of HTML5 [on Henry S. Thompson - due 2009-10-02].

<masinter> http://lists.w3.org/Archives/Public/public-html/2009Aug/1184.html

<masinter> ... The main thing that needs updating is the removal of the permission for sending syntactic profiles of XML as text/html. In addition, the encoding considerations, fragment identifier definition, and the text about recognising HTML documents are somewhat out of date and can be significantly improved by referencing HTML5 now. RFC2854 is quite vague in a number of areas, also, which can be cleaned up with an update.

Geolocation/Geopriv

Thomas Roessler is joining us.

<noahm> The chair thanks Thomas Roessler for joining us on short notice.

lm: I'm interested in current status. I met with Yves in Stockhom, area directors, what is the response from IETF and Cisco and CDT?

tr: I'm not the team contact, this info may be outdated...
... Comment was sent by IETF chair
... "We are working on the comments, something will be given"
... AFAIK they just haven't answered yet

<DanC_> http://lists.w3.org/Archives/Public/public-geolocation/2009Aug/0016.html "We're working on drafting formal responses to the Last Call comments we

<DanC_> have received.

<DanC_> Unfortunately due to vacations this has been taking a bit longer than we

<DanC_> had expected, but we will have them ready soon."

tr: There was unanimous WG sentiment against taking up geopriv.

noah: Rationale?

<tr> [On reviewing the scribe's record, following, of what TR said: 'I wonder whether it's best to just keep this as "summary of WG discussion and comments"; as scribed, it isn't all completely accurate.']

tr: There are several variants of similar but distinct requests.
... To interoperability of geopriv and geolocation: The geolocation API is straightforward and simple. Geopriv is big and complex. I don't know the implementation status of geopriv.
... One level up: could there be geopriv-like functionality included in geoloc? Along with location data, one could pass two pieces of policy info: one is how long data can be retained, the other is whether it can be passed on to third parties.
... Extra parameter on the callback.
... Burden is on the UI writer to produce all those parameters.
... Compare range of examples: Google latitude, which is privacy invasive, and geotagging photos. It's a serious burden to come up with an API that works for all these applications.
... The implementor doesn't have anything to do with the downstream processing, e.g. the UIs for controlling privacy.

TimBL: Is there any precedent [for handling policy information]? P3P was not successful.

tr: CDT says, the server should talk to the user to get preferences, then convey to the browser.
... Here [Geopriv?]: user's wishes are articulated to browser and forwarded to site. I'm not aware where this has been done successfully.
... Not sure CDT's policy argument holds water. It's more a policy argument than a technical one.
... The question is whether, if you attach this information to the data, will that lead to improved privacy control for users? Personally, this is unconvincing.
... Reason: The site is actually talking to the user. Domains of control. The boundary where I have control is between the user-facing part of the browser (can get geolocation), and the web app, parts of which run on server and parts on client. But I don't have architectural control over where a dataflow occurs (i.e. (a) *within* the distributed web app, or (b) out of that webapp down the road).

TimBL: The app *knows* how the info is being used.

tr: Server and javascript are a single domain of control. User has set some kind of parameter in the browser. Things happen, either on server, or client, we don't care.
... Two cases:
... 1. Benevelont - we've seen this stuff, may we pass it on? We have achieved nothing by adding the policy tag to the geoloc information.
... 2. Not benevolent - the policy info will be disregarded anyhow.
... The geoloc default is: Throw the data away when you're done with the task, don't retransmit to third parties.

<johnk> DanC: I agree with this: Most well-intentioned sites,

<johnk> and _all_ evil sites (the ones where privacy leakage is an issue in the

<johnk> first place) would just ignore the user's requests

<johnk> (and evil sites can just put their own code in there to ensure that the user's information _is_ leaked)

TimBL: Will it [geolocation] catch on? Will people use it the right way? Looked like geopriv wasn't useless, it looked like cookies to me.

tr: You're saying browser-authored policy? I don't see the benefit.

TimBL: (1) It lets someone set a default in the browser. (2) If the parameter has to be passed around, it will be harder for people to do the wrong thing.

TR: I don't think either of those. We will probably see an outcry about bad implementations... we'll see more (installed) apps that play fast and loose with geoloc...

TimBL: The violation will be clear. If app X does the wrong thing, Apple will remove it from the store.

tr: The question is whether the browser-authored policy adds much actual accountability to web applications and implementors.
... There is no dispute that the browser should ask the user if it's OK to pass on location information, with attention to caching and so on. The distinction is whether along with the location info, after user has said yes, the policy info travels along with it. How deployable is a version of the spec with geopriv going to be?

lm: Hackles. Don't like venue shopping. That's the main thing. Don't want the system gamed.

dc: CDT and Cisco are WG members. There have not been formal objections.

TimBL: WG members can't make last call comments.

dc: A decision over someone's objection...
... How much more significant can you get than the IETF chair sending a 6 page letter...

ashok: No, by "significant" I meant to users...

tr: This *cannot* turn into a dispute between the organizations - must be a dispute between WGs. If there were a disagreement on what an IRI is, or on what a public policy should be, that would be an organizational issue. But this isn't such a case.

ashok: Noah, are you asking that there be a hook, where you can add policy?

noah: Yes, but with a twist, ... (?) ... outside organizations may add new members, etc.
... We could say this geoloc stuff is fine. But how about policy mix and match.

dan offered suggestion - see minutes (drop action)

lm: We can show more leadership. Encourage web app developers to do the right thing. We should encourage more w3c work to satisfy the requirements.

tr: More general problem, how do we tie policy and access control together, is going to be a significant headache in device APIs work

noah: Much broader problem that goes beyond geoprivs. Is that a line of inquiry for the TAG.

lm: Or for the security domain. Should it be in the charter of the device APIs WG to work out policy issues, or should it be [higher up]?

tr: Formerly one group is working on the policy issues; the 2 groups were combined (Device APIs). This was a way of getting the attention.

<DanC_> suggestion: we've looked at the technical issues and a little bit of the policy issues, and come to the conclusion that there are several coherent designs and none of them critically in conflict with web architecture. Maybe let's action somebody to take the remaining liaison/process issues to the IETF/W3C liaison forum or something.

<DanC_> (re orthogonality... the device API WG seems likely to persue that approach)

<johnk> such as http://www.w3.org/2009/policy-ws/cfp.html ?

<johnk> http://www.w3.org/2008/security-ws/report#PolicyDescription

Adjourned until next time.

Summary of Action Items

[NEW] ACTION: DanC to follow up on best plan for HTML / TPAC [recorded in http://www.w3.org/2009/09/25-tagmem-irc]
[NEW] ACTION: Henry S. to draft for tag@w3.org proposed TAG feedback on the text/html media type registration in the 25 September draft of HTML5 [recorded in http://www.w3.org/2009/09/25-tagmem-irc]
[NEW] ACTION: John to talk to Balisage participants about XML namespace work, discuss TAG interest in this area, and summarize [recorded in http://www.w3.org/2009/09/25-tagmem-irc]
[NEW] ACTION: noah Check with Amy on room availability and suggest to Ian that he mention this meeting in TAG election call for nominations [recorded in http://www.w3.org/2009/09/25-tagmem-irc]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.133 (CVS log)
$Date: 2010/01/06 22:19:09 $