IRC log of tagmem on 2012-06-13

Timestamps are in UTC.

00:33:00 [timbl]
timbl has joined #tagmem
00:33:07 [timbl_]
timbl_ has joined #tagmem
01:36:26 [JeniT]
JeniT has joined #tagmem
01:40:55 [jar]
jar has joined #tagmem
02:20:03 [ht]
ht has joined #tagmem
13:14:40 [RRSAgent]
RRSAgent has joined #tagmem
13:14:40 [RRSAgent]
logging to
13:15:09 [masinter]
scribenick: masinter
13:15:15 [masinter]
scribe: Larry Masinter
13:15:21 [masinter]
topic: Storage
13:17:59 [masinter]
noah: Storage including synchronization
13:18:09 [plinss]
13:18:14 [noah]
13:18:35 [noah]
13:18:35 [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:18:35 [trackbot]
13:18:55 [noah]
Robin recommends:
13:19:00 [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.
13:19:08 [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
13:20:44 [masinter]
I suggest this is a topic for the TAG Blog
13:21:06 [noah]
I hadn't meant to ask about synchronization
13:21:12 [darobin]
13:21:34 [masinter]
noah: in terms of other storage work, what should the TAG do?
13:22:13 [timbl]
q+ to ask about synchronization anyway for a status summary of the field
13:22:20 [masinter]
darobin: In terms of architecture, it would be useful to revisit the notions we have URI stability, in terms of distributed minting of URIs
13:22:54 [masinter]
darobin: we might want to look at versioning, and the databases are massively distributed and unlikely to be running the same version
13:23:16 [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
13:23:16 [masinter]
darobin: problem of vendor lockin, if you have data locally and want to switch user agents
13:23:46 [masinter]
robin: if there is any TAG work to be done, the rest falls under "these are pitfalls"
13:24:23 [Ashok]
13:24:31 [masinter]
timbl: what about sharing and access control? If you have lots of apps access to your address book ...
13:24:31 [jar]
robin: SOP solves the access control problem. timbl: I don't think so
13:25:00 [masinter]
timbl: I want to have standards for the data, for interoperaebility
13:25:25 [noah]
q+ to agree with Tim that access control is important/unsolved; disagree with implication TAG is the place to worry about it now, except maybe to alert the community that it's important
13:25:40 [masinter]
timbl: I buy an application, use it on the ipad, and i can't do anything at all with the data
13:26:20 [masinter]
darobin: 2 things: vendor lockin, if data stored is _only_ in UA and only locally, then that would lock you into a UA
13:26:59 [masinter]
darobin: sharing, you don't want to give another application access to your storage directly because you might change htem
13:27:16 [masinter]
darobin: ((something about webintents, group being chartered))
13:27:41 [JeniT]
darobin: webintents provide standardisation around data structures
13:28:12 [masinter]
timbl: there is another model, from the link data platform, where you DON'T use APIs
13:29:09 [masinter]
timbl: 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
13:29:56 [masinter]
darobin: it's not that different a model. The APIs are data oriented with a discovery component.
13:30:10 [masinter]
timbl: standardizing an ontology instead
13:30:41 [noah]
NM: Robin, if you have to leave, anything else?
13:30:56 [masinter]
darobin: standardizing an ontology and standardizing an API are very similar in these cases
13:30:58 [JeniT]
+1 on common model between webintents and linked data platform
13:31:04 [noah]
RB: Not beyond what's in my e-mail. I am interested, as Tim implies, in finding common model between Web Intents and Linked Data
13:31:44 [masinter]
darobin: could we make use of json-ld, (something), we've been looking at options
13:32:04 [Zakim]
- +
13:32:07 [masinter]
noah: what is your interest in writing in this area?
13:32:13 [Zakim]
- +1.617.715.aabb
13:32:14 [Zakim]
TAG_f2f()8:00AM has ended
13:32:14 [Zakim]
Attendees were +, +1.617.715.aabb
13:32:21 [noah]
ack next
13:32:25 [noah]
13:32:27 [masinter]
darobin: I can help but I don't want to drive
13:32:49 [noah]
q+ test
13:32:54 [noah]
q- test
13:33:46 [masinter]
timbl: form my point of view, I'd love to have someone explain why, after all these years, that sync is hard
13:34:23 [masinter]
noah: Capp theorem... it's hard.
13:34:58 [masinter]
timbl: Mac has had over years sync services, and still over the years there are failures
13:36:19 [masinter]
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"
13:36:35 [masinter]
timbl: Robin said this is still a research issue
13:37:17 [masinter]
noah: the research is for cases which are more complicated
13:37:47 [masinter]
timbl: (description of situations where synchronization has failed for him on odd occasions)
13:38:14 [masinter]
ashok: re vendor lockin: what is required is that you can take your data and move it to another machine
13:38:28 [noah]
Some references on CAP theorem:
13:38:29 [noah]
13:38:40 [noah]
13:38:48 [masinter]
ashok: thinking about replication: what has happened in the last few years is NoSQL
13:39:06 [masinter]
ashok: they replicate the databases to make them all available
13:39:16 [noah]
We have 20 mins or so to settle what TAG is doing in this space.
13:39:21 [masinter]
ashok: They have this semantics of "eventually consistence"
13:39:37 [masinter]
ashok: that works OK if there is no semantic difficulty
13:40:13 [masinter]
timbl: the mac has a layer where it generates a UI and asks the user about semantics
13:40:40 [masinter]
ashok: if you use CouchDB, it keeps copies of your documents, and ... ((...)) ...
13:41:06 [masinter]
ashok: if you don't have conflicts it is a solved problem. If you do have conflicts, ... (something)...
13:41:32 [masinter]
ashok: I want the WebApps guys to make an interface to SQL
13:41:39 [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.
13:42:17 [masinter]
ashok: if you use SQL, the database syncs, it's what databases do
13:42:33 [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.
13:42:35 [masinter]
ashok: databases can even send you updates to previous queries
13:42:46 [noah]
13:42:58 [JeniT]
q+ to say that it sounds like these are patterns that we could usefully summarise
13:43:18 [masinter]
timbl: from the RDF point of view, it would be appealing to define sync for arbitrary RDF graphs
13:43:34 [JeniT]
13:43:37 [masinter]
noah: (time)
13:43:56 [masinter]
noah: there were two items: storage & synchronization
13:44:20 [masinter]
ashok: robin spoke about 2 things
13:44:51 [masinter]
noah: we need to define what the TAG is doing
13:45:13 [masinter]
13:45:26 [masinter]
noah: what is the TAG's business?
13:46:19 [masinter]
noah: Synchronization vs. Storage, what do you think the TAG should pursue?
13:46:53 [masinter]
ashok: when robin started, he said "we could write something that would alert people about storage"
13:46:58 [timbl]
We did sync stuff with cwm in the SWAP project around 2001
13:47:28 [masinter]
jeni: why not bite of syncrhonization about storage
13:47:38 [masinter]
jeni: would like some kind of output
13:48:31 [masinter]
noah: I think someone needs to research the state of the art, looking at web environment, all in the context of writing architecture
13:48:57 [masinter]
jeni: we're looking at people trying to get out of walled garden
13:49:37 [masinter]
I'd like to propose a direction for consideration
13:50:32 [noah]
NM: Suggest we use next 10 minutes to see whether people agree TAG work on sync, and if so, get short list of detailed goals.
13:50:46 [jar]
lm: 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.
13:51:04 [noah]
LM: I think TAG won't look for us to that. What might be useful is to narrow focus to linked data synchronization.
13:51:07 [timbl]
q+ to about sync being proprietory
13:51:27 [noah]
ack next
13:51:31 [noah]
ack next
13:51:32 [Zakim]
timbl, you wanted to about sync being proprietory
13:51:34 [noah]
q+ jeni
13:51:45 [jar]
s/I think TAG/I think the community/
13:52:12 [masinter]
s/for us to that/to us for that/
13:52:22 [noah]
It occurs to me that things like Dropbox are very widely deployed embodiments of sync, albeit at the file level.
13:52:53 [noah]
rsync is also pertinent to a degree, I think, though as far as I know it's not bi-directional.
13:52:55 [masinter]
timbl: because the architecture was hub (or adaptor and hub) and spoke
13:53:06 [JeniT]
q+ 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 advantage of
13:53:12 [JeniT]
q- jeni
13:53:26 [noah]
+1 to what Jeni's about to say :-)
13:53:43 [masinter]
timbl: EAI Enterprise Application Integration (something)
13:53:49 [noah]
ack next
13:53:51 [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
13:53:51 [Zakim]
... advantage of
13:54:27 [masinter]
timbl: that may be why syncrhonization is a black art: the market is based on solutions where the hub is a black art
13:55:13 [noah]
13:55:20 [noah]
zakim, close the queue
13:55:20 [Zakim]
ok, noah, the speaker queue is closed
13:55:23 [masinter]
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 eright
13:55:39 [masinter]
ashok: it's an example we're intereested in
13:56:06 [masinter]
jar: message shouldn't be "You should do it this way" but "If you want to do it this way, here's how"
13:56:22 [jar]
… and what advantages you might get
13:59:35 [masinter]
larry: 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?
13:59:58 [masinter]
noah: who's willing to do X
14:00:17 [masinter]
jeni: i'd rather have an action to write something
14:01:11 [masinter]
noah: (wants a product page)
14:01:16 [JeniT]
s/rather have/rather someone have/
14:01:36 [masinter]
(discussion of whether we're doing a product page or a document or ...)
14:01:54 [masinter]
ashok: I'll talk to Robin when I can catch him
14:02:39 [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
14:02:39 [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].
14:03:14 [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
14:03:14 [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].
14:03:20 [masinter]
i think the scope in the action is broader than i wanted
14:04:02 [noah]
14:04:02 [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
14:04:02 [trackbot]
14:04:07 [noah]
close ACTION-647
14:04:07 [trackbot]
ACTION-647 Draft product page on client-side storage focusing on specific goals and success criteria closed
14:05:16 [noah]
14:05:16 [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
14:05:16 [trackbot]
14:05:31 [noah]
close ACTION-693
14:05:31 [trackbot]
ACTION-693 Draft scope and goals for the Patterns/Pitfalls work in local/remote storage synch closed
14:10:25 [masinter]
topic: tag effectiveness
14:10:57 [masinter]
noah: Jeni suggested some meeting facilitation methods to use, so I will turn the meeting over to her
14:11:24 [masinter]
noah: I think it is important that we think carefully about what we're trying to achieve
14:11:50 [masinter]
noah: People come in and complain "the community isn't listening ..."
14:12:25 [masinter]
noah: and i ask myself whether the charter is wrong or whether we're performing it wrong
14:12:53 [masinter]
noah: people complain X and propose Y but it's easy to jump to conclusions
14:13:18 [masinter]
noah: as chair I see operational things that are boring but are important
14:14:20 [masinter]
noah: 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.
14:14:32 [masinter]
noah: some of those things are bigger
14:15:29 [masinter]
noah: 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.
14:15:39 [masinter]
the fragid thing looks like pretty good work
14:16:24 [masinter]
s/the/noah: the/
14:17:14 [masinter]
noah: there's a lot positive we've done
14:18:14 [Zakim]
TAG_f2f()8:00AM has now started
14:18:15 [Zakim]
14:19:53 [Zakim]
+ +1.617.715.aaaa
14:22:43 [masinter]
(noah reviewing charter)
14:23:28 [jar]
noah: Issues are called out in the charter; maybe we've swung too far from issue-oriented to product-oriented
14:26:44 [masinter]
ashok: what do you mean by community review?
14:27:30 [masinter]
ashok: 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?
14:27:57 [masinter]
noah: I think we've tried in good faith to be open
14:28:51 [masinter]
noah: in my time on the TAG we have bent over backwards ... people don't complain that we haven't answered comments
14:31:32 [masinter]
jeni: structure brainstorming of strengths and weaknesses.....
14:32:11 [masinter]
jeni: opportunities and threats, 10 minutes for each to write down, and group to write down
14:32:31 [JeniT]
14:33:35 [masinter]
jeni: one we can prioritize, do brainstorming first, clusters second
14:33:37 [jar]
jeni: brainstorming -> clustering -> priorities
14:35:23 [jar]
lm: what are we trying to optimize?
14:38:40 [masinter]
lm: "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"
14:38:44 [masinter]
lm: right?
14:38:47 [masinter]
jeni: right
14:48:34 [timbl_]
timbl_ has joined #tagmem
15:33:08 [masinter]
(group has put up postits for strengths, weaknesses, threats, opportunities, Jini will review categories in that order)
15:33:28 [masinter]
jeni: big strength is experience, expertise, knowledge
15:34:01 [masinter]
jeni other big category strength is we're good people
15:34:44 [masinter]
jeni: others acess to W3C, TimBL
15:35:15 [masinter]
jeni: weaknesses: thrashing, ratholing
15:35:30 [masinter]
jeni: weakness: conflict within group
15:35:49 [masinter]
jeni: problems around time available for tag work
15:36:02 [masinter]
jeni: weakness: travel funding
15:36:27 [masinter]
jeni: weakness: quite a lot of membership churn
15:36:59 [masinter]
jeni: weakness: lack of knowledge in specific areas (security, privacy, network protocols)
15:37:40 [masinter]
((ashok is typing outline))
15:37:48 [timbl_]
timbl_ has left #tagmem
15:38:24 [masinter]
jeni: weakness: our ability to educate others, lack of power, lack of enforcement
15:38:58 [masinter]
jeni: threat: bad PR
15:39:07 [noah]
noah has joined #tagmem
15:39:18 [masinter]
jeni: threat: creating recommendations take a long time
15:39:21 [noah]
noah has joined #tagmem
15:39:49 [masinter]
jeni: threat: general issues around connection with other groups
15:40:08 [masinter]
jeni: threat: liaison to other groups (ECMA, OASIS)
15:40:32 [masinter]
jeni: threat: web is moving, getting broader, more areas
15:41:07 [masinter]
jeni: threat: over in opportunity side: help persuade community
15:41:32 [masinter]
s/threat: over in opportunity/opportunity: /
15:41:50 [masinter]
jeni: opportunity: liaise with ietf iab
15:42:08 [masinter]
jeni: opportunity: meet more with customers, chairs, staff
15:42:37 [masinter]
jeni: opportunity: (2 more)
15:43:46 [masinter]
noah: we should find some middle ground to find some high-value things
15:47:42 [Ashok]
Topic: TAG Effectiveness
15:47:58 [Ashok]
Strengths -Experience, expertise and knowledge -Good people -Common understanding of Web -Good writing skills -Tim is with us -Access to W3C Process
15:48:15 [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.
15:48:37 [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)
15:48:55 [Ashok]
Opportunities -Help persuade people this matters -Help WGs -Liaise with IETF -Feedback on WG work -Meet with customers, etc.
16:00:42 [Zakim]
16:01:55 [timbl]
timbl has joined #tagmem
16:01:56 [timbl_]
timbl_ has joined #tagmem
16:05:46 [Norm]
Norm has joined #tagmem
16:23:02 [JeniT]
16:50:02 [timbl__]
timbl__ has joined #tagmem
17:07:22 [JeniT]
plinss, have you seen
17:07:50 [plinss]
17:08:00 [JeniT]
you have now
17:36:31 [JeniT]
Scribe: JeniT
17:38:15 [Ashok]
Ashok has joined #tagmem
17:38:27 [Ashok]
17:38:49 [Ashok]
- Disconnect from community (5)
17:39:10 [Ashok]
- People don't care about architecture (1)
17:39:41 [Ashok]
- Persuading community that arch. matters (1)
17:40:01 [masinter]
noah: some people have a short-term/long term
17:40:03 [Ashok]
- Helping WGs/involvement in W3C
17:40:26 [Ashok]
- Education of Community (4)
17:40:26 [JeniT]
masinter: if you're a browser making, you care about browsers, not about semantic web
17:40:31 [JeniT]
... it's about breadth of scope
17:40:41 [Ashok]
- Enforcement (1)
17:40:55 [Ashok]
- Getting comments / spec process
17:40:59 [JeniT]
... we're trying to bring a broader perspective, for applications they don't think are important
17:41:02 [Ashok]
17:41:26 [Ashok]
- Threats (3) and opportunities (2)
17:41:32 [Ashok]
17:41:44 [Ashok]
- Time/money/efforts
17:41:59 [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
17:42:05 [Ashok]
- Thrashing / Ratholing
17:42:50 [JeniT]
Ashok: on reacting to the changing web
17:42:58 [JeniT]
... I was involved in 'Headlights' effort
17:43:12 [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
17:43:12 [JeniT]
... they had five Headlight areas, one of which was 'Cloud'
17:43:19 [JeniT]
... which is a hot topic now
17:43:36 [JeniT]
... we argued about whether we should do cloud
17:43:47 [masinter]
you are tempted to characterize this as a "short term" vs "long term", but I think it's narrow vs. broad
17:43:49 [JeniT]
... we thought W3C didn't have anything to offer
17:44:08 [JeniT]
... they all use URIs, all use REST, but cloud is application management
17:44:28 [JeniT]
... we thought the W3C should be doing fundamental web technologies, to use in cloud, in big data or elsewhere
17:44:38 [JeniT]
... otherwise, it's out of the comfort zone of W3C
17:45:50 [JeniT]
noah: we should focus our TAG improvements around these themes
17:46:10 [JeniT]
... is there anything else that we should have mentioned?
17:47:01 [JeniT]
... over the next little while we should remind ourselves and focus around these clusters
17:48:14 [JeniT]
masinter: we've done this analysis, shouldn't we try to identify actions
17:48:58 [JeniT]
jenit: what actions do you see (Larry), so we can have those as input for anything we do tomorrow?
17:49:08 [JeniT]
masinter: a set around engaging leaders in the community
17:49:21 [JeniT]
... not people who subscribe to www-tag, but community of the web
17:49:36 [JeniT]
... we could go and talk at conferences, but that's not efficient
17:49:48 [JeniT]
... instead, target chairs of working groups, team members
17:50:04 [JeniT]
... talk to dozens of people in leadership positions rather than hundreds
17:50:09 [JeniT]
Ashok: should we have a TPAC presentation?
17:50:38 [JeniT]
masinter: I'd like to get better feedback, based on data, on our work
17:50:57 [JeniT]
... for example, web stats on how many people are reading these documents
17:51:14 [JeniT]
noah: I'm not sure that all leaders are chairing WGs
17:51:30 [JeniT]
... I'm concerned of not getting balanced feedback
17:51:45 [JeniT]
... like an advisory group, to look at what we're doing
17:52:08 [JeniT]
masinter: I was going to ask W3C for a programme manager to work to survey the community for a while
17:52:14 [JeniT]
... to help prioritise our work
17:52:51 [JeniT]
... we need to decide what we work on, so that what we work on matches the needs of the community
17:53:08 [JeniT]
... and we should be explicit about doing things that the community doesn't think they need, and why they really should
17:53:21 [JeniT]
noah: it would be great to do an organised job to get that feedback
17:53:51 [JeniT]
... I don't want it to take a lot of my time
17:54:12 [JeniT]
... they are going to call me a lot, to coordinate
17:54:41 [JeniT]
... let's make sure it would actually work
17:54:46 [JeniT]
jar: could we just talk about the ideas?
17:55:18 [JeniT]
Ashok: if we agree that this is what we ought to do, we should do it regardless of noah's schedule
17:55:31 [JeniT]
masinter: second thing is how we publish what we have worked on
17:55:45 [JeniT]
... there's the presentation of the website, to find out what we do
17:55:49 [JeniT]
... it's hard to find out
17:56:10 [JeniT]
... a lot of draft findings, only a few findings, it's hard to find out what the latest thing we've said is
17:56:19 [JeniT]
... then there's the finding vs. recommendation issue
17:56:52 [jar]
jar has joined #tagmem
17:56:52 [JeniT]
... a recommendation reflects community agreement, said on behalf of community
17:57:17 [JeniT]
... sometimes what we do needs to get engagement from community even wider than W3C community
17:57:33 [JeniT]
... would be nice if chairs needed to look at architectural recommendations
17:57:45 [JeniT]
... I don't know how to solve those problems
17:58:07 [JeniT]
... but asking someone else to change the way that they work is difficult, they need to be involved in that change
17:58:45 [JeniT]
plinss: it's good having putting documents through the Rec process, because you have to identify WGs from which you need feedback
17:59:08 [JeniT]
masinter: then there's how we get selected, how many TAG members there are, whether they are funded and so on
17:59:14 [JeniT]
... I don't have hope for additional funding
17:59:28 [JeniT]
ht: I thought it was worth putting down as a marker
17:59:49 [JeniT]
... to say that if W3C did get more money, the TAG might be a place to spend it
18:00:10 [JeniT]
masinter: what we work on, how we publish it, how we work
18:00:21 [JeniT]
... spending time on administrative topics, how we organise
18:00:36 [JeniT]
... those things are more easily adaptable, we can try different internal organisations at will
18:00:48 [JeniT]
... it's harder changing the way we present and interact with others, and the way we prioritise
18:01:05 [JeniT]
... I think we should put more priority on how we work externally, because it will affect how we work internally anyway
18:01:16 [JeniT]
... more blog posts, for example, would change our internal working
18:01:39 [JeniT]
noah: is there anything that you would say that isn't on the board?
18:01:50 [JeniT]
masinter: the one thing is increasing the priority of our liaison work
18:02:11 [JeniT]
... especially with IAB
18:02:23 [JeniT]
... OASIS doesn't have an architecture committee, does it?
18:02:40 [JeniT]
noah: do we only want to liaise with people who are organised like we are?
18:02:51 [JeniT]
... we should liaise for example with WHATWG
18:03:05 [JeniT]
masinter: the principle is, do they talk about architectural issues in the same way that we do
18:03:32 [JeniT]
... they write vocabulary/architecture documents like we do, lots of opportunity for cross-review
18:03:40 [JeniT]
... and coordination
18:05:12 [JeniT]
Topic: Positioning of Web and Native applications
18:05:13 [Ashok]
Ashok has joined #tagmem
18:07:40 [JeniT]
18:11:21 [JeniT]
masinter: the main point from this was the death of the application layer
18:11:38 [JeniT]
... native vs web app was one question among many
18:11:50 [JeniT]
noah: so Hannes wasn't asking us to take on long-term work
18:11:55 [JeniT]
... I still think it's an interesting question
18:12:06 [JeniT]
... is this a promising area? it feels like it is to me
18:12:36 [JeniT]
... web vs. native, and within the web app, things that used to be managed at the protocol level are now being managed through Javascript
18:12:46 [JeniT]
masinter: the trend started with layering on top of HTTP
18:12:54 [JeniT]
... and it's going rapidly in that direction
18:13:34 [JeniT]
noah: my inclination is to go into this, to indicate tradeoffs
18:14:02 [JeniT]
masinter: used to think of 7 layers
18:14:13 [JeniT]
... the layers are still here
18:14:25 [JeniT]
... you would draw this as an hour glass, because everything went through TCP/UDP
18:14:37 [JeniT]
... doesn't matter what's above, what's below, so long as everything went through that neck
18:14:46 [JeniT]
... rich applications in layers above that hour glass
18:15:04 [JeniT]
ht: and that bottleneck being where it is meant there was work for the IETF in designing protocols
18:15:14 [JeniT]
... right about TCP/UDP you had protocols
18:15:19 [JeniT]
18:15:41 [JeniT]
masinter: in the new diagram, the bottleneck is at the protocol layer, we have HTTP, WebRTC
18:15:49 [JeniT]
ht: IETF doesn't need to design protocols any more
18:16:03 [JeniT]
... that was the emotional subtext to the discussion at the IETF
18:16:12 [JeniT]
... "what is there for us in this new world"
18:16:18 [JeniT]
masinter: and how to manage the parts they're doing
18:16:47 [JeniT]
timbl: the TCP bottleneck meant that underneath the bottleneck, stuff underneath could change without us having to change our code
18:16:57 [JeniT]
... does this top bottleneck have this property as well?
18:17:10 [JeniT]
... could we make huge changes to the way HTTP works?
18:17:20 [JeniT]
ht: SPDY is evidence that you can
18:17:43 [JeniT]
timbl: otoh we've learned that apps have to look a little bit down through the bottleneck
18:17:52 [JeniT]
ht: SPDY is about avoiding a bit of that
18:18:01 [JeniT]
... to avoid having to play games to get parallelism
18:18:17 [JeniT]
timbl: in the LDP model, the bottleneck is HTTP+RDF+SPARQL Update
18:18:28 [JeniT]
... the application level, the design is in ontologies and rules for their use
18:18:49 [ht]
ht has joined #tagmem
18:18:49 [JeniT]
noah: that only says so much about how we optimise delivery of a video stream
18:19:07 [JeniT]
timbl: video is an independent part of the web
18:19:15 [JeniT]
noah: video benefited from the old hourglass
18:19:53 [JeniT]
masinter: I disagree, they discovered because of firewalls they couldn't deliver video how they needed to
18:19:56 [JeniT]
... to get real-time stuff
18:20:19 [JeniT]
noah: a whole lot of TV goes through the hourglass
18:20:23 [masinter]
18:20:24 [ht]
ht has joined #tagmem
18:20:34 [JeniT]
Ashok: we're speaking between native apps and web apps
18:20:42 [JeniT]
... what's the difference?
18:20:44 [timbl]
timbl has left #tagmem
18:20:45 [masinter]
MPEG-DASH is delivering streaming video using HTTP using the top neck
18:20:57 [masinter]
two hourglasses
18:21:04 [JeniT]
noah: devices have APIs
18:21:14 [masinter]
s/glasses/glass necks/
18:21:30 [JeniT]
... native apps are written to exploit the platform APIs
18:21:39 [masinter]
18:21:44 [JeniT]
... not tuned to write application that run on a different device or platform
18:22:04 [JeniT]
... released in lock step with device releases
18:22:17 [JeniT]
... people wrongly associate it with marketplaces, and charging
18:22:24 [JeniT]
Ashok: it does not run in the browser
18:22:33 [JeniT]
noah: but some use Webkit components for example
18:22:38 [JeniT]
Ashok: does it work with a server?
18:22:43 [JeniT]
noah: many do
18:22:51 [JeniT]
Ashok: can you access another external website?
18:22:58 [JeniT]
noah: some do some don't
18:23:07 [masinter]
18:23:24 [JeniT]
... I bet weather apps use RESTful APIs to access their data
18:23:57 [JeniT]
... ESPN apps appear purely native, and you then get a web page, no back button
18:24:05 [JeniT]
plinss: not a full interactive browser
18:24:13 [JeniT]
noah: some intercept links, some don't
18:24:24 [JeniT]
Ashok: the only difference I'm seeing is that they don't run in the browser
18:24:28 [JeniT]
noah: that has huge implications
18:24:32 [JeniT]
masinter: no it doesn't
18:25:05 [JeniT]
Ashok: so it doesn't run in browser, and it has priviledged access to hardware?
18:25:24 [JeniT]
noah: plugging iPad into mixing device
18:25:41 [JeniT]
... we have nothing in the web space to do that
18:25:54 [JeniT]
... people are building businesses on that
18:26:14 [JeniT]
Ashok: I'm trying to figure out what the differences are
18:26:26 [JeniT]
noah: native priviledged control of hardware
18:26:54 [JeniT]
jar: but this could also apply to communication with a server
18:27:15 [JeniT]
... proprietary protocols between two parts of the system
18:27:22 [masinter]
Apache Cordova (aka PhoneGap) uses web infrastructure to build apps
18:27:45 [masinter]
"proprietary protocols" => "private device APIs"
18:27:54 [JeniT]
... if you have an application in mind and it involves a client/server, your choice is affected by multiple considerations
18:28:05 [masinter]
WebIDL should be in scope for architecture
18:28:11 [JeniT]
Ashok: the part that uses the hardware, the special hardware, that *has* to run on the device
18:28:18 [JeniT]
jar: the special hardware could be on the server
18:28:30 [JeniT]
masinter: I have 40 native apps on my phone, none of which access specialised hardware
18:28:56 [JeniT]
noah: analogy between relationships between Macs and Laserwriters
18:29:20 [JeniT]
... the web community needs to support multiple devices
18:29:32 [JeniT]
... and interfaces with them
18:29:46 [JeniT]
jar: seems like there are multiple considerations that would lead to deploying as native vs web
18:29:54 [JeniT]
... maybe hardware is one of them, but there will be a bunch of others
18:30:05 [JeniT]
... these issues are orthogonal to interoperability
18:30:28 [JeniT]
masinter: I hear Robin saying we shouldn't talk about this because there are WGs trying to make native apps irrelevant
18:30:44 [JeniT]
... then there are articles saying that companies build native apps is because of monetisation
18:30:59 [JeniT]
jar: I think we could list four considerations for making the decision
18:31:53 [JeniT]
jenit: these issues are well known
18:32:07 [JeniT]
masinter: I've read that the main issue is monetisation
18:32:15 [JeniT]
... and we have nothing to say about that anywhere within W3C
18:32:41 [JeniT]
noah: maybe we need to help W3C to see this
18:32:46 [masinter]
the motivation for innovation in the web is monetization
18:32:54 [JeniT]
timbl: the whole webapps drive at W3C has been going for a while
18:33:11 [masinter]
rights management video is also driven by monetization
18:33:13 [JeniT]
... the push that people should use webapp technology is several years old
18:33:29 [JeniT]
... we must have talked about trusted apps
18:33:32 [masinter]
q+ to correct what i said. The W3C *is* talking about monetization for video
18:33:56 [JeniT]
... that's one example where web apps aren't trusted apps
18:34:02 [masinter]
I want to correct what i said. The W3C *is* talking about monetization in the context of DRM for video
18:34:05 [JeniT]
... making the list of reasons is a good idea
18:34:14 [JeniT]
... putting it in order is a silly idea, because everyone is different
18:34:24 [JeniT]
... many different markets, many different kinds of apps
18:34:29 [JeniT]
... based on different criteria
18:34:45 [JeniT]
... whole tranche that cares about monetisation, another that really doesn't care
18:35:04 [JeniT]
... I think we should map pros and cons, or point to it
18:35:17 [JeniT]
... and flag any things that give us particular concern
18:35:24 [JeniT]
... we've said that payment protocols is a gap
18:35:56 [jar]
lm: it isn't true that the w3c doesn't talk about monetization. videos. DRM, subscription
18:36:20 [jar]
lm: we haven't said much about book or text content [or software]
18:36:58 [jar]
18:37:21 [jar]
pl: A lot of this interesting things here, but why to the TAG? Any architectural issues?
18:37:39 [jar]
pl: What could lead to us having any effect?
18:38:24 [jar]
nm: Having a task group go off and look at this might help
18:38:51 [jar]
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
18:39:01 [jar]
pl: There are other people finding the gaps and filling them in
18:39:12 [jar]
timbl: There's an activity
18:40:00 [jar]
lm: 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,
18:40:53 [jar]
… 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?
18:41:53 [jar]
nm: Helping the w3c to focus and validate to make web-based platform successful. But LM is saying (something else)
18:42:51 [jar]
lm: 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
18:44:04 [jar]
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...
18:44:40 [jar]
… now we have pages and proxies… the whole point is the heavy use of layering
18:45:10 [jar]
lm: Now we take what we used to do with ports and streams, and figure out how to do it in the new regime
18:45:58 [jar]
nm: 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?
18:46:18 [jar]
lm: They sent the message to the entire IETF community. We're just not monitoring that list
18:46:50 [jar]
am: How would we write trusted apps that don't run in the browser in a portable way?
18:47:10 [jar]
nm: There are things vendors intentionally make hard, so that access is difficult
18:48:04 [jar]
am: We write standards that work within the browser. Should we start thinking about standards for native apps.
18:48:22 [JeniT]
timbl: there are lots of apps where the browser is the desktop, like Boot-to-chrome
18:48:35 [JeniT]
... I can't think of any architectural questions, except for the trusted app issue
18:48:48 [JeniT]
masinter: very frequently there's a service available on the web and in the native app
18:48:57 [JeniT]
... it has more trust, it has an icon, you don't have to log in
18:49:16 [JeniT]
... if your goal is: does it use standard protocols, is it interoperable? yes, it does
18:49:31 [JeniT]
... you can send URLs, and it will bring up the app or the browser
18:49:44 [JeniT]
... it's ok to develop standards that aren't for browsers
18:49:51 [JeniT]
... it's reasonable
18:50:08 [JeniT]
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
18:50:14 [JeniT]
... I need to look at local storage
18:50:23 [JeniT]
Ashok: Javascript would have to execute natively on the platform
18:50:35 [JeniT]
timbl: there would have to be a stripped down browser, one without the chrome
18:50:39 [JeniT]
... what's hard with that?
18:50:45 [JeniT]
masinter: that's what Windows did
18:50:52 [JeniT]
Ashok: a skinny browser
18:51:06 [JeniT]
timbl: a browser that's fat in features, the only thing that's missing is the window
18:51:18 [JeniT]
noah: IE5 did that
18:51:31 [JeniT]
... the native app might not be browser based
18:51:38 [JeniT]
... maps might be an example
18:52:00 [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
18:52:03 [JeniT]
... if you have a Google Maps URI, the phone looks at the URI, cheats, decides to open a specific maps app
18:52:14 [JeniT]
... no way to to tell whether it's using REST/HTTP
18:52:21 [JeniT]
Ashok: but it uses the URI
18:52:38 [JeniT]
plinss: if you click a Google Maps link in a browser, it launches the native app
18:52:47 [JeniT]
noah: it feels more native than wrapped web
18:53:26 [JeniT]
noah: where should we go with this?
18:53:32 [JeniT]
Ashok: I'm not hearing any direction
18:53:45 [JeniT]
noah: we did have a contact from Hannes, should we have a response?
18:53:57 [JeniT]
... if we have more TAG work, we should have focused analysis with a goal
18:54:11 [JeniT]
masinter: I have what I think is a new thought
18:54:19 [JeniT]
... W3C often works on things that have nothing to do with browsers
18:54:26 [JeniT]
... XML protocol for example
18:55:05 [JeniT]
... why should we care that these standards are being used by native apps?
18:55:26 [JeniT]
... people are spending more money building native apps
18:55:34 [JeniT]
noah: you imply those native apps are rendering HTML
18:55:49 [JeniT]
... and if they're not, our stuff is totally irrelevant
18:56:04 [JeniT]
... I can't tell if they are standalone, if they use HTTP
18:56:42 [JeniT]
jar: I think we should be looking at the interoperability problems
18:56:58 [JeniT]
... some are to do with the internet and some aren't
18:57:10 [JeniT]
... there are all kinds of standards organisations
18:57:16 [JeniT]
... that's different from getting work done as a developer
18:57:25 [JeniT]
masinter: the question is what should be in scope for W3C
18:57:36 [JeniT]
... what's the scope of the architecture?
18:57:44 [JeniT]
... what W3C does vs what we expect others to do
18:57:49 [JeniT]
... that's not entirely up to the TAG
18:57:55 [JeniT]
... but we might have some input on it
18:58:17 [JeniT]
noah: what should our next step be?
18:58:41 [JeniT]
masinter: I suggest we put this on our status report to Jeff
18:58:55 [JeniT]
... I think we have new information, that the IAB would like to know
18:59:04 [JeniT]
noah: he'll immediately ask what we're doing about it
18:59:16 [JeniT]
... what should we do?
18:59:19 [masinter]
should we try to define what we think W3C's scope is?
18:59:55 [JeniT]
... is someone going to step up to analyse the area and provide goals?
18:59:57 [masinter]
i'm convinced by this discussion that native apps using web technology should be in scope for W3C and the TAG and AWWW
19:00:12 [JeniT]
ht: get something on the broken record
19:00:25 [JeniT]
... there's the potential for a big revolution
19:01:02 [masinter]
and that DRM for native apps might be a candidate enabling technology
19:01:15 [JeniT]
... providing apps over the web is repurposing
19:01:22 [JeniT]
... without any rearchitecturing
19:01:35 [JeniT]
... it might be that now we know what we want, we should design one and ship one
19:01:39 [masinter]
and there might be some 'best practices' that would have to be review URIs, security, login
19:01:43 [timbl__]
19:02:02 [JeniT]
... Flash was designed much more to be that mechanism for delivering apps
19:02:24 [JeniT]
... if the idea of a distributed deployment platform gets traction
19:02:26 [jar]
Evolution of Javascript is repeating evolution of Java (somewhat out of order)
19:02:33 [JeniT]
... then we need to pay attention
19:02:36 [masinter]
19:02:50 [JeniT]
... different from web browsers, which have a different goal, and weren't designed to be a distributed deployment platform
19:03:05 [masinter]
19:03:26 [JeniT]
timbl: the idea of redesigning from scratch sounds like a bad idea
19:03:39 [JeniT]
... but we could look at what it would look like if we did
19:03:55 [JeniT]
jar: history is repeating itself, so we could look at that, eg Java, Adobe
19:04:26 [JeniT]
timbl: I'm not interested in the TAG doing a redesign, except as a thought experiment to identify we might be missing
19:04:32 [JeniT]
... to do a course correction
19:05:08 [masinter]
. RESOLUTION: The TAG says that Native apps using web technology are in scope for W3C and the TAG
19:05:49 [JeniT]
noah: does someone want to propose direction?
19:06:15 [JeniT]
... the more work we can do offline, the better
19:06:24 [JeniT]
... we need someone to do legwork to bring in some facts
19:06:36 [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.
19:06:46 [JeniT]
... I propose we have no actions, except that we owe Hannes an answer
19:07:14 [noah]
noah has joined #tagmem
19:07:15 [JeniT]
... Larry, did you want to propose a reply to Hannes?
19:07:37 [masinter]
. ACTION: Larry to reply to Hannes summarizing the discusison, pointing to th eminutes, and asking him if he has any more specific questions.
19:09:02 [masinter]
ACTION: Larry to reply to Hannes pointing to the minutes, summarizing the discussion, and asking him if he has any more specific questions.
19:09:02 [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].
19:23:43 [Norm]
Norm has joined #tagmem
19:27:09 [masinter]
19:30:29 [JeniT]
Topic: Administration
19:31:37 [JeniT]
noah: tentatively between 7-10th Oct in UK
19:33:27 [JeniT]
... agreement on 7-9th Oct in London?
19:34:20 [JeniT]
ACTION: Noah to make sure we have somewhere to meet in London 7-9th October
19:34:20 [trackbot]
Created ACTION-720 - Make sure we have somewhere to meet in London 7-9th October [on Noah Mendelsohn - due 2012-06-20].
19:36:49 [JeniT]
RESOLUTION: TAG will meet in London 7-9th October
19:37:52 [JeniT]
noah: we may meet on 21st June
19:38:02 [JeniT]
... but cancel meetings of 28th June & 5th July
19:38:11 [JeniT]
... but have a meeting on 12th July
19:38:48 [JeniT]
... TPAC is 29th Oct - 2nd Nov
19:38:52 [JeniT]
... in Lyon
19:39:32 [JeniT]
... I probably won't be able to get there
19:39:52 [JeniT]
... December meeting, latest is 20th December
19:40:07 [JeniT]
Ashok: maybe January instead?
19:40:59 [JeniT]
noah: possibly 8-10th January in California
19:42:41 [JeniT]
... Timbl not free
19:50:08 [JeniT]
(lots of date discussion)
19:51:03 [JeniT]
(18-20th December out as TimBL unlikely)
19:51:19 [JeniT]
(early Jan difficult for Henry & Noah before lectures scheduled)
19:51:46 [JeniT]
noah: we have a room at TPAC even though I'm unlikely to make it
19:52:53 [JeniT]
(Tim, Ashok, Peter, JeniT likely at TPAC)
19:53:05 [JeniT]
(Larry possible, Henry unlikely)
19:53:21 [JeniT]
Topic: TAG Priorities 2012
19:53:39 [JeniT]
noah: we're doing good work on fragids
19:53:45 [JeniT]
... taking serious run at ISSUE-57
19:54:20 [JeniT]
... publishing & linking is kind of ok, except main assignee (JeniT) also doing the other main priorities
19:54:57 [JeniT]
ACTION: Noah to update product index to target date on publishing & linking
19:54:57 [trackbot]
Created ACTION-721 - Update product index to target date on publishing & linking [on Noah Mendelsohn - due 2012-06-20].
19:55:36 [jar]
ACTION jar Review 'publishing and linking' due 2012-08-01
19:55:36 [trackbot]
Created ACTION-722 - Review 'publishing and linking' due 2012-08-01 [on Jonathan Rees - due 2012-06-20].
19:56:14 [JeniT]
noah: my concern is that 9 people working 20% time should be doing more work
19:56:30 [JeniT]
... are any of the medium priority work items things we should move up to high priority?
19:56:58 [JeniT]
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
19:57:35 [JeniT]
noah: what technical topics would you prioritise based on that?
19:57:47 [JeniT]
masinter: engagement is important, so we should raise priority of web architecture pages
19:58:10 [JeniT]
... it's simple, and gains engagement
19:58:51 [JeniT]
noah: the only thing that's held that back is that we assigned actions and only Jeni's done it
19:59:02 [JeniT]
... we need to get members who take on the actions to buy in to doing them
19:59:31 [JeniT]
masinter: I think people work on things that you feel other people care about
19:59:47 [Zakim]
- +1.617.715.aaaa
19:59:48 [Zakim]
TAG_f2f()8:00AM has ended
19:59:48 [Zakim]
Attendees were Yves, +1.617.715.aaaa
19:59:50 [JeniT]
jar: people should work on things they are motivated to work on
20:00:21 [Zakim]
TAG_f2f()8:00AM has now started
20:00:28 [Zakim]
+ +1.617.715.aaaa
20:00:36 [Norm]
20:00:39 [Norm]
zakim, passcode?
20:00:39 [Zakim]
the conference code is 0824 (tel:+1.617.761.6200, Norm
20:01:31 [Zakim]
20:01:47 [JeniT]
Topic: HTML/XML Unification
20:03:01 [noah]
20:03:44 [JeniT]
noah: what's happened since we last met, and what should happen next?
20:04:05 [JeniT]
Norm: we met and chatted in December
20:04:14 [JeniT]
... a bunch of us were in Prague for XML Prague
20:04:35 [JeniT]
... Jeni, Robin & Anne (and me) thought setting up a community group in this space would be a good idea
20:04:44 [JeniT]
... Anne agreed to edit
20:04:50 [JeniT]
... I agreed to chair
20:05:08 [JeniT]
... there was a flurry of email, and there's Anne's draft based on XML5
20:05:23 [JeniT]
... I have been behind, but I caught up yesterday
20:05:40 [JeniT]
... I've tried to pull out the larger issues that I don't think are in the draft or where we have consensus
20:05:58 [JeniT]
... next step would be to try to get more review of Anne's draft within the group
20:06:06 [JeniT]
... to see whether that draft satisfies some of the requirements we have
20:06:24 [JeniT]
... we could spend time on use cases if we were more diligent
20:06:40 [JeniT]
... I'm not sure we could get that much discipline, but I'll make a stab at it
20:06:50 [JeniT]
noah: when we met at Tim's, we reviewed the TF report
20:07:00 [JeniT]
... at the time, you said you wanted the TAG's help to get it published as a Note
20:07:11 [JeniT]
... it was published on Feb 9th
20:07:16 [JeniT]
... just before XML Prague
20:07:39 [JeniT]
... most of what you've focused on is Anne's presentation at XML Prague & XML-ER
20:08:11 [JeniT]
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
20:08:18 [JeniT]
... the TF was useful in framing the discussion
20:08:28 [JeniT]
... but the TF has done all it will successfully do
20:08:45 [JeniT]
... we should be looking at engaging the XML-ER folks
20:09:12 [JeniT]
noah: the TF was a big deal for the TAG
20:09:28 [JeniT]
... are we happy to move in the direction that Norm is signalling?
20:10:04 [JeniT]
Norm: we do need to get use cases out there to help make choices
20:10:14 [ht_home]
ht_home has joined #tagmem
20:10:18 [JeniT]
... for example, the case of an interactive editor
20:10:30 [JeniT]
... there are some people who think that's critical and others that think it isn't
20:10:47 [JeniT]
... that will help drive refining something like Anne's draft
20:10:50 [noah]
20:11:24 [JeniT]
noah: I propose we close out the HTML/XML work
20:11:47 [JeniT]
... declare success on this bit of the work
20:11:59 [JeniT]
Norm: I'm agnostic
20:12:27 [JeniT]
... in the perfect world, we might want to do more work along the lines that was originally envisaged
20:12:38 [JeniT]
... but we should move in the direction of the community
20:13:11 [JeniT]
noah: we need to make a decision not to pursue other aspects from the report
20:13:33 [JeniT]
timbl: unless there's some huge thing that people haven't noticed, we should follow what the community is doing
20:13:43 [JeniT]
ht: my energy is going to go on monitoring polyglot
20:13:55 [JeniT]
... because it's the XHTML constituency that we have responsibility towards
20:14:08 [JeniT]
Norm: that's a good and wise thing to do
20:14:19 [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.
20:15:13 [JeniT]
ht: as long as I can continue to monitor polyglot, closing is fine
20:15:51 [JeniT]
noah: any objections?
20:16:23 [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.
20:16:53 [JeniT]
noah: would it be helpful to talk with the TAG on XML-ER?
20:17:39 [JeniT]
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?
20:17:47 [JeniT]
... is it a processing model or a declarative model?
20:17:59 [JeniT]
... the other issues are smaller
20:18:21 [noah]
20:18:35 [JeniT]
... is there a pre-processor that does clean-up and then uses an XML parser
20:18:42 [noah]
Point 1: declarative vs imperative rules for the mapping from character sequence to (fixed up) tree
20:18:54 [JeniT]
... or is it a procedural/streaming process?
20:19:10 [JeniT]
ht: it's stupid to define it procedurally
20:19:41 [JeniT]
noah: there was a similar decision in the HTML spec
20:20:02 [JeniT]
ht: it wasn't an explicit decision for HTML
20:20:37 [JeniT]
noah: for HTML, the asynchronous scripting environment might be legitimate grounds for saying it's hard to define this declaratively
20:20:43 [JeniT]
... but that doesn't apply in XML-ER
20:20:50 [JeniT]
... there's no asynchrony
20:21:09 [JeniT]
... Norm, do you think there are good technical reasons for speccing it procedurally rather than declaratively?
20:21:36 [JeniT]
Norm: I don't think there are technical reasons, but Anne's influenced by the HTML parsing method
20:21:44 [masinter] is declarative
20:21:49 [JeniT]
... and he's not interested in editing anything other than in that style
20:22:16 [JeniT]
noah: I'd love to see it done declaratively, but I don't think we should fight it now
20:22:34 [JeniT]
... I wish I had the time to do it
20:22:50 [JeniT]
Norm: if someone looked at Anne's draft and picked some subset and rewrote it using declarative rules
20:23:21 [JeniT]
... 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
20:23:30 [JeniT]
masinter: HTML5 is defined declaratively, there's a document that does it
20:23:50 [JeniT]
Norm: there's an exposition of how it's done, but it's not declarative
20:23:57 [masinter]
20:24:08 [JeniT]
noah: it's not a declarative mapping to a DOM tree
20:24:11 [JeniT]
ht: it's also incomplete
20:24:22 [JeniT]
noah: the goal with XML-ER is to map a character string to a DOM tree
20:24:40 [JeniT]
... the document you're pointing at focuses on legal HTML for good reasons
20:24:49 [JeniT]
... the target for XML-ER is illegal XML
20:25:07 [JeniT]
masinter: in the email discussion I was not understanding the use case that XML-ER is intending to address
20:25:21 [JeniT]
Norm: someone sends you a document that they've served as XML, but isn't well-formed
20:25:26 [JeniT]
... you want to process it with XSLT
20:25:35 [JeniT]
masinter: what's the use case for that?
20:25:54 [JeniT]
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
20:26:08 [JeniT]
... so you would have an alternative browser mode, that would process XHTML and keep going
20:26:22 [JeniT]
masinter: that's not enough of a use case, because it's a personal preference
20:26:35 [JeniT]
noah: people are using HTML because XHTML kept breaking for them
20:27:02 [JeniT]
masinter: give me a scenario where something doesn't work, where the requirements of the use case are that you need XML-ER
20:27:11 [JeniT]
timbl: an RSS aggregator
20:27:25 [JeniT]
masinter: one that's getting XHTML?
20:27:31 [JeniT]
timbl: it contains embedded HTML5
20:28:17 [JeniT]
Norm: another one is an XML database company, which wants to ingest documents
20:28:22 [JeniT]
... that purport to be XML
20:28:30 [JeniT]
... 30% of them are broken
20:28:40 [JeniT]
... you can do proprietary attempts to fix the markup
20:29:05 [JeniT]
... having a standard would enable two independent companies to ingest the documents and build the same trees
20:29:18 [JeniT]
... which would enable XML databases, XSLT processors etc to work on them
20:29:34 [JeniT]
... we would get better interoperability across these applications
20:30:05 [JeniT]
masinter: is it a requirement that it's consistent with the HTML parser?
20:30:19 [jar]
norm: There is LOTS of broken XML out there
20:30:24 [JeniT]
Norm: as compatible as it can be without torturing the spec
20:30:31 [JeniT]
masinter: for these use cases
20:31:02 [JeniT]
Norm: the requirement is that the processor processes it without falling over
20:31:23 [JeniT]
ht: this is a perfect demonstration for why a declarative definition would be better
20:31:33 [JeniT]
... we could process with both an XML-ER and HTML parser to see
20:31:49 [JeniT]
masinter: is there a requirement that they be equivalent? I think I've heard not
20:31:59 [JeniT]
Norm: the vast majority cases are really easy to fix
20:32:07 [JeniT]
... missing angle brackets, quotes and so on
20:32:15 [JeniT]
... the focus is on recovering bad data
20:32:26 [JeniT]
... we don't want to get into "correct" interpretations
20:32:36 [JeniT]
... we need to fix up the obvious mistakes
20:32:58 [JeniT]
noah: the RSS case is different: it's divided between what humans see and those they can't
20:33:24 [JeniT]
... automatic processes on sensitive documents is risky
20:33:49 [JeniT]
Norm: if you have mission critical data going through this, you deserve what you get
20:34:07 [JeniT]
noah: if we can refine the use case to exclude these scenarios
20:34:22 [JeniT]
Norm: you can't tell people how to use your spec
20:34:26 [JeniT]
noah: but you can warn them
20:34:28 [masinter]
Can this be defined as a sequence of fixup transformations?
20:35:02 [JeniT]
timbl: I don't think we have to warn people about obvious things
20:35:09 [masinter]
which isn't either declarative or procedural
20:35:34 [JeniT]
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
20:35:52 [JeniT]
masinter: there's another way of defining the spec as fix-up transformations
20:36:08 [JeniT]
noah: if I were doing it declaratively, I think I'd do it as fix-up transformations
20:36:17 [JeniT]
masinter: then you don't have to worry about the DOM tree at all
20:36:34 [JeniT]
... you can have a pre-processor that does the first fixups
20:36:38 [JeniT]
ht: that's how tagsoup works
20:36:46 [JeniT]
... which the CG is ignoring
20:36:52 [masinter]
what's wrong with tagsoup?
20:37:46 [JeniT]
masinter: we should ask the XML-ER CG why they are ignoring it
20:38:18 [JeniT]
noah: the HTML5 spec took into account what browsers were using and other inputs
20:38:27 [JeniT]
ht: I think Hixie only looked at what the browsers were doing
20:38:36 [JeniT]
noah: this fits into that path
20:39:01 [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?
20:39:01 [JeniT]
Ashok: does tagsoup handle these use cases?
20:39:13 [JeniT]
ht: tagsoup is best-of-breed, nearly the only one
20:39:34 [JeniT]
... it has two phases: a micro phase and a macro phase
20:39:48 [JeniT]
... the micro phase is done at the level of angle brackets and equal signs
20:39:56 [JeniT]
... macro phase at open & close tag level
20:40:01 [noah]
ACTION: Noah to record final closing of work on HTML/XML Unification in product page Due 2012-08-01
20:40:01 [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].
20:40:01 [jar] ?
20:40:04 [JeniT]
... not quite well-formedness vs. validity
20:40:11 [JeniT]
Norm: tagsoup is also table driven
20:40:14 [Ashok]
Ashok has joined #tagmem
20:40:22 [JeniT]
ht: yes, but it does useful work with an empty table
20:40:32 [JeniT]
JeniT: is it specced anywhere?
20:40:39 [JeniT]
ht: there's something approximating a spec
20:40:56 [JeniT]
... and I've done work with a grad student to make the table declarative
20:41:11 [JeniT]
... so it's an open question how well tagsoup would do at satisfying the RSS use case
20:41:11 [masinter]!topic/tagsoup-friends/Y2qA29CM4n4
20:41:22 [JeniT]
... I don't know which use cases the XML-ER CG has written down
20:41:40 [JeniT]
Ashok: but take MarkLogic, where they really need this
20:41:45 [masinter]
"" ?
20:41:49 [JeniT]
ht: Norm, why doesn't MarkLogic use tagsoup?
20:41:58 [JeniT]
Norm: probably because it's written in Java
20:42:04 [jar]
"The semantics of TagSoup are as far as practical those of actual HTML browsers."
20:42:08 [JeniT]
... I think we have tidy incorporated
20:42:46 [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." --
20:42:55 [JeniT]
noah: anything else we should be talking about?
20:43:02 [JeniT]
JeniT: media type maybe?
20:43:45 [JeniT]
Norm: yes, we're talking about processing documents where the media type is a lie: it says its application/xml when it isn't
20:44:10 [JeniT]
noah: the authoritative metadata finding suggests that if the user has input, that's OK
20:44:33 [JeniT]
Norm: yes, one thing is to try with an XML parser, and then try again with the XML-ER parser if it fails
20:44:39 [JeniT]
masinter: it depends on context
20:45:14 [JeniT]
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
20:45:17 [noah]
Tag finding on authoritative metadata, pertinent section:
20:45:21 [JeniT]
masinter: is this intended for XHTML or all XML?
20:45:23 [masinter]
is this really intended for ALL XML?
20:45:31 [noah]
Good practice: Web agents SHOULD have a configuration option that enables the display or logging of detected errors.
20:45:33 [masinter]
both of the use cases were HTML
20:45:35 [JeniT]
Norm: intended for all XML, on XHTML I think I'd just use an HTML parser
20:45:52 [noah]
20:46:02 [noah]
Constraint: An agent MUST NOT ignore or override authoritative metadata without the consent of the party employing the agent.
20:46:03 [JeniT]
masinter: what kinds of documents would you be reading into a database?
20:46:16 [JeniT]
Norm: some horrendous stuff from database dumps and logs and so on and on
20:46:22 [masinter]
question is what the nature of the errors are and where they came from
20:46:26 [ht_home]
TagSoup references:,">,
20:46:29 [masinter]
RSS feeds are different
20:46:30 [JeniT]
... that's where I've encountered this problem
20:46:50 [ht_home]
Pyxup (declarative version from me):
20:46:55 [JeniT]
noah: I've added links to the authoritative metadata finding where we talk about this
20:47:33 [JeniT]
... other than that, I don't think we're discouraging it
20:47:39 [JeniT]
masinter: what about HTML Tidy?
20:47:44 [JeniT]
ht: it's even less documented
20:47:53 [JeniT]
... you could ask Dave Raggett to help you decompile it
20:48:07 [JeniT]
timbl: I don't think Dave is a committer now
20:48:25 [JeniT]
... you could fit it into the test suite
20:48:36 [JeniT]
noah: the fixups you might want to do would depend on the use case
20:48:52 [JeniT]
... Tidy was mostly used by authors to clean up what they'd written
20:49:01 [ht_home]
I believe the open source Tidy project is dormant
20:49:09 [JeniT]
... but stuff in the HTML spec is done by the user agent
20:49:24 [JeniT]
ht: I use Tidy to convert HTML to XHTML so I can work with it
20:49:35 [JeniT]
timbl: I use Tidy to help me publish as polyglot
20:50:00 [timbl__]
20:50:16 [JeniT]
noah: is there any followup from us?
20:50:25 [JeniT]
Norm: I'm going to try to get the group re-energised
20:50:49 [timbl__]
HTMLtidy - Revision 1.46 - Wed Mar 25 21:37:11 2009 UTC (3 years, 2 months ago) by arnaud02
20:50:58 [JeniT]
... I'm inclined to say that anyone in the TAG who wants to influence direction should join the CG
20:51:12 [JeniT]
... I can keep coming and giving status updates
20:51:16 [noah]
20:51:58 [JeniT]
(Norm is directed to upload a picture)
20:51:59 [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
20:52:07 [JeniT]
Ashok: how active is the group?
20:52:27 [JeniT]
Norm: there was a flurry of mail earlier in the year, and it's been dormant over the last few months
20:52:37 [JeniT]
... I'm going to try to get it going again
20:53:01 [JeniT]
noah: on the TAG side, we just closed down HTML/XML work: we're not doing anything formally now
20:53:18 [JeniT]
... do we need to follow up more formally?
20:53:37 [JeniT]
masinter: I think we should give them feedback to look at tagsoup and to ask about use cases
20:53:47 [JeniT]
Norm: if someone wants to chime in about tagsoup, that would be good
20:54:25 [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)
20:54:27 [JeniT]
ht: it's easier to give input if there are use cases and test suites
20:54:39 [JeniT]
noah: should we have an action?
20:55:09 [JeniT]
ht: we don't need to: Norm's heard, Jeni's heard, Robin will read the minutes
20:55:29 [JeniT]
noah: we've decided we don't need to do any more
20:56:02 [JeniT]
... thank you again to Norm for all his work
20:56:35 [Zakim]
20:56:37 [Zakim]
- +1.617.715.aaaa
20:56:37 [Zakim]
TAG_f2f()8:00AM has ended
20:56:37 [Zakim]
Attendees were +1.617.715.aaaa, Norm
20:57:03 [JeniT]
Ashok: I think this work will just dribble away
20:57:23 [JeniT]
s/think/have a fear that/
20:58:13 [JeniT]
20:59:13 [JeniT]
masinter: if you talk about proliferation of schemes, please look at RFC 4395bis on scheme registration guidelines
20:59:24 [JeniT]
... we want to make it easier to register schemes
20:59:42 [JeniT]
... because the consensus of IETF is that making it hard to register schemes is lots of unregistered schemes
21:00:08 [noah]
Larry wants us to look at RFC 4395bis when we talk about scheme proliferation -- it attempts to facilitate scheme registration.
21:00:18 [JeniT]
... there's a lot of reasons why you wouldn't want to deploy schemes or use schemes
21:00:22 [noah]
LM: You might not want to deploy or use them all, but registering them is often good
21:00:26 [JeniT]
... but that's different from not registering them
21:00:59 [JeniT]
... it's not much of a risk when you have a scheme that isn't recognised
21:01:10 [JeniT]
timbl: the only risk is if two people take the same unregistered scheme
21:01:55 [masinter]
masinter has joined #tagmem
21:02:45 [noah]
21:03:30 [JeniT]
masinter: I like narrowing CSS prefixes to extracting documentation of deployment plan in CSS documents and make it a separate document
21:03:45 [JeniT]
... then see if we can extract important aspects of deployment plan
21:03:52 [JeniT]
... as hints for how to plan for extensibility
21:04:17 [JeniT]
... some people think CSS prefixes is successful, and we should capture what works about it
21:06:01 [JeniT]
21:10:33 [JeniT]
JeniT has joined #tagmem
21:34:33 [ht]
ht has joined #tagmem
23:07:44 [ht]
ht has joined #tagmem
23:54:22 [JeniT]
JeniT has joined #tagmem