See also: IRC log
<scribe> scribenick: masinter
<scribe> scribe: Larry Masinter
noah: Storage including synchronization
<plinss> 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
<trackbot> 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
<darobin> 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 version
... 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 platform
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> http://en.wikipedia.org/wiki/CAP_theorem
<noah> 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 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 architecture
jeni: we're looking at people trying to get out of walled garden
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 goals.
masinter: The only interesting idea I've heard is for the L D 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 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 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
<trackbot> 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
<trackbot> 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
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 conclusions
... as chair I see operational things that are boring but are important
... 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> 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 second
... 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)
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)
((ashok is typing outline))
noah: we should find some middle ground to find some high-value things
<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> ENGAGEMENT
<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> CHANGING WEB
<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 management
... 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 web
... we could go and talk at conferences, but that's not efficient
... 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 documents
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 feedback
... 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 recommendations
... 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 feedback
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 anyway
... more blog posts, for example, would change our internal working
noah: is there anything that you would say that isn't on the board?
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
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 Javascript
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 IETF
... "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 code
... 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 Update
... 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
<masinter> 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 considerations
<masinter> 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 Laserwriters
... 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 others
... 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 decision
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 monetization
<masinter> rights management video is also driven by monetization
<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 while
... 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 different
... 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 software]
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 browser
... 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 platform
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 response?
... 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 browsers
... 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 problems
... 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 know
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 goals?
<masinter> should we try to define what we think W3C's scope is?
<masinter> i'm convinced by this discussion that native apps using web technology should be in scope for W3C and the TAG and AWWW
<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 traction
... 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> http://phonegap.com/about
<masinter> 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 idea
... 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 answer
... 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 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 2012-06-20].
<masinter> 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 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 2012-06-20].
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 scheduled)
noah: we have a room at TPAC even though I'm unlikely to make it
(Tim, Ashok, Peter, JeniT likely at TPAC)
(Larry possible, Henry unlikely)
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 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 2012-06-20].
<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
<noah> http://lists.w3.org/Archives/Public/www-tag/2012Jun/0051.html
noah: what's happened since we last met, and what should happen next?
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 signalling?
Norm: we do need to get use cases out there to help make choices
... 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
<noah> 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 fine
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 HTML/XML.
noah: would it be helpful to talk with the TAG on XML-ER?
<noah> Discussing lists.w3.org/Archives/Public/www-tag/2012Jun/0051.html
<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 declaratively
... 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> http://dev.w3.org/html5/markup/ is declarative
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> http://dev.w3.org/html5/markup/
Norm: there's an exposition of how it's done, but it's not declarative
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 them
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 applications
... 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 transformations?
<masinter> which isn't either declarative or procedural
timbl: I don't think we have to warn people about obvious things
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 transformations
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 all
... 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 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].
<jar> 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 declarative
... so it's an open question how well tagsoup would do at satisfying the RSS use case
<masinter> 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
<masinter> "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." 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." -- 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 section: 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
<noah> 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 database?
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: http://home.ccil.org/~cowan/XML/tagsoup/tagsoup.pdf, 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): 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 case
... Tidy was mostly used by authors to clean up what they'd written
<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__> 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> 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 good
<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 suites
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
<noah> Larry wants us to look at RFC 4395bis when we talk about scheme proliferation -- it attempts to facilitate scheme registration.
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 recognised
timbl: the only risk is if two people take the same unregistered scheme
<noah> 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 plan
... as hints for how to plan for extensibility
... some people think CSS prefixes is successful, and we should capture what works about it
ADJOURNED