See also: IRC log
<jar> scribenick: jar
<timbl> Larry, document RDF is at http://www.w3.org/2002/01/tr-automation/tr.rdf
agenda review
F2F scheduling
Next F2F is April 2-4 in the south of France.
<glenn> I have a conflict for week of Jun 11-15 should I be elected
<ht> I cannot do 25 or 29 may
<ht> should I be re-elected
<noah> We are talking about 12-14 June in Cambridge, to meet Tim's preferences. Can you do it?
<ht> Yes
<glenn> I will be in London that week
The TAG plans to meet 12-14 June, but please don't make travel plans yet since we need to consult with new members.
ht: It would be good for every TAG member to touch base with an IETF meeting, IMO
LM: Let's talk to Mark N about liaison when he's here. Might be good to interact with ISOC too
... maybe collaborate around extensibility
<masinter> suggestions for IETF general topics: (a) ask MNot on Friday (b) IAB on extensibility, (c) ISOC members on legal impact.
<masinter> suggestions for individual TAG members of relevant IETF working groups: RTC, IRI, URNbis, HTTPbis, websec. If you attend, be prepared to have read relevant documents being discussed
<JeniT> http://www.w3.org/wiki/Html-data-tf
JT: We have had wiki page set up since September. Two documents came out of this
<JeniT> https://dvcs.w3.org/hg/htmldata/raw-file/default/html-data-guide/index.html
JT: HTML data guide - advice on how to do data in HTML, when to use which mechanism
... divided by target audiences
... Publishers: how to mix vocabularies, how to mix syntaxes - what do you have to be aware of re possible conflicts
... Next section is for consumers - what syntax should you consume, how to deal with mixed input
... 3rd section is for vocabulary authors. Extending existing vocabularies to suit new requirements, designing vocabs for each kind of syntax and that work across the syntaxes
... The plan is to publish this as a SWIG note in January
LM: What I'm missing is anything about whole-document metadata - DC, XMP - I know this is a different problem, but some ack of this would be nice
... The HTML meta tag seems related. The document ought to say something about this other stuff, if only to put it out of scope.
... There should be references so that readers are directed to the right place (if they want to know about it)
TBL: question about history of RDFa
... Dublin Core was persuaded to adopt RDF with the understanding that RDFa would be coming along later
NM: Didn't the current [Microdata + RDFa] effort start with the announcement of schema.org ? How have things progressed since then?
<masinter> "whole document metadata" is a separate but related topic but likely to be confused
JT: RDFa Lite is now a WD, schema.org has adopted support for it
<masinter> and http://www.w3.org/TR/REC-rdf-syntax/#section-rdf-in-HTML
JT: Google already recognized a wide variety of markups, and schema.org was a statement of a preferred form
NM: It would be nice to be able to tell the community what the TAG's role was in this
<masinter> also: http://partners.adobe.com/public/developer/en/xmp/sdk/XMPspecification.pdf#page=98 embedding XMP in HTML
<timbl> 2003-12-15 XFN 1.0 launched by Tantek Çelik[1], Eric Meyer[2], Matthew Mullenweg[3]
<timbl> a b "XHTML and RDF W3C Note 14 February 2004". World Wide Web Consortium. 2004-02-14. Retrieved 2007-12-27. http://www.w3.org/MarkUp/2004/02/xhtml-rdf
ashok: So there wasn't a groundswell to reduce the number of formats? Why not?
LM: I thought the big difference had to do with namespaces and extensibility? You can use namespaces in RDFa but not in microdata?
<masinter> i'm also concerned about relationship between embedded metadata in linked images and metadata in links
JT: Not really. In microdata you can have multiple independent event vocabularies
... In microdata syntax you can't say a single item is two things from two different vocabularies... but you can always nest
<JeniT> https://dvcs.w3.org/hg/htmldata/raw-file/default/microdata-rdf/index.html
TBL: What about getting triples out of HTML documents?
JT: That's the second document.
... There were problems with the HTML5 mapping of microdata to RDF
<masinter> for example, http://www.metadataworkinggroup.org/specs/ deals with relationship. For example, img src="something.jpeg" might want to link data about the image in the HTML, to ... override? supplant? be resolved against ? metadata ... may need something of the scope of http://www.metadataworkinggroup.org/specs/
JT: The problem is it's impossible to generate idiomatic RDF without some knowledge of the microdata vocabulary.
<masinter> would like to make sure review with http://www.w3.org/2008/WebVideo/Annotations/ happens
JT: It doesn't make distinctions that RDF makes. E.g. what about ordering of multiple values? Microdata is always ordered, but in idiomatic RDF it would depend on vocabulary
... AFAIK everyone using microdata is using schema.org
TBL: Could you annotate the schema?
JT: Somewhere, somehow, there needs to be a registry that provides this information
<JeniT> http://dev.w3.org/html5/md/Overview.html#items
<JeniT> "Except if otherwise specified by that specification, the URLs given as the item types should not be automatically dereferenced."
<noah> We need to wrap this discussion in 2 minutes
jar: asking why there needs to be a canonical mapping for microdata (as opposed to lots of mappings)
noah: Cost/benefit
TBL: Scaling and reuse
<Zakim> masinter, you wanted to ask that the HTML data guide address other workflows around data management in HTML: merging HTML from multiple sources, merging HTML data with data from
<JeniT> I think that's expanding the scope which I don't want to do
LM: metadata about the linked object in the referring document - this is a common workflow - possible conflicts - might be worth calling this out
<JeniT> That might be useful, but it's outside scope
<masinter> if it is out of scope, then please note that it hasn't been addressed and should be before the analysis is complete
NM: Thanks Jeni
JT: There's so much to say about this, we had to keep the scope quite narrow
<timbl> I wonder why "This section is non-normative.
<timbl> This document describes a means of transforming HTML containing microdata into RDF. "
<JeniT> http://www.w3.org/html/wg/next/markup/
Philippe le Hegaret joined the TAG in person for this session.
NM: I'd like to know what we ought to be doing re HTML.next in the next 3-6 months
PLH: Mike Smith did some work since we last spoke about this. New list [of features], which is interesting
... E.g. datagrid got removed from html5, deferred
... Input mode attribute, proposal from Microsoft
NM: Looks like none of this is deeply structural
PLH: There will be no upgrades to the HTML5 parsers
NM: That's important
<masinter> modularization of the specification?
<glenn> the proposed "element" and "template" element types appear somewhat generic
PLH: intent element - from device API WG - for head - this is a problem since an HTML5 parser will treat unrecognized an element in the head as transition to body
<masinter> which of http://www.w3.org/2010/11/TPAC/HTMLnext.pdf are in scope?
<masinter> and my own perspective: http://www.w3.org/2010/11/TPAC/HTMLnext-perspectives.pdf
TBL: This has always been a bug... unrecognized head elements ought to be ignored, otherwise there's no extensibility
PLH: intent is thus an example of an extension that's NOT going to be considered for now
... ('intent' is a misnomer)
NM: Intent has a pub/sub feel to it, like Android intents, right?
PLH: Arrival of speech on the web is going to be a big item. Speech incubator group is looking at it
... translate - if you don't use namespaces, that's OK, but [scribe missed]
... translate will be part of HTML, but will be extended further
<plh> --> http://www.w3.org/2011/12/mlw-lt-charter.html Multilingual Web Working Group Charter
NM: Before ratholing, remember the goal is what the TAG should be doing
JAR: What about javascript related changes?
PLH: Being able to control adaptive streaming algorithm - it's a set of APIs
... Javascript modules is not part of this discussion
LM: What I see is sets of features, which seems appropriate for the WG
<glenn> plh? impact from media related proposals in http://www.w3.org/wiki/HTML/next#Multimedia ?
LM: at TPAC there was an interesting panel ... architectural conflicts between SVG (etc.) and HTML, things left dangling, references to evolving specifications
... these are not features, but they are changes to the specification and affect evolution of the language. Maybe the WG doesn't want to work on this, as this is painful
... might the TAG be able [to do anything] to make that kind of work easier to do?
PLH: SVG and HTML video element conflict will be addressed by the WGs
<glenn> plh? accessibility issues from use of canvas ? is this in HTML.next scope ?
PLH: there is interest in making the technologies work well together
LM: color management
PLH: this is happening naturally, since implementors don't like to implement the same thing twice with variation
LM: But that kind of pressure is not neceesarily enough
PLH: The CSS extensibility story has been falling apart. Market successes drive out minority features...
PL: If an id contains a - then it will never become part of CSS (this includes vendor prefixes)
... When people started using vendor prefixes for experimental purposes that was a problem
TBL: Pain
PL: Any vendor who does [that] will get a whack from the CSS WG
LM: The question is who to blame when something goes wrong
PLH: I introduced this topic because CSS seems to have the best extensibility story for experimental features
PL: The best approach is for the CSS WG to drive new features to rec as fast as possible, to avoid vendor prefixes
LM: Vendor prefixes should have a year, and old features should not be used
<masinter> What can the TAG do? Extensibility, mdularization, references... architectural features
<glenn> what is the record for attaining REC by CSS WG? 2-3 out of 20-30 specs? some specs going on 10+ years
NM: XML namespaces often feel like vendor prefixes. There's not a good way to say what the implementation path is for [missed]
LM: How can the TAG help? Not with the feature list. What about architectural issues, like extensibility, maybe narrowly focussed.
PLH: Because no namespace support, we're trying to keep track of new elements being introduced
... [in HTML]
TBL: HTML parser is a big black box, not driven by tables, no grammar - so how to add new elements?
<masinter> timbl: table driven parser? Grammar? If you're adding new elements, where will they be added?
PLH: Some parts of parser are going to be unchanged - error recovery
LM: What about HTML5 issues closed for lack of change proposal? Reconsidering them for HTML6?
PLH: Correct, this can happen.
JT: Has there emerged a kind of scope for HTML.next? Or timeline?
PLH: Should be more rapid this time
<noah> ACTION-600?
<trackbot> ACTION-600 -- Daniel Appelquist to report to TAG on goals, scope and progress to date for HTML.next work -- due 2011-10-25 -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/actions/600
<noah> DKA: No progress on ACTION-600
<noah> NM: I think we'll probably reassign ACTION-600 given that Dan is leaving the TAG, let's see how the rest of this discussion goes.
<noah> ACTION-641?
<trackbot> ACTION-641 -- Noah Mendelsohn to try and find list of review issues relating to HTML5 from earlier discussions -- due 2012-01-17 -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/actions/641
<noah> I'm sorry I didn't have time to get to ACTION-641. It's due mid-Jan. Not sure if I'll get to it, but I'll try. Help would be welcome.
PLH: There's the issue of modularizing the spec. To some extent this happens because different people are working on different parts
<glenn> negative impact of modularization is cross-dependencies between modules and time lines for completion of dependencies
NM: The TAG isn't looking for work, the question is whether we can be of any use
<glenn> separately, there are core semantics of HTML5 spec (such as event queue semantics) that are being normatively referenced by many other specs in other WGs (e.g., WebApps)
<glenn> it's becoming quite a nest of dependencies with little architectural planning for the impact
LM: We're not looking for trouble. Can we look to Philippe to bring to our attention anything the TAG might help with?
<noah> PROPOSED RESOLUTION: The TAG decides that it will not at this time start a significant effort on HTML.next. Therefore: 1) HTML.next will be removed from the under consideration list on the TAG product list 2) ACTION-600 will be closed. The TAG will look to PLH and others to engage the ...
<noah> TAG as appropriate on HTML.next issues.
RESOLUTION: The TAG decides that it will not at this time start a significant effort on HTML.next. Therefore: 1) HTML.next will be removed from the under consideration list on the TAG product list 2) ACTION-600 will be closed. The TAG will look to PLH and others to engage the TAG as appropriate on HTML.next issues.
<noah> close ACTION-600
<trackbot> ACTION-600 Report to TAG on goals, scope and progress to date for HTML.next work closed
LM: Request that MIME type registrations happen sooner
... You can say that there is no specification yet - register a placeholder
... W3C has been too conservative, better to err on the side of aggressive registration
... Enough about specs, it's time to start registering
... I want the official registry to be better than what you find in wikipedia
JT: Talking about media type registries - I had an action re FYN
LM: If specs are allowed to fork, maybe they shouldn't contain their own media type registration, since the reg has to talk about the fork
<JeniT> ACTION-642?
<trackbot> ACTION-642 -- Jeni Tennison to with help from Larry to make plan of action for getting "follow your nose" for (at least) microdata and RDFA from HTML5 Due: 2 January 2012 -- due 2012-01-02 -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/actions/642
LM: Consider the existence of "profiles" - the pointer to the main spec would be just one piece of information
... I want to figure out whether Philippe might need help [with any aspect of the reg. process]
NM: Is profile still out?
PLH: Are you looking for a text/html registration that is really vague?
LM: I was looking for a reg that talks about what someone receiving a document [so marked] would get
NM: Document misuses of the MIME type.
LM: MIME is the wrong place to talk about conformance or correctness.
... MIME is informational to receivers.
NM: The reg. makes promises: if doc is well formed it has such and such a meaning (DOM, etc.)
LM: 3023 is a spec, and you can conform or not. It sets out conformance criteria.
<JeniT> plh, what I'm worried about is the follow-your-nose from an HTML document to understanding how the HTML document should be processed...
TBL: The arch goes thru media type, that means you're part of a protocol, you're committing to a particular meaning
... MIME type is a key piece of this, normative
<JeniT> plh, which can't currently happen because there's no route from the mime type to the various extensions made to HTML
<JeniT> plh, so I guess the question is: where is the registry of the set of HTML extensions (such as microdata, RDFa)
<plh> doesn't exist at the moment
LM: Let me try to restate. When you register, you're saying two things, one to consumers, one to producers. Advice to consumers has to be realistic - even for non-conforming docs
NM: When something's put on the wire, there are inferences that can be drawn from the specs
... It's a contract
... If you send me garbage, then nothing can be inferred per the registration
[but can be inferred some other ways?]
LM: The spec is extensible - extensions are legit according to the spec - even though not written at the time the spec is written
NM: Is error recovery language in HTML used for ...?
[scribe couldn't distill what NM just said into something that could be written down]
NM: Fully legal, expect it but deprecated, tolerate it interoperably, ...
... If you see a new element name, maybe it comes from a future spec
LM: Jeni's action was to connect text/html to RDFa. No simple way to fix that if RDFa isn't listed in the media type reg.
... A registry of HTML extensions would solve this problem
JT: Could W3C do this?
jar: W3C already does this for XHTML (XHTML namespace document)
NM: What should the TAG's involvement be in the text/html media type registration?
PLH: No request sent yet
NM: Maybe TAG should be more actively involved
LM: There's currently a W3C policy that the media type reg is in the language spec, because unlinking led to mismatches. This is probably OK in many cases, but I'm not sure about text/html
<glenn> other obligations for today, will rejoin in morning
<noah> NM: I think the next step on media type registration would be to get a balanced analysis of potentially controversial or architecturally tricky points regarding the media type registration. Then we can see if there's anything the TAG needs to engage.
<noah> JT: We can rescope my ACTION-642 to cover that.
<noah> NM: Great, fine with me. Thank you.
<noah> ACTION-642
<noah> ACTION-642?
<trackbot> ACTION-642 -- Jeni Tennison to with help from Larry to make plan of action for getting "follow your nose" for (at least) microdata and RDFA from HTML5 Due: 2 January 2012 -- due 2012-01-02 -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/actions/642
<noah> New scope: JT with help from Larry to report on potential issues requiring TAG attention relating to HTML media type registration.
<masinter> it says "at least"
<JeniT> "JT with help from Larry to liaise with PLH to register HTML media type
<noah> "JT with help from Larry to propose plan to liaise with PLH to register HTML media type
NM: what about what TAG is doing, as opposed to TAG members. [scribe mistranscription]
<noah> ACTION-642?
<trackbot> ACTION-642 -- Jeni Tennison to with help from Larry to propose plan to liaise with PLH to register HTML media type -- due 2012-01-17 -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/actions/642
<masinter> i liked the old action item better, because it recorded why we're doing it
break ending
Welcome Wendy Seltzer
introductions
WS: EFF, Berkman, now W3C team
<masinter> http://masinter.blogspot.com/2011/08/internet-privacy-telling-friend-may.html
<masinter> my contribution to the privacy discussion
NM: privacy, big issue, potential threat to the web. DNT
<noah> http://lists.w3.org/Archives/Public/www-tag/2012Jan/0000.html
ashok: The idea was to look at privacy from higher level. There is a DNT WG, that's good, but it's just a corner of the "war on personal privacy"
<masinter> want to ask about ISOC and http://www.internetsociety.org/our-work-privacy
ashok: leaks from social networks
... picking up ambient information
... identifying based on clicks etc.
<masinter> http://www.ietf.org/rfc/rfc3514.txt
ashok: Not a technological problem. Encryption may be helpful, but not clear how far it can go
... Accountability, laws as non-technological alternative
... Mitigations? Technical, policy, education
DKA: Data minimization as technical mitigation - granularity - this is privacy-enhancing
<masinter> What is relationship of W3C role in privacy to other initatives
jar: Interesting: http://dataprivacylab.org/projects/irb/index.html
DKA: I got negative feedback from the geolocation WG - they ask, who is asking for this?
<DKA> Draft API Data Minimization finding: http://www.w3.org/2001/tag/doc/APIMinimization.html
NM: Here are 2 things. 1, possibility of more traffic encryption, cf. SPDY.. performance limited devices, cost of encryption. 2. Fingerprinting, e.g. browser configuration uniqueness . These are technical topics
<Zakim> masinter, you wanted to ask why this is TAG work... argue against TAG taking this as a major area, not so much because of "lack of expertise" as "already covered". to respond to
YL:
LM: W3C is a focus of policy initiatives that aren't asked for by developers. Constituencies come to us
... Many past difficulties around privacy have to do with venue shopping, esp between W3C and IETF.
... Encryption is a red herring. Does nothing for privacy
<timbl> Sweeping generalizations are always wrong -- and Larry's is no exception.
LM: Why is this TAG work? Seems like W3C work, but not TAG work - not technical. Not interested in stopgaps
<masinter> it isn't that it is "not technical", it's that any TAG work would be without sufficient context to be useful
<masinter> "Not interested in stopgap" => "DNT is stopgap, we shouldn't do too many more of those"
<masinter> encryption doesn't help much with almost all of the privacy threats i can think of
<DKA> For the record: I feel the data minimization is relevant to the TAG since it is articulating an architectural principle - a design best practice - that also happens to enhance privacy.
<masinter> @dka: it might be an architectural principle, but it's not clear it really helps in most of the threat cases, and it's not actionable
NM: Look at work plan...nothing much here re privacy, barely started
RESOLUTION: The TAG will not do a major effort on privacy at this point. We will remove Privacy from the list of active projects.
WS: The framing is a good start. Threat categories: p2p, corporate, individual to government - different concerns re different info collectors
LM: [What are the] threats?
WS: Info used out of context
LM: Is there a sense that these are more than a list of anecdotes?
... What W3C could do: try to ground anecdotal tales about hypothetical instances, in real cases
... If we had a better model of the real threats, we could do better at responding, with technical architecture
WS: We can do better at describing
LM: We need the particular cases - not a categorization - we already have good descriptions of categories, but they seem to be based on hypotheticals
... need grounding in fact
TBL: [one might mine them from] risks digest http://catless.ncl.ac.uk/Risks
<masinter> a real threat analysis
<wseltzer> "concern" can be a harm too
<DKA> http://online.wsj.com/public/page/what-they-know-digital-privacy.html
<wseltzer> ...if people are deterred from using the web based on concerns that their information may be misused
<masinter> concern can be caused by rumors too
<masinter> many people are concerned about 12/11/12 or whenver the mayan calendar says the world will end
<masinter> would encryption help with any of the issues in http://online.wsj.com/public/page/what-they-know-digital-privacy.html ?
discussion of what to do, and who to do it
<wseltzer> encryption could prevent some of the snooping by middlemen
<Yves> encryption could also lead to misplaced trust (in case of CA attacks, for example)
<noah> WS: I'm here to work on Web Identity.
action jar to review what provenance WG is doing with an eye to application to privacy issues
<trackbot> Created ACTION-650 - Review what provenance WG is doing with an eye to application to privacy issues [on Jonathan Rees - due 2012-01-12].
<noah> WS: Part of that is getting the privacy story right, and helping users to understand the implications of what they're doing on the Web
<noah> ACTION-566?
<trackbot> ACTION-566 -- Daniel Appelquist to contact Alissa Cooper, organize a future joint discussion on privacy with IAB. -- due 2011-10-18 -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/actions/566
<masinter> http://www.internetsociety.org/our-work-privacy
<masinter> see http://www.ietf.org/proceedings/81/technical-plenary.html
adjourn for lunch
<Norm> I'm hitting the road. Noah, you've got my mobile if you need to reach me. See y'all this afternoon.
<Ashok> scribenick: Ashok
Noah: We published a finding on Web Application State.
... need to deal with Raman's document
... I suggest we move Web App State to the completed state
LM: Did we get community review?
Noah: We may want to do more to promote it and ask folks if it helped them
LM: Any reason not to make this rec track?
Jar: Findings should make their way into architectural recommendations
RESOLUTION: The TAG, having published a finding on Web Application State, closes its "product" on that topic.
<noah> ACTION: Noah to announce closing of Web App State Product Due: 2012-01-17 [recorded in http://www.w3.org/2012/01/05-tagmem-irc]
<trackbot> Created ACTION-651 - Announce closing of Web App State Product Due: 2012-01-17 [on Noah Mendelsohn - due 2012-01-12].
<noah> — <span class="needswork">product page needed</span>)</td>
<noah> <td>Daniel Appelquist, Ashok Malhotra</td>
<noah> <td class="needswork">TBD</td>
<noah> </tr>
http://www.w3.org/2001/tag/products/ is the list of stuff we are working on
Noah: Frag Identifiers and Mime Types is late
<noah> ACTION-594?
<trackbot> ACTION-594 -- Peter Linss to with Henry produce partial revision of fragment id finding -- due 2011-10-18 -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/actions/594
Yves: I will work on that
<noah> ACTION-594?
<trackbot> ACTION-594 -- Yves Lafon to with Peter and Henry produce partial revision of fragment id finding -- due 2012-02-14 -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/actions/594
LM: Should we integrate this with the other MIME stuff?
JT: I think it's better to keep a tight scope
Noah: The TAG agreed to invest in this effort starting by revisiting the work plan.
(Noah updates the product page)
Noah: Publishing and Linking on the Web remains a top priority
... URI Discovery remains a top priority
... MIME architecture for the Web remains a top priority
... Other items:
... API Minimization --- leave
LM: Not clear this will make progress. Let us publish now.
Dan: Maybe a new TAG member will have new energy to put in this
... I can come back with a proposal how to publish it
Noah: We can leave open for a few weeks and then decide. Or decide to publish now.
Dan: I will come back with a proposal for our next telcon
Noah: HTML/XML Unification
... this is either done or we keep in this mode
... Persistence of Identifiers
... should we move this up in priority
jar: Publishing a Workshop Report would be good.
... then i can do some writing based on yesterday's session
<Yves> ACTION-622?
<trackbot> ACTION-622 -- Noah Mendelsohn to schedule discussion of html.next as possible new TAG work focus (per Edinburgh F2F) [self-assigned] -- due 2011-12-20 -- PENDINGREVIEW
<trackbot> http://www.w3.org/2001/tag/group/track/actions/622
<Yves> ACTION-652?
<trackbot> ACTION-652 -- Yves Lafon to danA to come back with a proposal on API minimization draft -- due 2012-01-17 -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/actions/652
<noah> ACTION: Noah to schedule telcon discussion of Persistence product page (which was drafted for but not reviewed at F2F0 Due: 2012-10-17 [recorded in http://www.w3.org/2012/01/05-tagmem-irc]
<trackbot> Created ACTION-653 - Schedule telcon discussion of Persistence product page (which was drafted for but not reviewed at F2F0 Due: 2012-10-17 [on Noah Mendelsohn - due 2012-01-12].
Noah: Microdata and RDFa
... is this done?
JT: I think we should declare success
... I will write a final taskforce report and tell the TAG and the HTML WG
<noah> ACTION: Jeni to write "product" page summarizing wrapup of RDFa/Microdata work Due: 2012-01-31 [recorded in http://www.w3.org/2012/01/05-tagmem-irc]
<trackbot> Created ACTION-654 - Write "product" page summarizing wrapup of RDFa/Microdata work Due: 2012-01-31 [on Jeni Tennison - due 2012-01-12].
Noah: Web Apps Storage
<JeniT> ScribeNick: JeniT
noah: client-side local storage is not a spec
ashok: the difficulty is there's more than one web storage capability
(looking at draft http://www.w3.org/2001/tag/products/clientsidestorage.html )
ashok: the success criteria look like requirements for a Web Storage Working Group
noah: I'm trying to spell out good practice for people developing web apps, such as a calendaring application
... how to design a good web app
TimBL: perhaps express it as a set of patterns
... when we did a top-down analysis of versioning, it didn't really work
... local storage is new, and it will change a lot soon
... there's a caching pattern when the URI on the web is used everywhere to refer to the document, even when it's in local storage
noah: the TAG isn't committed to doing anything in this space at all currently
... what we need to do here is to decide how to scope it and choose where to invest
larry: it's difficult to come up with best practices, but we could come up with criteria for evaluating a design
... we don't have to produce the patterns, just say how to evaluate a design
ashok: evaluate on what basis? I thought using patterns or use cases would help
noah: there are cases where we will have a good idea for a pattern, such as where the same information is stored locally and on web
... but then it's hard to point to local vs web
... we need a plan that's more than just noodling on use cases
... how about we refine this draft product page?
larry: examining even one tradeoff is useful
ashok: Dan, when could we have something about the workshop? do you have a draft?
<noah> ACTION-523?
<trackbot> ACTION-523 -- Ashok Malhotra to (with help from Noah) build good product page for client storage finding, identifying top questions to be answered on client side storage -- due 2011-12-20 -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/actions/523
dan: there are minutes
<DKA> Minutes for off-line web apps workshop: http://www.w3.org/2011/11/05-offline-minutes.html
<noah> ACTION-523 Due 2012-01-17
<trackbot> ACTION-523 (with help from Noah) build good product page for client storage finding, identifying top questions to be answered on client side storage due date now 2012-01-17
<scribe> ScribeNick: Ashok
Noah: I feel moderately good about the topics we have.
JT: SPDY?
Noah: Let's talk about this after tomorrow's session.
<Norm> Norm begins by thanking Tim for the fine hospitality
<Norm> Norm begins by thanking Tim again for the fine hospitality
<noah> ACTION-437?
<trackbot> ACTION-437 -- Tim Berners-Lee to create a task force on XML / HTML convergence -- due 2011-06-01 -- CLOSED
<trackbot> http://www.w3.org/2001/tag/group/track/actions/437
<Norm> => http://www.w3.org/2010/html-xml/snapshot/
<noah> http://www.w3.org/2001/tag/tag-weekly#htmlxml
Noah: We should review the report, determine whether further action is required and update product pages, etc.
Norm: My goal is to publish report, which the TAG needs to do so that we can get public review
Noah: We could publish a note
Norm: The TAG wanted a strong statement re. Polygot but there were people that thought that that was a waste of time
... so that does not appear
... I attempted to incorporate the feedback I got
<jar> 2.1.1 in the table of contents
<noah> http://www.w3.org/2010/html-xml/snapshot/
<timbl> In the report please change "Resolution Broadly speaking, there are two techniques for addressing th" to "Resolution Broadly speaking, there are two alternative techniques for addressing th"
LM: Add names of other contributers?
Dan: Are editorial comments in scope?
Norm: Yes, they are
LM: I want references to source material
Noah: Add sentence mentioning minutes of telcons
s/mentioing/mentioning/
LM: Cite [the] paper backing up the assertion that "much of HTML is generated".
Norm: Could you identify where references would help?
Dan: Re. last para ... sets out a false dichotomy
... should say "if you want to ... . you could use polyglot"
... use positive wording
<JeniT> "Consumers that require polyglot markup will fail with content doesn't adhere to it. Therefore, consumers that want to access lots of random data can't use polyglot. On the other hand, in a constrained environment (eg where the consumer is publisher), polyglot is more viable"
<jar> People who like this sort of thing will find it's the sort of thing they like. (re polyglot)
Norm: There was some pushback re. polyglot
Dan: If you have a corpus, you want to publish documents on the web [but] use it also as XML, you should use XHTML
<jar> Polyglot reduces the number of versions you have to keep track of
Noah: Multiple uses of documents
Norm: If there is an angle for giving polyglot a better angle, I'm all for it, but the task force did not want that
JT: We want to digitally sign the pages as XML
<jar> LM: Just say there are use cases for polyglot the TF didn't consider and didn't make progress on.
<jar> ?
Norm: I will attempt to incorporate this info in 2.1 and see if the taskforce will [buy] off on it
<Zakim> DKA, you wanted to question the wording of the polyglot markup paragraph.
<JeniT> scribenick: JeniT
ashok: laxer XML parsers seem interesting, and there should be more of a reference
ndw: if you want that to happen, I think the TAG should recommend taking that forward
noah: the conclusion of the TF was that it was unlikely to be effective in practice, because it wouldn't be adopted by people using XML now
ndw: the draft doesn't say that, it was just that the TF wasn't the right body to do that
<scribe> scribenick: ashok
Norm: The taskforce did not think this was central to their concerns
<Zakim> JeniT, you wanted to ask about HTML toolchains consuming XML
Norm: We should charter a WG if we want this work to get done
JT: Why bother discussing the usecase in 2.2?
Norm: For balance ... I think it comes to the right conclusions
Tim: What was the most hardest point?
Norm: How to make XML more forgiving of errors
(Discussion of how to make XML more forgiving of errors)
Norm: The XML spec states it should be well formed
Noah: Spec does not talk about errors and perhaps how to deal with them.
Norm: My take away was -- just put an HTML parser in front. And that works.
<Zakim> noah, you wanted to talk about where XML forgiveness is discussed
Noah: The conclusion section should restate earlier material. So, ...
<noah> Specifically, I noted that the sentence "However, it's entirely unclear that the XML community would be motivated to adopt such changes and, in any event, making such proposals is outside the scope of this Task Force." is in the conclusions only. That thought should also be in 2.5, I think.
<noah> Norm agreed.
jar: "HTML parser" is not defined ... perhaps use "standard HTML parser"
Yves: It should be HTML5 Parser as it is the first spec to define parsing model
jar: Rewrite for the naive user ... define terms
Norm: Define HTML parser as something that conforms to HTML5 spec
jar: In 2.2 can you make a stronger statement if input is XHTML
Norm: It's likely to get XHTML right
jar: It is worth saying that
... Does not discuss XSLT
Norm: XSLT is a XML tool, not an HTML tool
JT: Use XSLT to covert XML to HTML?
... the document says that
jar: Says in 2.5 "the HTML parser", earlier it says "an HTML parser".
<Zakim> JeniT, you wanted to ask about embedding XML islands in polyglot/XHTML
Norm: Should always say "an HTML5 parser"
Tim: Cannot substitue XML parser for HTML parser ... they produce different DOMs
Norm: Eventually, there will be a single DOM
<JeniT> JeniT: section 2.4 should mention (a) that you can embed any old XML in XHTML without <script> and (b) that you cannot use the <script> method in Polyglot markup
Noah: There is a missing shim between XML and HTML DOMs
Norm: There are several shims around
(Discussion about differences in DOMs)
<Zakim> masinter, you wanted to review comments
LM: Editorial stuff re. comment should go to Task Force
Norm: SOTD needs updating
LM: There is ladder of comparisons, XML/HTML infosets etc.
... Asks about digital signatures ... cannot do it in HTML
... need to convert HTML to XML
<jar> LM: what if you want to apply EXI to HTML?... want to know how to slot this (and other random use cases) into the document
Norm: Document is clear about where it says XHTML and HTML
... no confusion there
<jar> LM: no orientation to layered architecture - surface syntax, parse tree, element semantics
LM: Should say why someone should care about this document
Noah: Who is the audience for this?
Norm: The intro says that.
... Technical folks on one side or the other interested in the issue
<jar> LM: maybe the average AC member as audience
Noah: Does this document do it for that audience?
LM: Other audiences: Typical AC member, someone in the trade press
<DKA> I think the document is fine for the Intended audience (modulo my earlier comments regarding polyglot).
<jar> "Readers are encouraged to report additional use cases" - really? I thought you were trying to wrap this up
Noah: The question is "Is it a useful piece of work for the audience it is intended for"
(Discussion about different audiences)
Noah: There is a wiki, right? Would that answer the question?
Dan: This is useful for folks struggling with these problems
Noah: Can we discuss next steps?
Norm: It's going to be hard to get all the references ... this represents the judgements of a lot of smart people
Tim: I support taking the document forward
Ashok: Norm should react to the comments he has received and then we should vote whether to publish the document
Noah: How shall we publish the document?
Tim: Let's publish as a Finding and then a Note
JT: Do you want public review?
Norm: I would like to publish the draft as is as a Finding then fix it up and publish as a Note
<jar> LM volunteers to write status section
Noah: Does anybody object to publishing the document as a Draft Finding as soon as Norm makes the changes we recommended?
Norm: I would like to have it published in some form
DKA: Editorial changes should be incorporated
Yves suggests a W3C Note
scribe: Notes can be updated
Yves: It was a product of a task force
Tim: Gets it into the mainstream
Feeling that Note is better
Noah: Norm, pl. work with Yves to prepare a document to be published as a Note
... we can then review and then we can vote and publish
RESOLUTION: The TAG thanks Norm Walsh and the task force, and expects that Norm will shortly provide the TAG for review a draft on XML/HTML Unification to be published as a W3C note for comunity review and comment. TAG chair will check with TAG before giving final clearance for publication.
<DKA> +1
LM: Change the name of the document?
<noah> ACTION-587?
<trackbot> ACTION-587 -- Jonathan Rees to prepare issue-57 and issue-63 documents for TAG members to discuss at Sept F2F -- due 2011-10-11 -- CLOSED
<trackbot> http://www.w3.org/2001/tag/group/track/actions/587
<noah> ACTION-591?
<trackbot> ACTION-591 -- Noah Mendelsohn to ping Norm end of Sept. on revised HTML/XML report per discussion on 1 Sept 2011 -- due 2011-12-27 -- PENDINGREVIEW
<trackbot> http://www.w3.org/2001/tag/group/track/actions/591
Tim: The Taskforce stems from Raman's request for XML/HTML unification
Noah: I will prepare a covering note, which I will share with you, which will have some of the history
Norm: I prefer in the cover letter
LM: Could be in the introduction
Tim: I prefer the history in the cover letter
<noah> ACTION: Noah to check Norm Walsh draft of W3C Note with the TAG, draft cover letter to include with Note, and review that with the TAG Due: 2012-01-17 [recorded in http://www.w3.org/2012/01/05-tagmem-irc]
<trackbot> Created ACTION-655 - Check Norm Walsh draft of W3C Note with the TAG, draft cover letter to include with Note, and review that with the TAG Due: 2012-01-17 [on Noah Mendelsohn - due 2012-01-12].
JT: Asks about taking the XML5 work forward
<noah> JT: Two additional things we might do 1) possible encouragement of W3C to do something like XML5 on liberal XML processing 2) possibly do a new version of note that would better target needs of AC members, etc.
<noah> ACTION: Noah to schedule discussion of possibly getting W3C to invest in technologies for liberal XML processing (e.g. XML5) [recorded in http://www.w3.org/2012/01/05-tagmem-irc]
<trackbot> Created ACTION-656 - Schedule discussion of possibly getting W3C to invest in technologies for liberal XML processing (e.g. XML5) [on Noah Mendelsohn - due 2012-01-12].
<noah> NW: XML Prague is weekend of 11th and 12th of February (Jeni is keynoting on Microdata and RDFa)
<noah> NW: Anne will present XML5. Robin Berjon had some ideas for the task force, and he will present those. Norm is chairing a panel on XML/HTML.
<Norm> => http://www.xmlprague.cz/2011/sessions.html
<noah> ACTION: Noah to schedule telcon discussion of possible XML/HTML Unification next steps Due: 2012-01-27 [recorded in http://www.w3.org/2012/01/05-tagmem-irc]
<trackbot> Created ACTION-657 - Schedule telcon discussion of possible XML/HTML Unification next steps Due: 2012-01-27 [on Noah Mendelsohn - due 2012-01-12].
<JeniT> http://www.xmlprague.cz/2012/sessions.html
<Norm> => http://www.xmlprague.cz/2012/sessions.html
<noah> ACTION-657 Due 2012-01-17
<trackbot> ACTION-657 Schedule telcon discussion of possible XML/HTML Unification next steps Due: 2012-01-27 due date now 2012-01-17
<jar> scribe: Jonathan Rees, Ashok Mahotra