Draft minutes of Wed 13th June 2012 TAG F2F


The draft minutes from Wednesday 13th June 2012 TAG F2F meeting are available at


and reproduced below. Note that the HTML version has pictures!





      [1] http://www.w3.org/

                               - DRAFT -

   This is version has not been approved as a true record of the
   TAG's meeting and there is some risk that individual TAG
   members have been misquoted. This transcript should typically
   not be quoted, except as necessary to arrange for correction
   and approval.

                         W3C TAG F2F 2012-06-13

13 Jun 2012

   See also: [2]IRC log

      [2] http://www.w3.org/2012/06/13-tagmem-irc


          Noah_Mendelsohn, Larry_Masinter, Ashok_Malhotra,
          Peter_Linss, Henry_Thompson, Tim_Berners-Lee,
          Jeni_Tennison, Jonathan_Rees, Robin_Berjon_(partial,
          on_phone), Yves_Lafon_(partial, on_phone),
          Norm_Walsh_(partial, on_phone)


          Noah Mendelsohn

          Larry Masinter, JeniT


     * [3]Topics
         1. [4]Storage
         2. [5]TAG Effectiveness
         3. [6]Positioning of Web and Native applications
         4. [7]Administration
         5. [8]TAG Priorities 2012
         6. [9]HTML/XML Unification
         7. [10]Issues for Thursday
     * [11]Summary of Action Items

   <scribe> scribenick: masinter

   <scribe> scribe: Larry Masinter


   noah: Storage including synchronization


     [12] http://lists.w3.org/Archives/Public/www-tag/2012Jun/0032.html

   <noah> ACTION-647?

   <trackbot> ACTION-647 -- Robin Berjon to draft product page on
   client-side storage focusing on specific goals and success
   criteria -- due 2012-06-29 -- OPEN


     [13] http://www.w3.org/2001/tag/group/track/actions/647

   <noah> Robin recommends:

   <noah> [The TAG SHOULD NOT] attempt to provide a solution for
   synchronisation problems. It is a complex research area, and if
   a standardised solution were to be established (which may not
   be necessary, and certainly not yet) it ought to be created by
   a dedicated working group with the requisite expertise.

   <noah> there could be room for the TAG to release a short
   advisory note that would document 1) the known pitfalls in
   dealing with data synchronisation, 2) the primary patterns and
   solutions, and 3) an overview of the terms of the trade. The
   goal of such a document would be to ensure that someone who may
   be an adept Web application developer but has no knowledge of
   this specific problem space to save precious time by being
   bootstrapped with the basics one needs to s

   I suggest this is a topic for the TAG Blog

   <noah> I hadn't meant to ask about synchronization


     [14] http://lists.w3.org/Archives/Public/www-tag/2012Jun/0035.html

   noah: in terms of other storage work, what should the TAG do?

   darobin: In terms of architecture, it would be useful to
   revisit the notions we have URI stability, in terms of
   distributed minting of URIs
   ... we might want to look at versioning, and the databases are
   massively distributed and unlikely to be running the same
   ... problem of vendor lockin, if you have data locally and want
   to switch user agents
   ... if there is any TAG work to be done, the rest falls under
   "these are pitfalls"

   <noah> I think when we've spoken of versioning in the past,
   it's most often been regarding which version of a language or
   format is used. I think Robin is speaking of the
   synchronization of versions of particular data

   timbl: what about sharing and access control? If you have lots
   of apps access to your address book ...

   darobin: SOP solves the access control problem.

   timbl: I don't think so. I want to have standards for the data,
   for interoperaebility
   ... I buy an application, use it on the ipad, and i can't do
   anything at all with the data

   darobin: 2 things: vendor lockin, if data stored is _only_ in
   UA and only locally, then that would lock you into a UA
   ... sharing, you don't want to give another application access
   to your storage directly because you might change htem
   ... ((something about webintents, group being chartered))
   ... webintents provide standardisation around data structures

   timbl: there is another model, from the linked data platform,
   where you DON'T use APIs
   ... people are fed up with every app having little APIs that
   everyone else has to use. Instead you give access to a file,
   where the file uses linked data representation

   darobin: it's not that different a model. The APIs are data
   oriented with a discovery component.

   timbl: standardizing an ontology instead

   darobin: standardizing an ontology and standardizing an API are
   very similar in these cases

   noah: Robin, if you have to leave, anything else?

   darobin: Not beyond what's in my e-mail. I am interested, as
   Tim implies, in finding common model between Web Intents and
   Linked Data
   ... could we make use of json-ld, (something), we've been
   looking at options

   <JeniT> +1 on common model between webintents and linked data

   noah: what is your interest in writing in this area?

   darobin: I can help but I don't want to drive

   timbl: form my point of view, I'd love to have someone explain
   why, after all these years, that sync is hard

   noah: Cap theorem... it's hard.

   <noah> Some references on CAP theorem:

   <noah> [15]http://en.wikipedia.org/wiki/CAP_theorem

     [15] http://en.wikipedia.org/wiki/CAP_theorem


     [16] http://www.julianbrowne.com/article/viewer/brewers-cap-theorem

   timbl: Mac has had over years sync services, and still over the
   years there are failures

   noah: if you're willing to keep some amount of state and don't
   have ((various caveats)) unbounded number of replicates, this
   is a "solved problem"

   timbl: Robin said this is still a research issue

   noah: the research is for cases which are more complicated

   timbl: (description of situations where synchronization has
   failed for him on odd occasions)

   ashok: re vendor lockin: what is required is that you can take
   your data and move it to another machine
   ... thinking about replication: what has happened in the last
   few years is NoSQL
   ... they replicate the databases to make them all available

   <noah> We have 20 mins or so to settle what TAG is doing in
   this space.

   ashok: They have this semantics of "eventually consistence"
   ... that works OK if there is no semantic difficulty

   timbl: the mac has a layer where it generates a UI and asks the
   user about semantics

   ashok: if you use CouchDB, it keeps copies of your documents,
   and ... ((...)) ...
   ... if you don't have conflicts it is a solved problem. If you
   do have conflicts, ... (something)...
   ... I want the WebApps guys to make an interface to SQL
   ... if you use SQL, the database syncs, it's what databases do
   ... databases can even send you updates to previous queries

   <noah> I think it's also a difficult problem if the existence
   of replicas is not well controlled. I believe Lotus Notes
   allows anyone to create new replicas, which means you can
   >never< be sure you've been in touch with all the replicas.

   <noah> In Notes, this is dealt with be assuming that all
   replicas are (transitively) in touch over, say, ever 6 months.
   If you leave a laptop in a drawer for 2 years and reboot, you
   can have things like deleted records reappearing. So, that case
   remains hard as far as I know.

   timbl: from the RDF point of view, it would be appealing to
   define sync for arbitrary RDF graphs

   noah: (time)
   ... there were two items: storage & synchronization

   ashok: robin spoke about 2 things

   noah: we need to define what the TAG is doing
   ... what is the TAG's business?
   ... Synchronization vs. Storage, what do you think the TAG
   should pursue?

   ashok: when robin started, he said "we could write something
   that would alert people about storage"

   <timbl> We did sync stuff with cwm in the SWAP project around
   2001 [17]http://www.w3.org/DesignIssues/Diff

     [17] http://www.w3.org/DesignIssues/Diff

   jeni: why not bite of syncrhonization about storage
   ... would like some kind of output

   noah: I think someone needs to research the state of the art,
   looking at web environment, all in the context of writing

   jeni: we're looking at people trying to get out of walled

   I'd like to propose a direction for consideration

   noah: Suggest we use next 10 minutes to see whether people
   agree TAG work on sync, and if so, get short list of detailed

   masinter: The only interesting idea I've heard is for the LD
   platform could provide a framework for unwalled synchronization
   . Surveying sync literature is uninteresting, because nobody
   will come to us for that.
   ... I think the community won't look to us for that. What might
   be useful is to narrow focus to linked data synchronization.

   <Zakim> timbl, you wanted to about sync being proprietory

   <noah> It occurs to me that things like Dropbox are very widely
   deployed embodiments of sync, albeit at the file level.

   <noah> rsync is also pertinent to a degree, I think, though as
   far as I know it's not bi-directional.

   timbl: because the architecture was hub (or adaptor and hub)
   and spoke
   ... EAI Enterprise Application Integration (something)
   ... that may be why syncrhonization is a black art: the market
   is based on solutions where the hub is a black art

   <Zakim> JeniT, you wanted to say that the interesting thing is
   synchronisation on the web, with the use of URIs and of REST,
   and standard formats, all of which LDP should take full

   <noah> +1 to what Jeni's about to say :-)

   jeni: what i think is interesting is applying the principles
   we've learned in other systems. If it's done right, LDP should
   be a great example of it being done right

   ashok: it's an example we're interested in

   jar: message shouldn't be "You should do it this way" but "If
   you want to do it this way, here's how"
   ... and what advantages you might get

   masinter: the question is -- update conflict resolution in
   general requires understanding the application -- does using
   link data deconstruct updates such that a generic conflict
   resolution mechanism for rdf graphs could be used?

   noah: who's willing to do X

   jeni: i'd rather someone have an action to write something

   noah: (wants a product page)

   (discussion of whether we're doing a product page or a document
   or ...)

   ashok: I'll talk to Robin when I can catch him

   <noah> ACTION: Ashok to propose outline for possible TAG
   document (finding or rec) on architectural issues relating to
   storage sync, linked data, etc. Due 2012-07-15 [recorded in

     [18] http://www.w3.org/2001/tag/2012/06/13-minutes#action01

   <trackbot> Created ACTION-717 - Propose outline for possible
   TAG document (finding or rec) on architectural issues relating
   to storage sync, linked data, etc. Due 2012-07-15 [on Ashok
   Malhotra - due 2012-06-20].

   <noah> ACTION: Ashok to propose goals and success critera for
   TAG work on architectural issues relating to storage sync,
   linked data, etc. Due 2012-08-15 [recorded in

     [19] http://www.w3.org/2001/tag/2012/06/13-minutes#action02

   <trackbot> Created ACTION-718 - Propose goals and success
   critera for TAG work on architectural issues relating to
   storage sync, linked data, etc. Due 2012-08-15 [on Ashok
   Malhotra - due 2012-06-20].

   i think the scope in the action is broader than i wanted

   <noah> ACTION-647?

   <trackbot> ACTION-647 -- Robin Berjon to draft product page on
   client-side storage focusing on specific goals and success
   criteria -- due 2012-06-29 -- OPEN


     [20] http://www.w3.org/2001/tag/group/track/actions/647

   <noah> close ACTION-647

   <trackbot> ACTION-647 Draft product page on client-side storage
   focusing on specific goals and success criteria closed

   <noah> ACTION-693?

   <trackbot> ACTION-693 -- Robin Berjon to draft scope and goals
   for the Patterns/Pitfalls work in local/remote storage synch --
   due 2012-04-19 -- PENDINGREVIEW


     [21] http://www.w3.org/2001/tag/group/track/actions/693

   <noah> close ACTION-693

   <trackbot> ACTION-693 Draft scope and goals for the
   Patterns/Pitfalls work in local/remote storage synch closed

TAG Effectiveness

   noah: Jeni suggested some meeting facilitation methods to use,
   so I will turn the meeting over to her
   ... I think it is important that we think carefully about what
   we're trying to achieve
   ... People come in and complain "the community isn't listening
   ... and i ask myself whether the charter is wrong or whether
   we're performing it wrong
   ... people complain X and propose Y but it's easy to jump to
   ... as chair I see operational things that are boring but are
   ... try to get required reading, ready in time. I'm angry that
   people don't read the required reading. My intuition is that
   people would do the required readong.
   ... some of those things are bigger
   ... finally, there's quite an asymmetry depending on who is
   contributing, participating in meetings. To some degree, the
   last 6 months hasn't been bad.
   ... the fragid thing looks like pretty good work
   ... there's a lot positive we've done
   ... Issues are called out in the charter; maybe we've swung too
   far from issue-oriented to product-oriented

   (noah reviewing charter)

   ashok: what do you mean by community review?
   ... when we published the finding i wrote, we did several
   rounds where we asked for comments. Are you thinking we should
   have done more of that?

   noah: I think we've tried in good faith to be open
   ... in my time on the TAG we have bent over backwards ...
   people don't complain that we haven't answered comments

   <JeniT> [22]https://en.wikipedia.org/wiki/SWOT_analysis

     [22] https://en.wikipedia.org/wiki/SWOT_analysis

   jeni: structure brainstorming of strengths and weaknesses.....
   ... opportunities and threats, 10 minutes for each to write
   down, and group to write down
   ... one we can prioritize, do brainstorming first, clusters
   ... brainstorming -> clustering -> priorities

   masinter: what are we trying to optimize?
   ... "we don't explicitly discuss goals; rather, in the
   discussion of strengths, weaknesses, opportunities and threats
   and clustering those, we back-derive our common understanding
   of goals"
   ... right?

   jeni: right

   (group has put up postits for strengths, weaknesses, threats,
   opportunities, Jeni will review categories in that order)

Initial uncategorized postings (click for high resolution)


     [23] http://www.w3.org/2001/tag/2012/06/StrengthsUCMed.jpg


     [24] http://www.w3.org/2001/tag/2012/06/WeaknessUCMed.jpg


     [25] http://www.w3.org/2001/tag/2012/06/OpportunitiesUCMed.jpg


     [26] http://www.w3.org/2001/tag/2012/06/ThreatsUCMed.jpg

   jeni: big strength is experience, expertise, knowledge
   ... other big category strength is we're good people
   ... others access to W3C, TimBL
   ... weakness: thrashing, ratholing
   ... weakness: conflict within group
   ... weakness: problems around time available for tag work
   ... weakness: travel funding
   ... weakness: quite a lot of membership churn
   ... weakness: lack of knowledge in specific areas (security,
   privacy, network protocols)
   ... weakness: our ability to educate others, lack of power,
   lack of enforcement
   ... threat: bad PR
   ... threat: creating recommendations take a long time
   ... threat: general issues around connection with other groups
   ... threat: liaison to other groups (ECMA, OASIS)
   ... threat: web is moving, getting broader, more areas
   ... opportunity: side: help persuade community
   ... opportunity: liaise with ietf iab
   ... opportunity: meet more with customers, chairs, staff
   ... opportunity: (2 more)

After clustering in categories (click for high resolution)


     [27] http://www.w3.org/2001/tag/2012/06/StrengthsCatMed.jpg


     [28] http://www.w3.org/2001/tag/2012/06/WeaknessCatMed.jpg


     [29] http://www.w3.org/2001/tag/2012/06/OpportunitiesCatMed.jpg


     [30] http://www.w3.org/2001/tag/2012/06/ThreatsCatMed.jpg

   ((ashok is typing outline))

   noah: we should find some middle ground to find some high-value

   <Ashok> Strengths - Experience, expertise and knowledge - Good
   people - Common understanding of Web - Good writing skills -
   Tim is with us - Access to W3C Process

   <Ashok> Weaknesses - Thrashing, ratholing - Conflict within
   group - People are busy - Problems with travel funding -
   Membership churn - Lack of knowledge about some areas:
   security, privacy, protocols - Fear of producing poor work -
   Relevance of the work - Ability to educate others and have
   impact on them - Enforcement. No power.

   <Ashok> Threats - Bad PR - Creating Recs and how long that
   takes. - Not enough external review - How to persuade peple
   about importance of architecture - Connection with other groups
   - Technology is changing, scope is growing, moving away from
   areas where we have skills (this may be also an opportunity)

   <Ashok> Opportunities - Help persuade people this matters -
   Help WGs - Liaise with IETF - Feedback on WG work - Meet with
   customers, etc.


   <JeniT> Scribe: JeniT


   <Ashok> - Disconnect from community (5)

   <Ashok> - People don't care about architecture (1)

   <Ashok> - Persuading community that arch. matters (1)

   <Ashok> - Helping WGs/involvement in W3C

   <Ashok> - Education of Community (4)

   <Ashok> - Enforcement (1)

   <Ashok> - Getting comments / spec process


   <Ashok> - Threats (3) and opportunities (2)

   <Ashok> INTERNALS

   <Ashok> - Time/money/efforts

   <Ashok> - Thrashing / Ratholing

   noah: some people have a short-term/long term

   masinter: if you're a browser making, you care about browsers,
   not about semantic web
   ... it's about breadth of scope
   ... we're trying to bring a broader perspective, for
   applications they don't think are important

   <masinter> i think the main pushback on "architecture" is that
   a broader architecture presents opportunities for others to
   innovate (which they don't care about) or about applications
   they don't care about

   <masinter> so if you're doing document production, you might
   not care about 3D, and if yo'ure doing a browser, you don't
   care much about email, and architectural constraints for
   supporting applications they don't care about means introducing
   requirements for features that don't manage

   <masinter> you are tempted to characterize this as a "short
   term" vs "long term", but I think it's narrow vs. broad

   Ashok: on reacting to the changing web
   ... I was involved in 'Headlights' effort
   ... they had five Headlight areas, one of which was 'Cloud'
   ... which is a hot topic now
   ... we argued about whether we should do cloud
   ... we thought W3C didn't have anything to offer
   ... they all use URIs, all use REST, but cloud is application
   ... we thought the W3C should be doing fundamental web
   technologies, to use in cloud, in big data or elsewhere
   ... otherwise, it's out of the comfort zone of W3C

   noah: we should focus our TAG improvements around these themes
   ... is there anything else that we should have mentioned?
   ... over the next little while we should remind ourselves and
   focus around these clusters

   masinter: we've done this analysis, shouldn't we try to
   identify actions

   jenit: what actions do you see (Larry), so we can have those as
   input for anything we do tomorrow?

   masinter: a set around engaging leaders in the community
   ... not people who subscribe to www-tag, but community of the
   ... we could go and talk at conferences, but that's not
   ... instead, target chairs of working groups, team members
   ... talk to dozens of people in leadership positions rather
   than hundreds

   Ashok: should we have a TPAC presentation?

   masinter: I'd like to get better feedback, based on data, on
   our work
   ... for example, web stats on how many people are reading these

   noah: I'm not sure that all leaders are chairing WGs
   ... I'm concerned of not getting balanced feedback
   ... like an advisory group, to look at what we're doing

   masinter: I was going to ask W3C for a programme manager to
   work to survey the community for a while
   ... to help prioritise our work
   ... we need to decide what we work on, so that what we work on
   matches the needs of the community
   ... and we should be explicit about doing things that the
   community doesn't think they need, and why they really should

   noah: it would be great to do an organised job to get that
   ... I don't want it to take a lot of my time
   ... they are going to call me a lot, to coordinate
   ... let's make sure it would actually work

   jar: could we just talk about the ideas?

   Ashok: if we agree that this is what we ought to do, we should
   do it regardless of noah's schedule

   masinter: second thing is how we publish what we have worked on
   ... there's the presentation of the website, to find out what
   we do
   ... it's hard to find out
   ... a lot of draft findings, only a few findings, it's hard to
   find out what the latest thing we've said is
   ... then there's the finding vs. recommendation issue
   ... a recommendation reflects community agreement, said on
   behalf of community
   ... sometimes what we do needs to get engagement from community
   even wider than W3C community
   ... would be nice if chairs needed to look at architectural
   ... I don't know how to solve those problems
   ... but asking someone else to change the way that they work is
   difficult, they need to be involved in that change

   plinss: it's good having putting documents through the Rec
   process, because you have to identify WGs from which you need

   masinter: then there's how we get selected, how many TAG
   members there are, whether they are funded and so on
   ... I don't have hope for additional funding

   ht: I thought it was worth putting down as a marker
   ... to say that if W3C did get more money, the TAG might be a
   place to spend it

   masinter: what we work on, how we publish it, how we work
   ... spending time on administrative topics, how we organise
   ... those things are more easily adaptable, we can try
   different internal organisations at will
   ... it's harder changing the way we present and interact with
   others, and the way we prioritise
   ... I think we should put more priority on how we work
   externally, because it will affect how we work internally
   ... more blog posts, for example, would change our internal

   noah: is there anything that you would say that isn't on the

   masinter: the one thing is increasing the priority of our
   liaison work
   ... especially with IAB
   ... OASIS doesn't have an architecture committee, does it?

   noah: do we only want to liaise with people who are organised
   like we are?
   ... we should liaise for example with WHATWG

   masinter: the principle is, do they talk about architectural
   issues in the same way that we do
   ... they write vocabulary/architecture documents like we do,
   lots of opportunity for cross-review
   ... and coordination

Positioning of Web and Native applications


     [31] http://www.w3.org/2001/tag/2012/06/12-agenda#nativevsweb

   masinter: the main point from this was the death of the
   application layer
   ... native vs web app was one question among many

   noah: so Hannes wasn't asking us to take on long-term work
   ... I still think it's an interesting question
   ... is this a promising area? it feels like it is to me
   ... web vs. native, and within the web app, things that used to
   be managed at the protocol level are now being managed through

   masinter: the trend started with layering on top of HTTP
   ... and it's going rapidly in that direction

   noah: my inclination is to go into this, to indicate tradeoffs

   masinter: used to think of 7 layers
   ... the layers are still here
   ... you would draw this as an hour glass, because everything
   went through TCP/UDP
   ... doesn't matter what's above, what's below, so long as
   everything went through that neck
   ... rich applications in layers above that hour glass

   ht: and that bottleneck being where it is meant there was work
   for the IETF in designing protocols
   ... right above TCP/UDP you had protocols

   masinter: in the new diagram, the bottleneck is at the protocol
   layer, we have HTTP, WebRTC

   ht: IETF doesn't need to design protocols any more
   ... that was the emotional subtext to the discussion at the
   ... "what is there for us in this new world"

   masinter: and how to manage the parts they're doing

   timbl: the TCP bottleneck meant that underneath the bottleneck,
   stuff underneath could change without us having to change our
   ... does this top bottleneck have this property as well?
   ... could we make huge changes to the way HTTP works?

   ht: SPDY is evidence that you can

   timbl: otoh we've learned that apps have to look a little bit
   down through the bottleneck

   ht: SPDY is about avoiding a bit of that
   ... to avoid having to play games to get parallelism

   timbl: in the LDP model, the bottleneck is HTTP+RDF+SPARQL
   ... the application level, the design is in ontologies and
   rules for their use

   noah: that only says so much about how we optimise delivery of
   a video stream

   timbl: video is an independent part of the web

   noah: video benefited from the old hourglass

   masinter: I disagree, they discovered because of firewalls they
   couldn't deliver video how they needed to
   ... to get real-time stuff

   noah: a whole lot of TV goes through the hourglass

   Ashok: we're speaking between native apps and web apps
   ... what's the difference?

   <masinter> RTP, RTMP, now MPEG-DASH using hTTP

   <masinter> MPEG-DASH is delivering streaming video using HTTP
   using the top neck

   <masinter> two hourglass necks


     [32] http://en.wikipedia.org/wiki/Dynamic_Adaptive_Streaming_over_HTTP

   noah: devices have APIs
   ... native apps are written to exploit the platform APIs
   ... not tuned to write application that run on a different
   device or platform
   ... released in lock step with device releases
   ... people wrongly associate it with marketplaces, and charging

   Ashok: it does not run in the browser

   noah: but some use Webkit components for example

   Ashok: does it work with a server?

   noah: many do

   Ashok: can you access another external website?

   noah: some do some don't
   ... I bet weather apps use RESTful APIs to access their data
   ... ESPN apps appear purely native, and you then get a web
   page, no back button

   plinss: not a full interactive browser

   noah: some intercept links, some don't

   Ashok: the only difference I'm seeing is that they don't run in
   the browser

   noah: that has huge implications

   masinter: no it doesn't

   Ashok: so it doesn't run in browser, and it has priviledged
   access to hardware?

   noah: plugging iPad into mixing device
   ... we have nothing in the web space to do that
   ... people are building businesses on that

   Ashok: I'm trying to figure out what the differences are

   noah: native priviledged control of hardware

   jar: but this could also apply to communication with a server
   ... proprietary protocols between two parts of the system
   ... if you have an application in mind and it involves a
   client/server, your choice is affected by multiple

   <masinter> [33]http://phonegap.com/

     [33] http://phonegap.com/

   <masinter> Apache Cordova (aka PhoneGap) uses web
   infrastructure to build apps

   <masinter> "proprietary protocols" => "private device APIs"

   <masinter> WebIDL should be in scope for architecture

   Ashok: the part that uses the hardware, the special hardware,
   that *has* to run on the device

   jar: the special hardware could be on the server

   masinter: I have 40 native apps on my phone, none of which
   access specialised hardware

   noah: analogy between relationships between Macs and
   ... the web community needs to support multiple devices
   ... and interfaces with them

   jar: seems like there are multiple considerations that would
   lead to deploying as native vs web
   ... maybe hardware is one of them, but there will be a bunch of
   ... these issues are orthogonal to interoperability

   masinter: I hear Robin saying we shouldn't talk about this
   because there are WGs trying to make native apps irrelevant
   ... then there are articles saying that companies build native
   apps is because of monetisation

   jar: I think we could list four considerations for making the

   jenit: these issues are well known

   masinter: I've read that the main issue is monetisation
   ... and we have nothing to say about that anywhere within W3C

   noah: maybe we need to help W3C to see this

   <masinter> the motivation for innovation in the web is

   <masinter> rights management video is also driven by

   <masinter> I want to correct what i said. The W3C *is* talking
   about monetization in the context of DRM for video

   timbl: the whole webapps drive at W3C has been going for a
   ... the push that people should use webapp technology is
   several years old
   ... we must have talked about trusted apps
   ... that's one example where web apps aren't trusted apps
   ... making the list of reasons is a good idea
   ... putting it in order is a silly idea, because everyone is
   ... many different markets, many different kinds of apps
   ... based on different criteria
   ... whole tranche that cares about monetisation, another that
   really doesn't care
   ... I think we should map pros and cons, or point to it
   ... and flag any things that give us particular concern
   ... we've said that payment protocols is a gap

   masinter: it isn't true that the w3c doesn't talk about
   monetization. videos. DRM, subscription
   ... we haven't said much about book or text content [or

   plinss: A lot of this interesting things here, but why to the
   TAG? Any architectural issues?
   ... What could lead to us having any effect?

   noah: Having a task group go off and look at this might help

   timbl: I thought this was a discussion about the TAG making
   sure that the webapp in the future, w3c to fix any
   architectural gaps in the future

   plinss: There are other people finding the gaps and filling
   them in

   timbl: There's an activity

   masinter: The IAB had a presentation on the death of protocols.
   Concerned about extensibility in the architecture. New
   hourglass in the stack, now at the web, therefore apps are
   being defined in terms of the web rather than in terms of TCP,
   ... making concerns of infrastructure folks harder to
   penetrate. E.g. traffic shaping, you can't tell the nature of
   the content because of http multiplexing. Wait, W3C, why are
   you doing all of this, that makes our life hard?

   noah: Helping the w3c to focus and validate to make web-based
   platform successful. But LM is saying (something else)

   masinter: I don't think we can affect marketplace success, but
   we can document impact of what is being standardized. E.g. the
   APIs. We're analyzing privacy considerations. Useful regardless
   of whether native or web

   timbl: IAB question is a very interesting. They should get over
   it, by which I mean: They used to have the luxury of looking at
   port numbers. When the IT people started looking at port
   numbers, they were cheating. I understand why it's been useful
   in categorizing traffic. Now the distinctions are hidden...
   ... now we have pages and proxies... the whole point is the
   heavy use of layering

   masinter: Now we take what we used to do with ports and
   streams, and figure out how to do it in the new regime

   noah: Suppose we want to add traffic class to HTTP. I would
   think IETF would show that to us in draft form... why wouldn't
   they take the lead?

   masinter: They sent the message to the entire IETF community.
   We're just not monitoring that list

   Ashok: How would we write trusted apps that don't run in the
   browser in a portable way?

   noah: There are things vendors intentionally make hard, so that
   access is difficult

   Ashok: We write standards that work within the browser. Should
   we start thinking about standards for native apps.

   timbl: there are lots of apps where the browser is the desktop,
   like Boot-to-chrome
   ... I can't think of any architectural questions, except for
   the trusted app issue

   masinter: very frequently there's a service available on the
   web and in the native app
   ... it has more trust, it has an icon, you don't have to log in
   ... if your goal is: does it use standard protocols, is it
   interoperable? yes, it does
   ... you can send URLs, and it will bring up the app or the
   ... it's ok to develop standards that aren't for browsers
   ... it's reasonable

   timbl: at first blush I don't see what requirements there would
   be if I were writing a native app that I don't have writing a
   web app
   ... I need to look at local storage

   Ashok: Javascript would have to execute natively on the

   timbl: there would have to be a stripped down browser, one
   without the chrome
   ... what's hard with that?

   masinter: that's what Windows did

   Ashok: a skinny browser

   timbl: a browser that's fat in features, the only thing that's
   missing is the window

   noah: IE5 did that
   ... the native app might not be browser based
   ... maps might be an example
   ... if you have a Google Maps URI, the phone looks at the URI,
   cheats, decides to open a specific maps app
   ... no way to to tell whether it's using REST/HTTP

   <masinter> so why should we care whether W3C specs are being
   used for things that aren't run in the browser? After all, "web
   services" didn't run in the browser

   Ashok: but it uses the URI

   plinss: if you click a Google Maps link in a browser, it
   launches the native app

   noah: it feels more native than wrapped web
   ... where should we go with this?

   Ashok: I'm not hearing any direction

   noah: we did have a contact from Hannes, should we have a
   ... if we have more TAG work, we should have focused analysis
   with a goal

   masinter: I have what I think is a new thought
   ... W3C often works on things that have nothing to do with
   ... XML protocol for example
   ... why should we care that these standards are being used by
   native apps?
   ... people are spending more money building native apps

   noah: you imply those native apps are rendering HTML
   ... and if they're not, our stuff is totally irrelevant
   ... I can't tell if they are standalone, if they use HTTP

   jar: I think we should be looking at the interoperability
   ... some are to do with the internet and some aren't
   ... there are all kinds of standards organisations
   ... that's different from getting work done as a developer

   masinter: the question is what should be in scope for W3C
   ... what's the scope of the architecture?
   ... what W3C does vs what we expect others to do
   ... that's not entirely up to the TAG
   ... but we might have some input on it

   noah: what should our next step be?

   masinter: I suggest we put this on our status report to Jeff
   ... I think we have new information, that the IAB would like to

   noah: he'll immediately ask what we're doing about it
   ... what should we do?
   ... is someone going to step up to analyse the area and provide

   <masinter> should we try to define what we think W3C's scope

   <masinter> i'm convinced by this discussion that native apps
   using web technology should be in scope for W3C and the TAG and

   <masinter> and that DRM for native apps might be a candidate
   enabling technology

   <masinter> and there might be some 'best practices' that would
   have to be review URIs, security, login

   ht: get something on the broken record
   ... there's the potential for a big revolution
   ... providing apps over the web is repurposing
   ... without any rearchitecturing
   ... it might be that now we know what we want, we should design
   one and ship one
   ... Flash was designed much more to be that mechanism for
   delivering apps
   ... if the idea of a distributed deployment platform gets
   ... then we need to pay attention
   ... different from web browsers, which have a different goal,
   and weren't designed to be a distributed deployment platform

   <jar> Evolution of Javascript is repeating evolution of Java
   (somewhat out of order)

   <masinter> [34]http://phonegap.com/about

     [34] http://phonegap.com/about


     [35] http://phonegap.com/2012/04/12/rolling-releases-how-apache-cordova-becomes-phonegap-and-why/

   timbl: the idea of redesigning from scratch sounds like a bad
   ... but we could look at what it would look like if we did

   jar: history is repeating itself, so we could look at that, eg
   Java, Adobe

   timbl: I'm not interested in the TAG doing a redesign, except
   as a thought experiment to identify we might be missing
   ... to do a course correction

   <masinter> . RESOLUTION: The TAG says that Native apps using
   web technology are in scope for W3C and the TAG

   noah: does someone want to propose direction?
   ... the more work we can do offline, the better
   ... we need someone to do legwork to bring in some facts
   ... I propose we have no actions, except that we owe Hannes an
   ... Larry, did you want to propose a reply to Hannes?

   <masinter> . RESOLUTION: The TAG says that Native apps using
   web technology are in scope for W3C and the TAG, and that the
   TAG will consider architectural questions, and that the
   community is encouraged to bring architectural questions, in
   this space.

   <masinter> . ACTION: Larry to reply to Hannes summarizing the
   discusison, pointing to th eminutes, and asking him if he has
   any more specific questions.

   <masinter> ACTION: Larry to reply to Hannes pointing to the
   minutes, summarizing the discussion, and asking him if he has
   any more specific questions. [recorded in

     [36] http://www.w3.org/2001/tag/2012/06/13-minutes#action03

   <trackbot> Created ACTION-719 - Reply to Hannes pointing to the
   minutes, summarizing the discussion, and asking him if he has
   any more specific questions. [on Larry Masinter - due

   <masinter> [37]http://incubator.apache.org/cordova/

     [37] http://incubator.apache.org/cordova/


   noah: tentatively between 7-10th Oct in UK
   ... agreement on 7-9th Oct in London?

   <scribe> ACTION: Noah to make sure we have somewhere to meet in
   London 7-9th October [recorded in

     [38] http://www.w3.org/2001/tag/2012/06/13-minutes#action04

   <trackbot> Created ACTION-720 - Make sure we have somewhere to
   meet in London 7-9th October [on Noah Mendelsohn - due

   RESOLUTION: TAG will meet in London 7-9th October

   noah: we may meet on 21st June
   ... but cancel meetings of 28th June & 5th July
   ... but have a meeting on 12th July
   ... TPAC is 29th Oct - 2nd Nov
   ... in Lyon
   ... I probably won't be able to get there
   ... December meeting, latest is 20th December

   Ashok: maybe January instead?

   noah: possibly 8-10th January in California
   ... Timbl not free

   (lots of date discussion)

   (18-20th December out as TimBL unlikely)

   (early Jan difficult for Henry & Noah before lectures

   noah: we have a room at TPAC even though I'm unlikely to make

   (Tim, Ashok, Peter, JeniT likely at TPAC)

   (Larry possible, Henry unlikely)

TAG Priorities 2012

   noah: we're doing good work on fragids
   ... taking serious run at ISSUE-57
   ... publishing & linking is kind of ok, except main assignee
   (JeniT) also doing the other main priorities

   <scribe> ACTION: Noah to update product index to target date on
   publishing & linking [recorded in

     [39] http://www.w3.org/2001/tag/2012/06/13-minutes#action05

   <trackbot> Created ACTION-721 - Update product index to target
   date on publishing & linking [on Noah Mendelsohn - due

   <jar> ACTION jar Review 'publishing and linking' due 2012-08-01

   <trackbot> Created ACTION-722 - Review 'publishing and linking'
   due 2012-08-01 [on Jonathan Rees - due 2012-06-20].

   noah: my concern is that 9 people working 20% time should be
   doing more work
   ... are any of the medium priority work items things we should
   move up to high priority?

   masinter: I'd prioritise based on what we talked about this
   morning, focus on things that get us engaged with the community
   we're trying to serve

   noah: what technical topics would you prioritise based on that?

   masinter: engagement is important, so we should raise priority
   of web architecture pages
   ... it's simple, and gains engagement

   noah: the only thing that's held that back is that we assigned
   actions and only Jeni's done it
   ... we need to get members who take on the actions to buy in to
   doing them

   masinter: I think people work on things that you feel other
   people care about

   jar: people should work on things they are motivated to work on

HTML/XML Unification


     [40] http://lists.w3.org/Archives/Public/www-tag/2012Jun/0051.html

   noah: what's happened since we last met, and what should happen

   Norm: we met and chatted in December
   ... a bunch of us were in Prague for XML Prague
   ... Jeni, Robin & Anne (and me) thought setting up a community
   group in this space would be a good idea
   ... Anne agreed to edit
   ... I agreed to chair
   ... there was a flurry of email, and there's Anne's draft based
   on XML5
   ... I have been behind, but I caught up yesterday
   ... I've tried to pull out the larger issues that I don't think
   are in the draft or where we have consensus
   ... next step would be to try to get more review of Anne's
   draft within the group
   ... to see whether that draft satisfies some of the
   requirements we have
   ... we could spend time on use cases if we were more diligent
   ... I'm not sure we could get that much discipline, but I'll
   make a stab at it

   noah: when we met at Tim's, we reviewed the TF report
   ... at the time, you said you wanted the TAG's help to get it
   published as a Note
   ... it was published on Feb 9th
   ... just before XML Prague
   ... most of what you've focused on is Anne's presentation at
   XML Prague & XML-ER

   Norm: the group of people who are willing to work on this
   problem, have voted with their feet to work on something more
   concrete, along the lines of Anne's work
   ... the TF was useful in framing the discussion
   ... but the TF has done all it will successfully do
   ... we should be looking at engaging the XML-ER folks

   noah: the TF was a big deal for the TAG
   ... are we happy to move in the direction that Norm is

   Norm: we do need to get use cases out there to help make
   ... for example, the case of an interactive editor
   ... there are some people who think that's critical and others
   that think it isn't
   ... that will help drive refining something like Anne's draft


     [41] http://www.w3.org/2001/tag/products/htmlxmlunification.html

   noah: I propose we close out the HTML/XML work
   ... declare success on this bit of the work

   Norm: I'm agnostic
   ... in the perfect world, we might want to do more work along
   the lines that was originally envisaged
   ... but we should move in the direction of the community

   noah: we need to make a decision not to pursue other aspects
   from the report

   timbl: unless there's some huge thing that people haven't
   noticed, we should follow what the community is doing

   ht: my energy is going to go on monitoring polyglot
   ... because it's the XHTML constituency that we have
   responsibility towards

   Norm: that's a good and wise thing to do

   <noah> . RESOLUTION: The TAG notes the publication of the
   HTML/XML Task Force Report on 9 Feb 2012, the focus of the
   community on XML-ER. We thank Norm Walsh for his wonderful
   assitance to the TAG, and close our formal project on HTML/XML.

   ht: as long as I can continue to monitor polyglot, closing is

   noah: any objections?

   <noah> RESOLUTION: The TAG notes the publication of the
   HTML/XML Task Force Report on 9 Feb 2012, and the current focus
   of the community on XML-ER. We thank Norm Walsh for his
   wonderful assitance to the TAG, and close our formal project on

   noah: would it be helpful to talk with the TAG on XML-ER?

   <noah> Discussing

   <noah> Point 1: declarative vs imperative rules for the mapping
   from character sequence to (fixed up) tree

   Norm: the biggest question is the first one in my email: how
   can we describe what this process of reading characters and
   making a tree is?
   ... is it a processing model or a declarative model?
   ... the other issues are smaller
   ... is there a pre-processor that does clean-up and then uses
   an XML parser
   ... or is it a procedural/streaming process?

   ht: it's stupid to define it procedurally

   noah: there was a similar decision in the HTML spec

   ht: it wasn't an explicit decision for HTML

   noah: for HTML, the asynchronous scripting environment might be
   legitimate grounds for saying it's hard to define this
   ... but that doesn't apply in XML-ER
   ... there's no asynchrony
   ... Norm, do you think there are good technical reasons for
   speccing it procedurally rather than declaratively?

   Norm: I don't think there are technical reasons, but Anne's
   influenced by the HTML parsing method
   ... and he's not interested in editing anything other than in
   that style

   <masinter> [42]http://dev.w3.org/html5/markup/ is declarative

     [42] http://dev.w3.org/html5/markup/

   noah: I'd love to see it done declaratively, but I don't think
   we should fight it now
   ... I wish I had the time to do it

   Norm: if someone looked at Anne's draft and picked some subset
   and rewrote it using declarative rules
   ... doing a large enough section so that other people in the CG
   who aren't familiar enough with declarative approach might be
   shown how it works

   masinter: HTML5 is defined declaratively, there's a document
   that does it

   <masinter> [43]http://dev.w3.org/html5/markup/

     [43] http://dev.w3.org/html5/markup/

   Norm: there's an exposition of how it's done, but it's not

   noah: it's not a declarative mapping to a DOM tree

   ht: it's also incomplete

   noah: the goal with XML-ER is to map a character string to a
   DOM tree
   ... the document you're pointing at focuses on legal HTML for
   good reasons
   ... the target for XML-ER is illegal XML

   masinter: in the email discussion I was not understanding the
   use case that XML-ER is intending to address

   Norm: someone sends you a document that they've served as XML,
   but isn't well-formed
   ... you want to process it with XSLT

   masinter: what's the use case for that?

   noah: I thought a use case was that someone had written XHTML
   and they've made mistakes, and they hate the brittle
   stop-on-error model
   ... so you would have an alternative browser mode, that would
   process XHTML and keep going

   masinter: that's not enough of a use case, because it's a
   personal preference

   noah: people are using HTML because XHTML kept breaking for

   masinter: give me a scenario where something doesn't work,
   where the requirements of the use case are that you need XML-ER

   timbl: an RSS aggregator

   masinter: one that's getting XHTML?

   timbl: it contains embedded HTML5

   Norm: another one is an XML database company, which wants to
   ingest documents
   ... that purport to be XML
   ... 30% of them are broken
   ... you can do proprietary attempts to fix the markup
   ... having a standard would enable two independent companies to
   ingest the documents and build the same trees
   ... which would enable XML databases, XSLT processors etc to
   work on them
   ... we would get better interoperability across these
   ... There is LOTS of broken XML out there

   masinter: is it a requirement that it's consistent with the
   HTML parser?

   Norm: as compatible as it can be without torturing the spec

   masinter: for these use cases

   Norm: the requirement is that the processor processes it
   without falling over

   ht: this is a perfect demonstration for why a declarative
   definition would be better
   ... we could process with both an XML-ER and HTML parser to see

   masinter: is there a requirement that they be equivalent? I
   think I've heard not

   Norm: the vast majority cases are really easy to fix
   ... missing angle brackets, quotes and so on
   ... the focus is on recovering bad data
   ... we don't want to get into "correct" interpretations
   ... we need to fix up the obvious mistakes

   noah: the RSS case is different: it's divided between what
   humans see and those they can't
   ... automatic processes on sensitive documents is risky

   Norm: if you have mission critical data going through this, you
   deserve what you get

   noah: if we can refine the use case to exclude these scenarios

   Norm: you can't tell people how to use your spec

   noah: but you can warn them

   <masinter> Can this be defined as a sequence of fixup

   <masinter> which isn't either declarative or procedural

   timbl: I don't think we have to warn people about obvious

   Norm: the spec should say that correcting markup errors
   necessarily introduces the possibility of saying something the
   author didn't intend, but no more than that

   masinter: there's another way of defining the spec as fix-up

   noah: if I were doing it declaratively, I think I'd do it as
   fix-up transformations

   masinter: then you don't have to worry about the DOM tree at
   ... you can have a pre-processor that does the first fixups

   ht: that's how tagsoup works
   ... which the CG is ignoring

   <masinter> what's wrong with tagsoup?

   masinter: we should ask the XML-ER CG why they are ignoring it

   noah: the HTML5 spec took into account what browsers were using
   and other inputs

   ht: I think Hixie only looked at what the browsers were doing

   noah: this fits into that path

   <masinter> if there's a widely deployed implementation that
   meets the requirements, why isn't compatibility with that
   system a possibility? Does tagsoup work for the use cases?

   Ashok: does tagsoup handle these use cases?

   ht: tagsoup is best-of-breed, nearly the only one
   ... it has two phases: a micro phase and a macro phase
   ... the micro phase is done at the level of angle brackets and
   equal signs
   ... macro phase at open & close tag level

   <noah> ACTION: Noah to record final closing of work on HTML/XML
   Unification in product page Due 2012-08-01 [recorded in

     [44] http://www.w3.org/2001/tag/2012/06/13-minutes#action06

   <trackbot> Created ACTION-723 - Record final closing of work on
   HTML/XML Unification in product page Due 2012-08-01 [on Noah
   Mendelsohn - due 2012-06-20].

   gsoup/1.2 ?

     [45] http://mvnrepository.com/artifact/org.ccil.cowan.tagsoup/tagsoup/1.2

   ht: not quite well-formedness vs. validity

   Norm: tagsoup is also table driven

   ht: yes, but it does useful work with an empty table

   JeniT: is it specced anywhere?

   ht: there's something approximating a spec
   ... and I've done work with a grad student to make the table
   ... so it's an open question how well tagsoup would do at
   satisfying the RSS use case


     [46] https://groups.google.com/forum/?fromgroups#!topic/tagsoup-friends/Y2qA29CM4n4

   ht: I don't know which use cases the XML-ER CG has written down

   Ashok: but take MarkLogic, where they really need this

   " ?

     [47] http://groovy.codehaus.org/api/groovy/util/XmlSlurper.html

   ht: Norm, why doesn't MarkLogic use tagsoup?

   Norm: probably because it's written in Java

   <jar> "The semantics of TagSoup are as far as practical those
   of actual HTML browsers."

     [48] http://ccil.org/~cowan/XML/tagsoup/#what

   Norm: I think we have tidy incorporated

   <timbl__> "BeautifulSoup is closer to my TagSoup, but is
   written in Python and returns a parse tree. I believe its
   heuristics are hard-coded for HTML. There is a port to Ruby
   called RubyfulSoup." -- [49]http://ccil.org/~cowan/XML/tagsoup/

     [49] http://ccil.org/~cowan/XML/tagsoup/

   noah: anything else we should be talking about?

   JeniT: media type maybe?

   Norm: yes, we're talking about processing documents where the
   media type is a lie: it says its application/xml when it isn't

   noah: the authoritative metadata finding suggests that if the
   user has input, that's OK

   Norm: yes, one thing is to try with an XML parser, and then try
   again with the XML-ER parser if it fails

   masinter: it depends on context

   Norm: one of the goals of a parser is that it should produce
   the same thing as an XML parser on a well-formed XML document

   <noah> Tag finding on authoritative metadata, pertinent

     [50] http://www.w3.org/2001/tag/doc/mime-respect-20060412#silent-recovery

   masinter: is this intended for XHTML or all XML?

   <masinter> is this really intended for ALL XML?

   <noah> Good practice: Web agents SHOULD have a configuration
   option that enables the display or logging of detected errors.

   <masinter> both of the use cases were HTML

   Norm: intended for all XML, on XHTML I think I'd just use an
   HTML parser


     [51] http://www.w3.org/2001/tag/doc/mime-respect-20060412#consent

   <noah> Constraint: An agent MUST NOT ignore or override
   authoritative metadata without the consent of the party
   employing the agent.

   masinter: what kinds of documents would you be reading into a

   Norm: some horrendous stuff from database dumps and logs and so
   on and on

   <masinter> question is what the nature of the errors are and
   where they came from

   <ht_home> TagSoup references:

     [52] http://home.ccil.org/~cowan/XML/tagsoup/tagsoup.pdf
     [53] http://home.ccil.org/~cowan/XML/tagsoup/

   <masinter> RSS feeds are different

   Norm: that's where I've encountered this problem

   <ht_home> Pyxup (declarative version from me):

     [54] http://conferences.idealliance.org/extreme/html/2007/Thompson01/EML2007Thompson01.html

   noah: I've added links to the authoritative metadata finding
   where we talk about this
   ... other than that, I don't think we're discouraging it

   masinter: what about HTML Tidy?

   ht: it's even less documented
   ... you could ask Dave Raggett to help you decompile it

   timbl: I don't think Dave is a committer now
   ... you could fit it into the test suite

   noah: the fixups you might want to do would depend on the use
   ... Tidy was mostly used by authors to clean up what they'd

   <ht_home> I believe the open source Tidy project is dormant

   noah: but stuff in the HTML spec is done by the user agent

   ht: I use Tidy to convert HTML to XHTML so I can work with it

   timbl: I use Tidy to help me publish as polyglot

   <timbl__> [55]http://tidy.sourceforge.net/

     [55] http://tidy.sourceforge.net/

   <timbl__> HTMLtidy - Revision 1.46 - Wed Mar 25 21:37:11 2009
   UTC (3 years, 2 months ago) by arnaud02

   noah: is there any followup from us?

   Norm: I'm going to try to get the group re-energised
   ... I'm inclined to say that anyone in the TAG who wants to
   influence direction should join the CG
   ... I can keep coming and giving status updates

   <noah> [56]http://www.w3.org/community/xml-er/

     [56] http://www.w3.org/community/xml-er/

   (Norm is directed to upload a picture)

   <masinter> given deployment of tagsoup and xmltidy, it is
   likely that they won't go away, and thus the goal of the group
   is there a standard for fixup won't be accomplished

   Ashok: how active is the group?

   Norm: there was a flurry of mail earlier in the year, and it's
   been dormant over the last few months
   ... I'm going to try to get it going again

   noah: on the TAG side, we just closed down HTML/XML work: we're
   not doing anything formally now
   ... do we need to follow up more formally?

   masinter: I think we should give them feedback to look at
   tagsoup and to ask about use cases

   Norm: if someone wants to chime in about tagsoup, that would be

   <Norm> (Norm reports that there's a picture in his W3C account
   and it doesn't show up on that page and that isn't his fault,
   he so asserts)

   ht: it's easier to give input if there are use cases and test

   noah: should we have an action?

   ht: we don't need to: Norm's heard, Jeni's heard, Robin will
   read the minutes

   noah: we've decided we don't need to do any more
   ... thank you again to Norm for all his work

   Ashok: I have a fear that this work will just dribble away

Issues for Thursday

   <noah> Larry wants us to look at RFC 4395bis when we talk about
   scheme proliferation -- it attempts to facilitate scheme

   masinter: if you talk about proliferation of schemes, please
   look at RFC 4395bis on scheme registration guidelines
   ... we want to make it easier to register schemes
   ... because the consensus of IETF is that making it hard to
   register schemes is lots of unregistered schemes
   ... there's a lot of reasons why you wouldn't want to deploy
   schemes or use schemes
   ... but that's different from not registering them
   ... it's not much of a risk when you have a scheme that isn't

   timbl: the only risk is if two people take the same
   unregistered scheme


     [57] http://tools.ietf.org/id/draft-ietf-iri-4395bis-irireg-04.txt

   masinter: I like narrowing CSS prefixes to extracting
   documentation of deployment plan in CSS documents and make it a
   separate document
   ... then see if we can extract important aspects of deployment
   ... as hints for how to plan for extensibility
   ... some people think CSS prefixes is successful, and we should
   capture what works about it


Summary of Action Items

   [NEW] ACTION: Ashok to propose goals and success critera for
   TAG work on architectural issues relating to storage sync,
   linked data, etc. Due 2012-08-15 [recorded in
   [NEW] ACTION: Ashok to propose outline for possible TAG
   document (finding or rec) on architectural issues relating to
   storage sync, linked data, etc. Due 2012-07-15 [recorded in
   [NEW] ACTION: Larry to reply to Hannes pointing to the minutes,
   summarizing the discussion, and asking him if he has any more
   specific questions. [recorded in
   [NEW] ACTION: Noah to make sure we have somewhere to meet in
   London 7-9th October [recorded in
   [NEW] ACTION: Noah to record final closing of work on HTML/XML
   Unification in product page Due 2012-08-01 [recorded in
   [NEW] ACTION: Noah to update product index to target date on
   publishing & linking [recorded in

     [58] http://www.w3.org/2001/tag/2012/06/13-minutes#action02
     [59] http://www.w3.org/2001/tag/2012/06/13-minutes#action01
     [60] http://www.w3.org/2001/tag/2012/06/13-minutes#action03
     [61] http://www.w3.org/2001/tag/2012/06/13-minutes#action04
     [62] http://www.w3.org/2001/tag/2012/06/13-minutes#action06
     [63] http://www.w3.org/2001/tag/2012/06/13-minutes#action05

   [End of minutes]

    Minutes formatted by David Booth's [64]scribe.perl version
    1.136 ([65]CVS log)
    $Date: 2012/06/19 19:17:58 $

     [64] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [65] http://dev.w3.org/cvsweb/2002/scribe/

Jeni Tennison

Received on Tuesday, 19 June 2012 19:20:20 UTC