See also: IRC log
<masinter> scribenick: masinter
<scribe> scribe: Larry Masinter
<trackbot> ISSUE-25 -- What to say in defense of principle that deep linking is not an illegal act? -- open
Jeni: most controversial: indicate where the adoption of particular legal positions could have an impact on the use of the web
Noah: The term "back up" in "...to back up any restrictions..." ...
JeniT: read "reinforce"
Jeni: I haven't updated the text much to do things I think should be done...
... I would like to get agreement on contentious bits, whether we should say these things at all
DKA: We should talk about next steps... get consensus
Jeni: Let's go through the document on 'what is publishing on the web' and terminology (not fleshed out) and then some technical stuff on mechanisms (review by email). Let's go through first section piece-by-piece.
... First bit about 'hosting'
... the people put information on the web not necessarily the same as those who own the hardware or who provide the software
... Some of them automatically do things to the content. That's important because there is some legal wording around not allowing ISPs to perform 'transformations', but technically that is hard.
((discussion of UK and France laws around illegal content))
TimBL: I thought the distinction should be more like whether they perform editing
<noah> LMM: If legal community is using terms like hosting, transformation, etc., we could profitably define some of those in a document as a service to the community.
<noah> Isn't that already a stated goal of this document?
Larry: I"m not saying we should follow the legal opinion but we should look up the definitions used
<jar> dka: Let's not rathole
<noah> NOAH: We should mainly define terms as used in the technical community, but we should point out cases where we observe that confusingly different terminology or definitions are used by others.
noah: on cross-border we should point out how the terms are used in the community or on the web
Jeni: Section 1.1 has two bits on hosting:
Ashok: if our definitions are different from what the legal community use
<noah> LMM: Suggest a section, to be filled in, that explains where legal community uses terminology differently than we do in the rest of this document.
<noah> (I think Larry is proposing exactly what I proposed above)
TimBL: (discussing difference between ownership -- IPR -- separate from hosting )
... for online content, if you 'host' something do you 'possess' it?
... difficulty with use of 'possession'
<DKA> trackbot, start meeting
<trackbot> Date: 08 June 2011
Noah: equating 'hosting' with 'possession' leads to difficulty
<timbl> What Tim said was: The term 'posession' for physical artifacts combines aspect of ownership (as in property) and access to and control over -- but no such concept with these 3 wrapped up applies online.
noah: The organization of the document is surprising; you used a 'hote' for something that is really intended not as side commentary. editorially .... make the things now in notes into a separate section
<jar> Stallman says there is no such thing as "intellectual property"... meaning that you cannot possess bits, you can only possess a physical device that carries some bits. Copyright doesn't cover ownership, it covers copying and performing.
Jeni: I put them in notes because I wasn't sure we wanted them in there.
<timbl> Maybe it would be good say that some things are done by automatic agents, which are set up for various parties benefit but themselves cannot themselves be held responsible for the legality of the way they are used. These include transmission systems and routers, proxies, and also automatic format transfoamtion services and image re-rendering service, spell-checkers etc etc etc.
jar: The key idea is 'who is responsible for what'
TimBL: poeple who set up agents, format translation, spell checkers, image downsamplers, .... are not responsible for the content that those are used for.
ht: I like the note and think it should be upgraded, but point 2 is a tautology
... you should tell me things like 'things that are fundamental to their operation are at risk'
<jar> [ht is referring to 2nd bullet in note at end of 1.1]
Jeni: would it help with these to have the pithy 'this is the thing' first
<noah> Legislation that forbade transformations on illegal material would similarly limit the services that service providers could provide that are of value for legal purposes.
TimBL: while it would be great to have a list of automated agents as examples, it is important that, because this list changes all the time any laws should make the point in general about any automated systems like those, not the specific ones.
ashok: when you speak about transformations, you also include censorship
... censorship can be helpful in that it excludes bad words and then makes bad words acceptable
Jeni: is it useful to put in examples?
Noah: we should be particularly aware of international different concerns
<Ashok> Yes, examples would be great!
<noah> LMM: Thinking about longevity of this document, and its applicability over time. I'd like to see it put it into section. I'd like a section on stuff that's happened (or might happen) that's bad. E.g. hosting equated with posession and ... (explain what bad happened)
<noah> LMM: Then there are TAG recommendations on best practices. The terminology will stand; the examples are current
<noah> LMM: (scribe's not sure where that point was going) I like the Street View example.
<noah> LMM: Part of my question is "who is the audience for this document?" Just the legal community, or also ISPs?
<noah> LMM: So, I'm resisting wording suggesting what good laws would be, what the impact would be of laws, etc.
<noah> DKA: Genesis of this document was to service legal community's needs. Are you pushing back on that?
<jar> lmm's specific organization suggestion: 1. terminology 2. examples 3. recommended best practice
<noah> LMM: No, but rearrangement would help. Don't like the "if you were to do this it would be bad" should be "this happened, and it was bad"
<noah> LMM: Too speculative.
the wording sounds too speculative
terminology + organization
noah: I wouldn't go as far as Larry, in a document like this we should be careful how we shouldn't be to cautious
Jeni: Section 1.2 is around copying and distributing: 4 kinds of reasons why you copy data, with a summary and some points around that.
<noah> noah: I wouldn't go as far as Larry in being retrospective only. In some cases, it's very useful to say "we see certain policies being considered, we can explain the likely practical consequences to the Web"
<LMM> (example of terminology source http://www.amazon.com/ISP-Survival-Guide-Strategies-Competitive/dp/0471314994)
noah: 1.2 I had to read this 2-3 times to understand
... there is a formal distinction between hosting "HOSTED OWNED CONTROLLED" by an 'origin server'. The intent here is fine but the presentation is unclear. Introduce the simple case and then add the complexity
... "it is usually impossible to tell" ... when? from just one perspective, not 'from a subpoena' ... in simple ways be more careful about stuff like that
DKA: we want to make sure this document is readable to non-technical people, perhaps a diagram would be useful?
(not sure 'non-technical' is the right audience)
<timbl> (Why we ended up with "origin server" instead of "original server" I don;t know)
('original' was updated with a new version, so it's not the original www.w3.org which used to be hosted at CERN etc.)
jar: talk about libraries?
noah: backup strategies might also make copies....
TimBL: backing up in the cloud ....
jar: I think it's worth talking about libraries... there is a special exception for them, that says libraries are allowed to make backups
Yves: do they have the right to own illegal content
<Larry> (historical note http://en.wikipedia.org/wiki/The_Name_of_the_Rose)
Yves: libraries may be able to hold on to illegal material even if they can't distribute it
Jeni: 1.2.3 Search engines
... 1.2.4 Reusing .... that's the bits you're after, if you're trying to prevent something.
DKA: you don't talk about 'fair use', and has different names
noah: I'd understand this if the terms lined up, and that we can clarify
... we have technical terms about transformation and storing and only indirectly allowed
... That is for the lawyers to do.... (examples about copying and Xerox machines)
larry: i'd suggest going through one more round and issue a FPWD
DKA: we should have Tinh back on and get his feedback on a call
... then we go to a more general community
Jeni: and Rigo .... and Casey (privacy council)
... get a legal review
jar: what Tinh said ... if this is a TAG finding, it will have some impact, but if it is Req track that would have broader review....
... it would have much broader impact
the people Tinh have in mind are judges, legislators, constituents, .... try to get EFF review
Noah: I do want to be careful about how we handle it
<jar> What the legal community will care about is whether the document has had wide review within the technical community. Rec track is W3C's usual way of getting wide review.
larry: encourage Jeni to make another editorial pass, get individual review, and then we'll mkae one more pass at the meeting, and then go to FPWD
DKA: I tried to pull out section 1.5 with linking as a speech act. Essentially the idea is to conceptually put together linking with speech act, and put this into free speech
... freedom of expresion ... we htink linking is a kind of expression
larry: UN declaration last week on Internet
TimBL: there was a site that was taking down, who embedded video links
... drawing this lines is something the TAG could do
... cases where linking was aiding and abetting the crime
Jeni: linking to something is like speaking about something. Some cases there are are laws against some kind of speech ....
HT: suppose we agree as we have said many times that URIs are something like names. I'm not aware of any limitations on naming things, just ....
DKA: if you just had a list of links... and the combination of that list was, by itself, inciting violence
<ht> I really like the freedom of expression line
<ht> I am somewhat skeptical of the "subject to the same kind of constraints as any other kind of expression"
larry: We sometimes talk about the TAG saying things in this document, we should try to be careful that the TAG is editing this document but we're trying to capture community consensus
TimBL: you can say 'get your Free TV here', you're inciting people. If you say "here is how you can find out how ot make a bimb"
ht: A catalog of shops that used to sell the anarchist's cookbook isn't illegal even if the book itself is
timbl: when it comes to copyright, linking is fundamental, but when it comes to racial hate words might not be illegal
yves: we have laws in French about intent, indications of crime... is the link an invitation to follow the link... talking about what is legal or what is not legal
noah: one area that would be helpful to point out, there are different kind of links.... the visible rendering of the link where what is visible ...
((DKA brings up important use case of linking http://www.youtube.com/watch?v=oHg5SJYRHA0 aka 'Rick Rolling'))
<jar> agree, a taxonomy of link presentations would help to tease out these issues
Noah: (( discussion of downloading pornography and case around that ))
<Zakim> ht, you wanted to mention hovertext
ht: could not find any tool that would that preserved hover text
<jar> ht: link presentation taxonomy interacts with tools (e.g. pdf combination) - taxonomy not invariant
<timbl> It may be tempting for some people to try to cast a link as more than just a reference, because it is so easy to follow -- but that is tricky as in fact if for example you give the address of an illegal brothel in plain text, in fact a phone will navigate you there.
<Yves> some tools generate links out of plain text (like MUAs)
noah: what i tried to do in the last few minutes is make a first cut on the product page for this work
((discussion of timeliness as a sucess criteria))
Ashok: I thought the goal was to help web hosting and product companies
jeni: there is an aspect to this that is about describing the technical things
jar: we want to help with their defense and prosecution
noah: I'm reluctant to delete what it says but augment it
jka: This document should be a useful tool for technical people to talk to lawyers
jar: Express the common understanding in the technical community to those who make law. That is what Thinh Nguyen said is needed and what the document does.
... In doing so we support the technical community
larry: I want the word consensus appear in the product page
... I would like the word 'consensus' to be part of the product page, our intention to build consensus, develop consensus
jar: 'make law'
((discussion of schedule, FPWD ....))
dka: we need a live legal review, don't think we can do it just by sending the document out
goal is to get legal feedback before next F2F
((discussion of agenda))
((break for 10 min))
DKA: Review "Data Minimization in Web API"
... I was part of DAP working group call, was a good call, Frederick had sent me some good feedback and also from Robin and on more on the call.... also more feedback from others...
... They felt that this was a useful document for the TAG to produce
... I redid the introduction to be more clear. I renamed the document. Started with an excerpt of a 1978 paper...
dka: further on I extract the actual requirements that the DAP working group come up with ...
... talking about how this applies to geographic location
... what does this protect us from? Good feedback from DAP working group
... Section 2: what are our recommendation? This is something I just added. With some MUST and SHOULD and MAY language
... this tries to make this more general and clear
noah: people have seen earlier versions... who read this? Going over this for the benefit of what you did?
dka: I'd like to work on the product page for this... it's a smaller document, it's very targeted
... Noah, you asked "are there good examples of where this principle has been applied and it resulted in the desirable result? " and I don't know
noah: do you agree that this might have unintended consequences?
dka: there's been enough work on this that the risk is minimal, but we need more examples, and the document now lacks that
((discussion of whether this should be req track))
((question about patent policy))
ashok: What are you thinking of oding to this?
dka: I want to add more references, get further review from a wider community....
... kind of TAG call for review
noah: tradition for findings is that we don't use a formal process, all the findings have previous versions... we send email to www-tag and other places...
jar: does this go out in weekly newsletter, it's important than it that happens
... the distinction between Finding and Req implies the kind of review we expect
<jar> ergo, the decision should be based largely on what kind of review we want
wonder if this is something we might do with IAB on privacy, covering not only APIs but also protocols
yves: tag findings are much like working group notes
noah: we never go through the W3C process
<jar> (for findings)
noah: this strikes me as being in the middle, we're just doing this for now
ashok: my reaction to this is that it is quite focused, and quite small, i would just publish this quick and get htis behind us
dka: the audience is mostly W3C people
... the date holds
yves: talking about reviews, might be a good coordination with IAB
<Zakim> masinter, you wanted to ask whether this might also apply to other data paths
dka: think that is already there in the action already
... want to work on this with IAB
noah: change the deliverables to have two parts... an informal publishing and then later a finding
dka: I would like to put out a draft finding for review ... before the next F2F sufficiently to have had some feedback com ein .... I think that means by the end of July
((discussion of schedule))
noah: DKA please edit the product page
... ... to include relevant actions and issues
ashok: there were two issues: sync with other devices, convert from other formats
... are there others?
noah: could you give more context, it seemed like there was a whole lot. There were issues with cookies, issues with permacookies. There are resources identified by URIs, there are caches on the local machine. My email might wind up on my issues.
... before you did the AJAX implementation....
timbl: Noah, is it is possible point to a piece of client-side state
noah: I believe people implement what we would view as a cache with AJAX that now loses the URI
... why is state indentified with the same URI
... When we do a finding asking we should combine cache/storage
ashok: starts with discussion of cookies, you can't control them, got to client side storage, font stuff
... I tried to find apps where they use client-side storage
noah: mobile GMail... go into airplane can continue to read & write email
jar: used to be done with gears, now available with HTML storage
noah: they're using HTML client-side storage
ashok: "Oh gosh that's a terrific app, we couldn't have done that with cookies"
noah: you go to a web site and it starts eating space... you might want to clear for privacy reasons, it wrote a megabyte in my SD card?
... this thing looks great when you work on one site, but there's denial of storage
timbl: I've had something i've wanted for a while on tracking on dependencies, program space, debian keeps track of which modules were loaded
... I want to glob them
... ((example of how some app might help him manage storage on his device))
... installation and persistent cache should be treated on the same scale
noah: Tim wants really rich version of what 'manage local storage'
timbl: things like budgets for tasks
<Zakim> JeniT, you wanted to ask about encryption of data in local storage
ashok: doesn't say anything about encryption right now, sort of orthogonal
... consider encryption
whiteboard photo: http://www.w3.org/2001/tag/2011/06/tag_whiteboard_20110608.jpg
ashok: there's a reason why people don't encrypt but i don't know
<noah> NM: Encryption is an implementation technique used to achieve certain things...the document needs to start by stating what is to be achieved (that is, what are the threats against which we are protecting)
ashok: there are all these situations where people hack the cookies, encrypting them would prevent that
jeni: ((reporting examples came back on twitter))
... permissions around local storage, EU regulation that web sites have to talk about storage on local machine and what it's used for
<Zakim> noah, you wanted to talk about agenda item
ashok: this is the list, leading toward a product page
<JeniT> Other apps from twitter were from O'Reilly, FT webapp, facebook
<JeniT> Rigo references http://code.w3.org/privacy-dashboard
<JeniT> Norm talks about http://norman.walsh.name/2011/01/18/wordclock
ashok: the idea is that W3C started in a new direction, going to this with local storage. The idea was to think about it, and say what are the questions it raises, how do we manage it, how do we use it.
noah: we need a product page
<JeniT> From @bsletten: These are all WebDB (which is WebKit-only) examples, some just tests: http://twitpic.com/58q95p
ashok: you can have lightweight clients
larry: just want you to talk about iCloud and moving everything where the truth copy is in the cloud and everything is a cache in the architecture space
<JeniT> From @bsletten: Here is a full “application”: http://htmlfive.appspot.com/static/stickies.html
<JeniT> From @bsletten: Here is an IndexedDB example: http://www.html5rocks.com/en/tutorials/indexeddb/todo/
((discussion of product page, what are goals vs. success criteria, whether 'good practices' should be a success criteria or a goal))
accept product page
<jar> The product page is here: http://www.w3.org/2001/tag/products/clientsidestate.html
<jar> Adjourned for lunch.
<jar> https://creativecommons.org/weblog/entry/27603 Creative Commons and schema.org
<JeniT> Scribenick: JeniT
<scribe> Scribe: Jeni Tennison
noah: We need a better shared understanding of what we're trying to do in the next few months and who's working on what
... there are some things where I'd like that we do better
... [talks through spreadsheet of commitments of people to products]
... we get best output if people engage and collaborate on products
... it's healthy to have some things that are quality pieces of work that we can point back to
... the product pages help us to have a shared understanding of what we're doing
... are there a small number of these that we want to make sure we do well?
... ground rules for discussion: we won't spend time on technical issues regarding each product
... we won't expand or contract scope
timbl: Are new things out of bounds?
noah: We can look at adding those when we're comfortable with these
jar: there are six people, five of whom are working at capacity
... do people need to swap focus?
... how can we encourage those who aren't doing work to do more
noah: I want to break out of people working on their own
dka: some of the things don't seem to be equivalent levels
... privacy and dnt has different scope from publishing & linking on the web, which we know we're going to do
... we need to categorise and reflect topics, which reflect work
... such as Ashok going to the privacy workshop
noah: How much of the nuance between the things can we have? Hard in a spreadsheet.
... also the Xs don't indicate the depth of work someone is doing, it's very approximate
... let's try to do this mentally (to work out which are big and small)
... I really want to make broad groupings
timbl: If these things aren't the same, where's the problem?
... what we have to do *are* quite different in scope
dka: It doesn't matter; I think the problem is to reflect the amount of time that we're spending on each topic
timbl: should people fill that out themselves?
noah: I was hoping to start with the topic areas
dka: I'd like to see those categorised
noah: if I chose the three things to give high priority to, those things would be the ones that we'd really put intensive work on
... can we do all these without compromise
timbl: we need one piece of required reading for the telcon
noah: I want people to say which ones of these topics are the high priorities
timbl: HTML5 review is something that we should do
JeniT: some of these are time critical and others aren't
timbl: one for 'urgent' and one column for 'important'
noah: HTML5 gets a time critical code of 'Yes'
... Can we do this for others?
JeniT: fragid semantics is something that has a time critical component because it impacts on other drafts
ht: we identified that as something for TPAC 2011
Yves: I will work on fragid semantics as well
dka: I didn't say I'd do anything on fragid semantics
noah: We said we were starting the task force on HTML/XML unification
ht: I don't think we are the people to take this forward
noah: Having anything active on the list costs me effort
timbl: Make a priority column
noah: I'll add numbers for priorities
timbl: What is the objective for HTML/XML unification?
noah: it was to give the community guidance on how to maximise synergy between HTML and XML
timbl: I thought that was part of HTML5 review
... there's lots of things under HTML5 review, including fragid semantics
noah: the formal HTML5 review has to finish by early August
... there are links, and some aspects that we have to dive into early on
... that's currently top priority
timbl: that includes microdata and RDFa
noah: Can I continue to ask which things should be given priority?
ht: I'd like to give mime architecture for the web priority
... and HTTP semantics
... mime architecture is important because mime registrations are coming in all the time, and the longer we delay the more we miss
noah: high means that it should be within the top 5
timbl: why HTTP semantics?
ht: I want to prioritise what we talked about yesterday
noah: that might not be there
timbl: what is the urgency there?
<trackbot> ISSUE-57 -- Mechanisms for obtaining information about the meaning of a given URI -- open
ht: it's our credibility, and because there's more linked data being published all the time
timbl: what's interesting for me is avoiding trainwrecks
jar: Add a column that captures why
[discussion on spreadsheet]
timbl: 'Finding URI definitions' important for linked data uptake & TAG credibility
... 'Fragid Semantics' is important for RDFa, which is part of our HTML5 review
... 'HTML/XML Unification' relates to HTML5 Review
noah: also we said we'd write something and we're close to shipping it
timbl: We need to schedule work to avoid the trainwrecks
noah: What about web application state? I'd like to argue for that one
JeniT: it's important and good and we're close but it's not time critical
noah: Web app state might be high priority because we're close with it
... I think the community would benefit from it
... We have to find what things fit in with the people who are working on it
dka: API minimisation and publishing and linking on the web are fairly high priority, but they're not 2s
noah: After sorting, our top priorities are HTML5 last call review, and to the bits of unification that relate to that
... to fragid semantics, web app state and Jonathan's work on URI definitions
... Have we lost anything? Are any of the rest high priorities?
ht: Let's ensure that one slot each week focus on things that aren't in the top priority list
noah: Yes, but there will be weeks where one or two things fill the call
... but we will get to the others too
... If the high priority ones aren't moving, then I'm going to get people to focus on them
... I want to cross check that people are working on the important ones
... there are roughly three groups: critical, things we intend to work on, and other random things
dka: some of these are things that we will work on when we clear the rest of the list
noah: we'll still work on some of these
dka: I don't know what 'privacy friendly web including do-not-track' is
noah: You helped make the product page for it
dka: I think privacy is an umbrella topic, that includes API minimisation etc
jar: these are things that we've decided we'll work on but we don't know exactly what we're going to do with them, this includes security and IETF
noah: I will pay attention to the product pages for these
... there might be new things that come in, and this will change
JeniT: One thing you were after was whether people needed to be moved to work on the important things
noah: OK, we're going to discuss HTML5 last call in a few minutes, and everyone will have to do something on it
... on fragid semantics we have JeniT, ht and Yves
... on web app state, we have Ashok
... I was asking ht
ht: I'd be much happier on Jonathan's papers
... if that's OK with Jonathan
noah: What's the product page for Jonathan's work?
JeniT: I volunteered on web application state
noah: 'Finding URI definitions' we have jar and ht
on fragids I have done the product page: http://www.w3.org/2001/tag/products/fragids.html
noah: Larry, the next is mime architecture for the web, which was suggested as a priority
... it's in the IETF space, what do I need to do to make it happen better?
... is the energy that it will take low?
Larry: I don't expect a lot more TAG effort on it
... I have comments on it, I have a co-editor, I'll want some review, but I don't need a lot of TAG effort on it
noah: These high priorities are things that should take time
... I'll give myself an action to schedule a telcon of how to manage this over the next few months
Larry: Do you have a column on urgency? there's also how important it is, and how much effort is needed
ht: that comes back to HTML/XML unification, where there's nothing to do in the medium term
Larry: I'm expecting to review this with Alexei at the IETF meeting, and then I'd like to get TAG review then
noah: when is that roughly?
noah: On API minimisation, would it help for someone else to help you dka?
dka: I think it's small enough that it's ok just me
noah: Last one is linking & publishing
... that has JeniT & dka
... last one is HTML/XML unification
... I've asked Norm to get back to us with a document that needs TAG review
... Thank you, that has really helped me
<Norm> Will do. Need to get the TF to give it a once over and address comments, then will send along
noah: The other thing is that Jeff has asked for 2-3 things that we have said we would commit to
... How should I respond to Jeff?
timbl: Tell him about the top 5 things
noah: Isn't he after things that he can track in 2011?
timbl: Two or more things where we've got a schedule and milestones
<noah> ACTION: Noah to draft note for Jeff Jaffe listing 5 top TAG priorities as trackable items. [recorded in http://www.w3.org/2011/06/08-tagmem-irc]
<trackbot> Created ACTION-568 - Draft note for Jeff Jaffe listing 5 top TAG priorities as trackable items. [on Noah Mendelsohn - due 2011-06-15].
ashok: He also wanted a list of stuff that he should be looking out for
noah: I took an action to figure out by fall how to respond to that
... OK, that ends this session
noah: We've decided to meet in Edinburgh in September
... are there any objections or anyone who can't attend?
[no one objects]
noah: what about the meeting afterwards?
... should it be in California in the winter
[preference and diary discussions]
noah: 4-6th January 2012?
... any strong preference between Cambridge & CA
... slight preference for Cambridge
<Yves> IETF is March 25-30, 2012 in Paris
<noah> RESOLUTION: The TAG will meet in Cambridge, MA 4-6 January 2012
<noah> ACTION: Noah to check with Peter on January TAG date [recorded in http://www.w3.org/2011/06/08-tagmem-irc]
<trackbot> Created ACTION-569 - Check with Peter on January TAG date [on Noah Mendelsohn - due 2011-06-15].
<noah> ACTION: Noah to inform Amy of January TAG date [recorded in http://www.w3.org/2011/06/08-tagmem-irc]
<trackbot> Created ACTION-570 - Inform Amy of January TAG date [on Noah Mendelsohn - due 2011-06-15].
<noah> RESOLVED: TAG members will hold 2-4 April 2012 for TAG meeting in Sophia Antipolis, France. The meeting is not yet confirmed. It's in order to ask for changes.
noah: A few people took actions to review sections
... Yves on security
... Larry has bug report on fragids
... Timbl on microdata mappings to RDF
... noah on normative status of author document
... Larry to draft note on TAG interest on architectural issues
... JeniT to review microdata and RDFa
... ht to review polyglot and DOCTYPES
... which of these do we want to discuss?
<noah> * Better ways of asking chairs about HTML5 architural issues
<noah> * Microdata and RDFa
<noah> * Authoring draft status
<noah> * App cache (Dan)
<noah> PLH: Last call ends August 3.
<noah> * Do we have enough coverage?
Larry: plh, there's a last call, how do you think the TAG could be most effective?
plh: you don't have to review the entire specification
... the list you have is a good one
... the URI/IRI issue is one
Larry: the TAG has a charter to resolve issues between working groups, so perhaps we can be more involved with that more than reviewing documents
plh: the biggest issue we have there is between HTML and WAI-PF
Larry: Do we need higher consideration?
jar: Have you heard from RDFa?
plh: Well, that's part of the group to some extent
ht: the crucial thing, namely prefix bindings, went away as they're still there
<masinter> ht: xmlns prefixes are in the HTML draft? Plh says no.
plh: are you talking about HTML5 syntax for xmlns?
jar: Prefixes is part of it, but microdata is another part of it
... is there any issue between the RDFa WG and microdata?
plh: not recently
noah: Larry made the point that we're here to resolve issues within WGs
... we also have a mandate to help ensure that specs use web architecture well
... we should continue to do that even if WGs don't come up with objections
Larry: one of the chairs of the WG believes that the TAG has no authority
timbl: the TAG is considered just as any other member of the group
noah: can we scope the issues and if that becomes a problem we'll worry about it then
timbl: What were the issues that we had?
noah: There were a few, didn't we have a discussion and send an email that listed those points?
<timbl> - Microdata and RDFa conflict
<timbl> - historically, URI spec
<timbl> - historically, HTTP spec
plh: There is issue 41 on decentralised extensibility
... the group made a decision, and no one is arguing against it
ht: xml-dev woke up to this 10 days ago
noah: We had the HTML/XML unification work which is part of that
<plh> --> http://lists.xml.org/archives/xml-dev/201106/msg00002.html HTML5 and almost no namespaces
noah: If we've given our input, is it appropriate to raise the issue again at last call?
plh: you can provide new material, or you can raise an objection
<DKA> Isn't this why we encouraged development of the Polyglot spec?
timbl: someone asked how you put Exhibit stuff into HTML5 so that it will validate?
<masinter> how does issue-41 work with polyglot?
plh: The answer is XHTML syntax
noah: XHTML syntax or polyglot?
plh: when you use namespaces in XML syntax, they are valid there, but they might not load properly in the DOM
... if you use application/xhtml+xml then it will be loaded properly in the DOM
... just not in text/html
noah: a script will find it when parsed as XHTML, but not when parsed as HTML
... is there news on polyglot?
plh: we have objection on making it normative
... separate from the authoring spec
dka: what is the objection?
noah: the objection on authoring & base spec normative is potential for clashes
... the polyglot spec doesn't redefine anything, it just observes what works in both modes
timbl: it's only an observation
<masinter> should polyglot reference the authoring spec instead of the main one
<plh> --> http://www.w3.org/Bugs/Public/show_bug.cgi?id=12725 Polyglot spec should be a Note
dka: the implication of polyglot is that there is an implementation burden on browsers, isn't there?
plh (etc): no
noah: it's just says where the parsing rules intersect to yield the same DOM or other interestingly compatible results
timbl: the polyglot spec should be considered a rec track spec
plh: we have someone objecting to that right now
noah: you can have rec track but non-normative
... if this spec disagrees with a normative spec, then it's clear which is in error
... if you have two normative specs that don't work together then it's hard to work out where the bug is
Larry: we should specify what a normative spec is and why you would want one
<masinter> why you might or might not want it
ht: the issue was raised to get rid of prefix bindings, a change proposal against RDFa in HTML
... there were two change proposals in response to this issue (120)
... one was to take out profile/prefix/xmlns
<plh> --> http://www.w3.org/html/wg/tracker/issues/120 Use of prefixes is too complicated for a Web technology
<noah> HTML WG Decision on their ISSUE 120: http://lists.w3.org/Archives/Public/public-html/2011Mar/0689.html
ht: the other was to say that it's important, with existing pages containing xmlns, and you can't take it away
... eventually the chairs found in favour of the status quo
... so RDFa as currently constituted has prefixes and CURIES and uses xmlns to bind them
... despite the fact that HTML doesn't support namespace bindings
JeniT: I've implemented building RDFa processor over HTML and it sucks
ht: various people want to reopen the issue
<plh> --> http://dev.w3.org/html5/status/new-information-status.html New Information Status
ht: but the chairs won't reopen until there's substantial new information
... and there is no formal request to reopen
noah: how we should engage is tricky
Tim: observation about RDFa and microdata...
Noah: What do we currently have scheduled for TAG work on that issue?
HT: That one's not on me but it is on someone.
JAR: I had a concrete suggestion on RDFa.
<ht> Here's the nub of the mess that text/html + RDFa + xmlns:... requires, given no support for xmlns:... in the HTML5 DOM: http://www.w3.org/TR/rdfa-in-html/#preserving-namespaces-via-coercion-to-infoset
jar: the suite of HTML5 specs talk about both microdata and RDFa and creating RDF from them
... and the way they do it is qualitatively very different
... the microdata mapping is done by the HTML WG
... the HTML+RDFa document is developed cooperatively between HTML and the RDF applications WG
... I or JeniT should take an action to point this out to the RDFa/RDF WG chairs
... I think the mapping to RDF should be the business of the people involved in RDF
... maybe the process was fine, maybe if they cared, there would be formal objections
... I want to check with Manu and others whether they're happy with it
... the potential change proposal would be to remove that section
noah: the time is limited between now and early August
... if we want to have impact, we need to get to the point where if we want to, we need to raise a formal objection
... we need to focus on that level of things
Larry: Having these two specs for doing this is architecturally wrong
... we can see how this battles out in the market place
... perhaps we should ask the microdata and RDFa specs should be declared not ready to go to Rec until there's more work on getting them to work together
<trackbot> ACTION-367 -- Noah Mendelsohn to ask the HTML5 chairs to treat our 8220 bug as input to the poll, specifically as "An objection to keeping Microdata in", cc to email@example.com -- due 2010-02-10 -- CLOSED
Larry: it's harmful having two
<Zakim> masinter, you wanted to wonder that moving RDFa and microdata forward is a really unhappy overlap, that schema.org is 'more information', and maybe microdata / RDFa should be worked on further, and LC is premature
<ht> Some real numbers about RDFa: http://tripletalk.wordpress.com/2011/01/25/rdfa-deployment-across-the-web/
noah: we previously had actions on microdata
... there was a history of prior pushback on microdata
ht: they responded positively to that
<ht> In that they moved it out of the main spec.
plh: I don't think that stopping going to Rec is going to have much effect
... people are already doing it
... you have to formally object early
... maybe we should consider creating a task force to reconcile the two
... like we did for HTML/XML
timbl: people see this as tribal war between those who like/dislike RDF
... a task force isn't just about these specs, but about the communities behind them
... you can imagine reinvention of schema languages, query languages for microdata
... I'm not biased towards RDFa because I'm an RDF-head, but because it's compatible with a set of technologies developed over many years
... and has companies invested in it
... not necessarily the browser vendors
<masinter> the TAG work on metadata architecture is part of this
timbl: this isn't just about two specs
... and if there are issues of usability, the RDFa spec should change too
JeniT: I looked through microdata and rdf specs.
... the big things that jumped out as being problems to me
... a) the stuff Jonathan touched on - the incompatibilities of what you get when you parse each of them
<noah> Hmm, so you can't use them both in the same document?
JeniT: b) clear that microdata was integrated into the way that html works in a way that rdfa wasn't, For example, methods defined using microdata but not for RDFa. Methods for copying/pasting stuff with microdata but not with RDFa.
... so there is a mismatch between them, a conflict between them (you can't use them both)...
... If you're going to have 2 ways of doing the same thing then they ought to have clear advantages and disadvantages in different circumstances, and a clear upgrade path from the simple one to the complex one.
HT: They ought to be complementary.
<Zakim> noah, you wanted to ask how task force relates to last call comments
noah: I wanted to ask if, if we create a task force, how does that fit with August last call
ht: a report from such as task force would provide new evidence
<Zakim> ht, you wanted to mention a simple metric which supports Jeni
noah: we need to say something now about this, to lay groundwork
<noah> HT: The new evidence might apply to a subsequent last call.
ht: the extracting microdata to JSON section is one screenful compared to five screenfuls to RDF
<noah> NM: Hmm, it might uncover new input, but shouldn't we also see how much input we can provide for >this< last call?
plh: There is a long example in the RDFa section, but no example in the JSON section
... This issue has never been brought to the working group
... the issue of working on two data specifications has never been discussed
ht: Tim's objection was that microdata should be taken out
<Zakim> masinter, you wanted to ask if we want to work on Jeni's comments
Larry: JeniT had some comments
JeniT: I can write those up
<scribe> ACTION: JeniT to write up comments on microdata and RDFa [recorded in http://www.w3.org/2011/06/08-tagmem-irc]
<trackbot> Created ACTION-571 - Write up comments on microdata and RDFa [on Jeni Tennison - due 2011-06-15].
Larry: I like this idea of a task force
noah: it wouldn't have input to this last call
Larry: We can comment that the specs shouldn't progress until the task force reports back
noah: We need to make a case that something is broken
<masinter> because there are two ways of doing the same thing that are inconsistent
noah: can we object to things in 2nd last call that are unchanged?
noah: we could file an objection now with crude form on issues, and say we think it needs more detailed attention
... can we draft a last call comment?
timbl: an alternative is to object just to microdata
[discussion about status of RDFa as existing Rec]
ht: I only want to object to microdata
... RDFa is standardising a widely deployed technology that we already have standardised
jar: there are legitimate parties who have reviewed RDFa who have said it's not acceptable
timbl: How can we say that RDFa should have those issues addressed?
jar: the issue is reconciliation not one spec or the other
yves: in '95 when we had CSS, SGML had DSSSL
... CSS was adopted because it was easy enough, despite the conflict
ht: it was agreed between the CSS and XSL that they would share a common semantics
yves: it would be fine if there was no conflict between the two
... that being the case, the objection is to the two unless we have a good story to tell
noah: do we have to object on a per-document basis?
... can we object on the package of HTML5 rather than on a particular document
timbl: I'm not sure of the process, but yes that would be appropriate
Larry: we can object to each of them because they're in conflict
... if we had to choose one it would be microdata
... we think they're both likely to be forward, and what we want is consistency in the upgrade path
timbl: microdata and RDFa are identical except for spelling differences
... microdata may be a subset
... it's at the same level, not like CSS vs XSL
JeniT: there are large and complex differences in whether something is an item, the rules in RDFa are complicated
... RDFa tried too hard to fit naturally into existing pages and this makes it really difficult to process and author
noah: we can't reinvent RDFa based on this experience because it would take too long
JeniT: fixing RDFa might not take too much time if they break backwards compatibility
timbl: there is a lot of RDFa out there already
JeniT: I will take what I'm writing and couch it as an objection
dka: we didn't cover appcache
plh: my only point was Yves should look at it
<masinter> Chris Weber new IRI chair was communicating with HTML-WG directly
<masinter> plh, suggest you follow up with Chris Weber on the HTML/IRI issues, I'm encouraging him to push forward on issues
<scribe> ACTION: Yves to look at appcache in HTML5 Due 2011-07-31 [recorded in http://www.w3.org/2011/06/08-tagmem-irc]
<trackbot> Created ACTION-572 - Look at appcache in HTML5 Due 2011-07-31 [on Yves Lafon - due 2011-06-15].
jar: phrase as 'strengthen or revise consensus'
ashok: do you want to get consensus on one particular solution?
... you've spelled out a number of possible approaches
jar: we want to spell out recommended practice from those
noah: A W3C Rec would take as long as it takes to get consensus
... the first criterion implies something informal
jar: these are orthogonal
noah: success means doing all these things
... we develop acceptable techniques
jar: Harry's objection was having no authoritative documentation
noah: The product page can say that we don't know yet
Larry: There's a possibility that you might not succeed
... you might as well say what you really want to have happen
noah: I want to use the product pages to be what we work towards
Larry: I'm asking jar what he really wants to have happen
jar: I think people are wasting time quibbling and I want to be able to point to a document
timbl: Do you want to describe the status quo or something more?
jar: 'either strengthen or revise consensus'
... possibly do something new
timbl: it's the overall design of the system that you want to strengthen or revise, not just get people to be more friendly with each other
Larry: we want to make sure that the linked data community is happy
jar: more the adoption of linked data, not the linked data community
Larry: I'm trying to get to a goal to something that can be more evaluable
jar: A definition discovery story that supports adoption of linked data
noah: that will be widely deployed
Larry: that's not necessarily a measure of quality
noah: wide deployment is important as well as quality
jar: the TAG could say that RDF should do what it wants
Larry: I don't think we can let them not care about web architecture
jar: On the schedule...
... proposal is to revise following our discussion
... put it out on the semantic web and LOD lists to ask for help to approve
... and then convene a telcon with concerned parties