- From: Jeni Tennison <jeni@jenitennison.com>
- Date: Tue, 19 Jun 2012 20:19:50 +0100
- To: "www-tag@w3.org List" <www-tag@w3.org>
Hi,
The draft minutes from Wednesday 13th June 2012 TAG F2F meeting are available at
http://www.w3.org/2001/tag/2012/06/13-minutes
and reproduced below. Note that the HTML version has pictures!
Cheers,
Jeni
---
[1]W3C
[1] http://www.w3.org/
- DRAFT -
This is version has not been approved as a true record of the
TAG's meeting and there is some risk that individual TAG
members have been misquoted. This transcript should typically
not be quoted, except as necessary to arrange for correction
and approval.
W3C TAG F2F 2012-06-13
13 Jun 2012
See also: [2]IRC log
[2] http://www.w3.org/2012/06/13-tagmem-irc
Attendees
Present
Noah_Mendelsohn, Larry_Masinter, Ashok_Malhotra,
Peter_Linss, Henry_Thompson, Tim_Berners-Lee,
Jeni_Tennison, Jonathan_Rees, Robin_Berjon_(partial,
on_phone), Yves_Lafon_(partial, on_phone),
Norm_Walsh_(partial, on_phone)
Regrets
Chair
Noah Mendelsohn
Scribe
Larry Masinter, JeniT
Contents
* [3]Topics
1. [4]Storage
2. [5]TAG Effectiveness
3. [6]Positioning of Web and Native applications
4. [7]Administration
5. [8]TAG Priorities 2012
6. [9]HTML/XML Unification
7. [10]Issues for Thursday
* [11]Summary of Action Items
__________________________________________________________
<scribe> scribenick: masinter
<scribe> scribe: Larry Masinter
Storage
noah: Storage including synchronization
<plinss>
[12]http://lists.w3.org/Archives/Public/www-tag/2012Jun/0032.ht
ml
[12] http://lists.w3.org/Archives/Public/www-tag/2012Jun/0032.html
<noah> ACTION-647?
<trackbot> ACTION-647 -- Robin Berjon to draft product page on
client-side storage focusing on specific goals and success
criteria -- due 2012-06-29 -- OPEN
<trackbot>
[13]http://www.w3.org/2001/tag/group/track/actions/647
[13] http://www.w3.org/2001/tag/group/track/actions/647
<noah> Robin recommends:
<noah> [The TAG SHOULD NOT] attempt to provide a solution for
synchronisation problems. It is a complex research area, and if
a standardised solution were to be established (which may not
be necessary, and certainly not yet) it ought to be created by
a dedicated working group with the requisite expertise.
<noah> there could be room for the TAG to release a short
advisory note that would document 1) the known pitfalls in
dealing with data synchronisation, 2) the primary patterns and
solutions, and 3) an overview of the terms of the trade. The
goal of such a document would be to ensure that someone who may
be an adept Web application developer but has no knowledge of
this specific problem space to save precious time by being
bootstrapped with the basics one needs to s
I suggest this is a topic for the TAG Blog
<noah> I hadn't meant to ask about synchronization
<darobin>
[14]http://lists.w3.org/Archives/Public/www-tag/2012Jun/0035.ht
ml
[14] http://lists.w3.org/Archives/Public/www-tag/2012Jun/0035.html
noah: in terms of other storage work, what should the TAG do?
darobin: In terms of architecture, it would be useful to
revisit the notions we have URI stability, in terms of
distributed minting of URIs
... we might want to look at versioning, and the databases are
massively distributed and unlikely to be running the same
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> [15]http://en.wikipedia.org/wiki/CAP_theorem
[15] http://en.wikipedia.org/wiki/CAP_theorem
<noah>
[16]http://www.julianbrowne.com/article/viewer/brewers-cap-theo
rem
[16] http://www.julianbrowne.com/article/viewer/brewers-cap-theorem
timbl: Mac has had over years sync services, and still over the
years there are failures
noah: if you're willing to keep some amount of state and don't
have ((various caveats)) unbounded number of replicates, this
is a "solved problem"
timbl: Robin said this is still a research issue
noah: the research is for cases which are more complicated
timbl: (description of situations where synchronization has
failed for him on odd occasions)
ashok: re vendor lockin: what is required is that you can take
your data and move it to another machine
... thinking about replication: what has happened in the last
few years is NoSQL
... they replicate the databases to make them all available
<noah> We have 20 mins or so to settle what TAG is doing in
this space.
ashok: They have this semantics of "eventually consistence"
... that works OK if there is no semantic difficulty
timbl: the mac has a layer where it generates a UI and asks the
user about semantics
ashok: if you use CouchDB, it keeps copies of your documents,
and ... ((...)) ...
... if you don't have conflicts it is a solved problem. If you
do have conflicts, ... (something)...
... I want the WebApps guys to make an interface to SQL
... if you use SQL, the database syncs, it's what databases do
... databases can even send you updates to previous queries
<noah> I think it's also a difficult problem if the existence
of replicas is not well controlled. I believe Lotus Notes
allows anyone to create new replicas, which means you can
>never< be sure you've been in touch with all the replicas.
<noah> In Notes, this is dealt with be assuming that all
replicas are (transitively) in touch over, say, ever 6 months.
If you leave a laptop in a drawer for 2 years and reboot, you
can have things like deleted records reappearing. So, that case
remains hard as far as I know.
timbl: from the RDF point of view, it would be appealing to
define sync for arbitrary RDF graphs
noah: (time)
... there were two items: storage & synchronization
ashok: robin spoke about 2 things
noah: we need to define what the TAG is doing
... what is the TAG's business?
... Synchronization vs. Storage, what do you think the TAG
should pursue?
ashok: when robin started, he said "we could write something
that would alert people about storage"
<timbl> We did sync stuff with cwm in the SWAP project around
2001 [17]http://www.w3.org/DesignIssues/Diff
[17] http://www.w3.org/DesignIssues/Diff
jeni: why not bite of syncrhonization about storage
... would like some kind of output
noah: I think someone needs to research the state of the art,
looking at web environment, all in the context of writing
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 LD
platform could provide a framework for unwalled synchronization
. Surveying sync literature is uninteresting, because nobody
will come to us for that.
... I think the community won't look to us for that. What might
be useful is to narrow focus to linked data synchronization.
<Zakim> timbl, you wanted to about sync being proprietory
<noah> It occurs to me that things like Dropbox are very widely
deployed embodiments of sync, albeit at the file level.
<noah> rsync is also pertinent to a degree, I think, though as
far as I know it's not bi-directional.
timbl: because the architecture was hub (or adaptor and hub)
and spoke
... EAI Enterprise Application Integration (something)
... that may be why syncrhonization is a black art: the market
is based on solutions where the hub is a black art
<Zakim> JeniT, you wanted to say that the interesting thing is
synchronisation on the web, with the use of URIs and of REST,
and standard formats, all of which LDP should take full
<noah> +1 to what Jeni's about to say :-)
jeni: what i think is interesting is applying the principles
we've learned in other systems. If it's done right, LDP should
be a great example of it being done right
ashok: it's an example we're interested in
jar: message shouldn't be "You should do it this way" but "If
you want to do it this way, here's how"
... and what advantages you might get
masinter: the question is -- update conflict resolution in
general requires understanding the application -- does using
link data deconstruct updates such that a generic conflict
resolution mechanism for rdf graphs could be used?
noah: who's willing to do X
jeni: i'd rather someone have an action to write something
noah: (wants a product page)
(discussion of whether we're doing a product page or a document
or ...)
ashok: I'll talk to Robin when I can catch him
<noah> ACTION: Ashok to propose outline for possible TAG
document (finding or rec) on architectural issues relating to
storage sync, linked data, etc. Due 2012-07-15 [recorded in
[18]http://www.w3.org/2001/tag/2012/06/13-minutes#action01]
[18] http://www.w3.org/2001/tag/2012/06/13-minutes#action01
<trackbot> Created ACTION-717 - Propose outline for possible
TAG document (finding or rec) on architectural issues relating
to storage sync, linked data, etc. Due 2012-07-15 [on Ashok
Malhotra - due 2012-06-20].
<noah> ACTION: Ashok to propose goals and success critera for
TAG work on architectural issues relating to storage sync,
linked data, etc. Due 2012-08-15 [recorded in
[19]http://www.w3.org/2001/tag/2012/06/13-minutes#action02]
[19] http://www.w3.org/2001/tag/2012/06/13-minutes#action02
<trackbot> Created ACTION-718 - Propose goals and success
critera for TAG work on architectural issues relating to
storage sync, linked data, etc. Due 2012-08-15 [on Ashok
Malhotra - due 2012-06-20].
i think the scope in the action is broader than i wanted
<noah> ACTION-647?
<trackbot> ACTION-647 -- Robin Berjon to draft product page on
client-side storage focusing on specific goals and success
criteria -- due 2012-06-29 -- OPEN
<trackbot>
[20]http://www.w3.org/2001/tag/group/track/actions/647
[20] http://www.w3.org/2001/tag/group/track/actions/647
<noah> close ACTION-647
<trackbot> ACTION-647 Draft product page on client-side storage
focusing on specific goals and success criteria closed
<noah> ACTION-693?
<trackbot> ACTION-693 -- Robin Berjon to draft scope and goals
for the Patterns/Pitfalls work in local/remote storage synch --
due 2012-04-19 -- PENDINGREVIEW
<trackbot>
[21]http://www.w3.org/2001/tag/group/track/actions/693
[21] http://www.w3.org/2001/tag/group/track/actions/693
<noah> close ACTION-693
<trackbot> ACTION-693 Draft scope and goals for the
Patterns/Pitfalls work in local/remote storage synch closed
TAG Effectiveness
noah: Jeni suggested some meeting facilitation methods to use,
so I will turn the meeting over to her
... I think it is important that we think carefully about what
we're trying to achieve
... People come in and complain "the community isn't listening
..."
... and i ask myself whether the charter is wrong or whether
we're performing it wrong
... people complain X and propose Y but it's easy to jump to
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> [22]https://en.wikipedia.org/wiki/SWOT_analysis
[22] https://en.wikipedia.org/wiki/SWOT_analysis
jeni: structure brainstorming of strengths and weaknesses.....
... opportunities and threats, 10 minutes for each to write
down, and group to write down
... one we can prioritize, do brainstorming first, clusters
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)
Initial uncategorized postings (click for high resolution)
[23][StrengthsUCSm.jpg]
[23] http://www.w3.org/2001/tag/2012/06/StrengthsUCMed.jpg
[24][WeaknessUCSm.jpg]
[24] http://www.w3.org/2001/tag/2012/06/WeaknessUCMed.jpg
[25][OpportunitiesUCSm.jpg]
[25] http://www.w3.org/2001/tag/2012/06/OpportunitiesUCMed.jpg
[26][ThreatsUCSm.jpg]
[26] http://www.w3.org/2001/tag/2012/06/ThreatsUCMed.jpg
jeni: big strength is experience, expertise, knowledge
... other big category strength is we're good people
... others access to W3C, TimBL
... weakness: thrashing, ratholing
... weakness: conflict within group
... weakness: problems around time available for tag work
... weakness: travel funding
... weakness: quite a lot of membership churn
... weakness: lack of knowledge in specific areas (security,
privacy, network protocols)
... weakness: our ability to educate others, lack of power,
lack of enforcement
... threat: bad PR
... threat: creating recommendations take a long time
... threat: general issues around connection with other groups
... threat: liaison to other groups (ECMA, OASIS)
... threat: web is moving, getting broader, more areas
... opportunity: side: help persuade community
... opportunity: liaise with ietf iab
... opportunity: meet more with customers, chairs, staff
... opportunity: (2 more)
After clustering in categories (click for high resolution)
[27][StrengthsCatSm.jpg]
[27] http://www.w3.org/2001/tag/2012/06/StrengthsCatMed.jpg
[28][WeaknessCatSm.jpg]
[28] http://www.w3.org/2001/tag/2012/06/WeaknessCatMed.jpg
[29][OpportunitiesCatSm.jpg]
[29] http://www.w3.org/2001/tag/2012/06/OpportunitiesCatMed.jpg
[30][ThreatsCatSm.jpg]
[30] http://www.w3.org/2001/tag/2012/06/ThreatsCatMed.jpg
((ashok is typing outline))
noah: we should find some middle ground to find some high-value
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.
[Categories.jpg]
<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
Positioning of Web and Native applications
[31]http://www.w3.org/2001/tag/2012/06/12-agenda#nativevsweb
[31] http://www.w3.org/2001/tag/2012/06/12-agenda#nativevsweb
masinter: the main point from this was the death of the
application layer
... native vs web app was one question among many
noah: so Hannes wasn't asking us to take on long-term work
... I still think it's an interesting question
... is this a promising area? it feels like it is to me
... web vs. native, and within the web app, things that used to
be managed at the protocol level are now being managed through
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>
[32]http://en.wikipedia.org/wiki/Dynamic_Adaptive_Streaming_ove
r_HTTP
[32] http://en.wikipedia.org/wiki/Dynamic_Adaptive_Streaming_over_HTTP
noah: devices have APIs
... native apps are written to exploit the platform APIs
... not tuned to write application that run on a different
device or platform
... released in lock step with device releases
... people wrongly associate it with marketplaces, and charging
Ashok: it does not run in the browser
noah: but some use Webkit components for example
Ashok: does it work with a server?
noah: many do
Ashok: can you access another external website?
noah: some do some don't
... I bet weather apps use RESTful APIs to access their data
... ESPN apps appear purely native, and you then get a web
page, no back button
plinss: not a full interactive browser
noah: some intercept links, some don't
Ashok: the only difference I'm seeing is that they don't run in
the browser
noah: that has huge implications
masinter: no it doesn't
Ashok: so it doesn't run in browser, and it has priviledged
access to hardware?
noah: plugging iPad into mixing device
... we have nothing in the web space to do that
... people are building businesses on that
Ashok: I'm trying to figure out what the differences are
noah: native priviledged control of hardware
jar: but this could also apply to communication with a server
... proprietary protocols between two parts of the system
... if you have an application in mind and it involves a
client/server, your choice is affected by multiple
considerations
<masinter> [33]http://phonegap.com/
[33] http://phonegap.com/
<masinter> Apache Cordova (aka PhoneGap) uses web
infrastructure to build apps
<masinter> "proprietary protocols" => "private device APIs"
<masinter> WebIDL should be in scope for architecture
Ashok: the part that uses the hardware, the special hardware,
that *has* to run on the device
jar: the special hardware could be on the server
masinter: I have 40 native apps on my phone, none of which
access specialised hardware
noah: analogy between relationships between Macs and
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> [34]http://phonegap.com/about
[34] http://phonegap.com/about
<masinter>
[35]http://phonegap.com/2012/04/12/rolling-releases-how-apache-
cordova-becomes-phonegap-and-why/
[35] http://phonegap.com/2012/04/12/rolling-releases-how-apache-cordova-becomes-phonegap-and-why/
timbl: the idea of redesigning from scratch sounds like a bad
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
[36]http://www.w3.org/2001/tag/2012/06/13-minutes#action03]
[36] http://www.w3.org/2001/tag/2012/06/13-minutes#action03
<trackbot> Created ACTION-719 - Reply to Hannes pointing to the
minutes, summarizing the discussion, and asking him if he has
any more specific questions. [on Larry Masinter - due
2012-06-20].
<masinter> [37]http://incubator.apache.org/cordova/
[37] http://incubator.apache.org/cordova/
Administration
noah: tentatively between 7-10th Oct in UK
... agreement on 7-9th Oct in London?
<scribe> ACTION: Noah to make sure we have somewhere to meet in
London 7-9th October [recorded in
[38]http://www.w3.org/2001/tag/2012/06/13-minutes#action04]
[38] http://www.w3.org/2001/tag/2012/06/13-minutes#action04
<trackbot> Created ACTION-720 - Make sure we have somewhere to
meet in London 7-9th October [on Noah Mendelsohn - due
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)
TAG Priorities 2012
noah: we're doing good work on fragids
... taking serious run at ISSUE-57
... publishing & linking is kind of ok, except main assignee
(JeniT) also doing the other main priorities
<scribe> ACTION: Noah to update product index to target date on
publishing & linking [recorded in
[39]http://www.w3.org/2001/tag/2012/06/13-minutes#action05]
[39] http://www.w3.org/2001/tag/2012/06/13-minutes#action05
<trackbot> Created ACTION-721 - Update product index to target
date on publishing & linking [on Noah Mendelsohn - due
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
HTML/XML Unification
<noah>
[40]http://lists.w3.org/Archives/Public/www-tag/2012Jun/0051.ht
ml
[40] 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>
[41]http://www.w3.org/2001/tag/products/htmlxmlunification.html
[41] http://www.w3.org/2001/tag/products/htmlxmlunification.html
noah: I propose we close out the HTML/XML work
... declare success on this bit of the work
Norm: I'm agnostic
... in the perfect world, we might want to do more work along
the lines that was originally envisaged
... but we should move in the direction of the community
noah: we need to make a decision not to pursue other aspects
from the report
timbl: unless there's some huge thing that people haven't
noticed, we should follow what the community is doing
ht: my energy is going to go on monitoring polyglot
... because it's the XHTML constituency that we have
responsibility towards
Norm: that's a good and wise thing to do
<noah> . RESOLUTION: The TAG notes the publication of the
HTML/XML Task Force Report on 9 Feb 2012, the focus of the
community on XML-ER. We thank Norm Walsh for his wonderful
assitance to the TAG, and close our formal project on HTML/XML.
ht: as long as I can continue to monitor polyglot, closing is
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> [42]http://dev.w3.org/html5/markup/ is declarative
[42] http://dev.w3.org/html5/markup/
noah: I'd love to see it done declaratively, but I don't think
we should fight it now
... I wish I had the time to do it
Norm: if someone looked at Anne's draft and picked some subset
and rewrote it using declarative rules
... doing a large enough section so that other people in the CG
who aren't familiar enough with declarative approach might be
shown how it works
masinter: HTML5 is defined declaratively, there's a document
that does it
<masinter> [43]http://dev.w3.org/html5/markup/
[43] http://dev.w3.org/html5/markup/
Norm: there's an exposition of how it's done, but it's not
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
[44]http://www.w3.org/2001/tag/2012/06/13-minutes#action06]
[44] http://www.w3.org/2001/tag/2012/06/13-minutes#action06
<trackbot> Created ACTION-723 - Record final closing of work on
HTML/XML Unification in product page Due 2012-08-01 [on Noah
Mendelsohn - due 2012-06-20].
<jar>
[45]http://mvnrepository.com/artifact/org.ccil.cowan.tagsoup/ta
gsoup/1.2 ?
[45] http://mvnrepository.com/artifact/org.ccil.cowan.tagsoup/tagsoup/1.2
ht: not quite well-formedness vs. validity
Norm: tagsoup is also table driven
ht: yes, but it does useful work with an empty table
JeniT: is it specced anywhere?
ht: there's something approximating a spec
... and I've done work with a grad student to make the table
declarative
... so it's an open question how well tagsoup would do at
satisfying the RSS use case
<masinter>
[46]https://groups.google.com/forum/?fromgroups#!topic/tagsoup-
friends/Y2qA29CM4n4
[46] https://groups.google.com/forum/?fromgroups#!topic/tagsoup-friends/Y2qA29CM4n4
ht: I don't know which use cases the XML-ER CG has written down
Ashok: but take MarkLogic, where they really need this
<masinter>
"[47]http://groovy.codehaus.org/api/groovy/util/XmlSlurper.html
" ?
[47] http://groovy.codehaus.org/api/groovy/util/XmlSlurper.html
ht: Norm, why doesn't MarkLogic use tagsoup?
Norm: probably because it's written in Java
<jar> "The semantics of TagSoup are as far as practical those
of actual HTML browsers."
[48]http://ccil.org/~cowan/XML/tagsoup/#what
[48] http://ccil.org/~cowan/XML/tagsoup/#what
Norm: I think we have tidy incorporated
<timbl__> "BeautifulSoup is closer to my TagSoup, but is
written in Python and returns a parse tree. I believe its
heuristics are hard-coded for HTML. There is a port to Ruby
called RubyfulSoup." -- [49]http://ccil.org/~cowan/XML/tagsoup/
[49] http://ccil.org/~cowan/XML/tagsoup/
noah: anything else we should be talking about?
JeniT: media type maybe?
Norm: yes, we're talking about processing documents where the
media type is a lie: it says its application/xml when it isn't
noah: the authoritative metadata finding suggests that if the
user has input, that's OK
Norm: yes, one thing is to try with an XML parser, and then try
again with the XML-ER parser if it fails
masinter: it depends on context
Norm: one of the goals of a parser is that it should produce
the same thing as an XML parser on a well-formed XML document
<noah> Tag finding on authoritative metadata, pertinent
section:
[50]http://www.w3.org/2001/tag/doc/mime-respect-20060412#silent
-recovery
[50] http://www.w3.org/2001/tag/doc/mime-respect-20060412#silent-recovery
masinter: is this intended for XHTML or all XML?
<masinter> is this really intended for ALL XML?
<noah> Good practice: Web agents SHOULD have a configuration
option that enables the display or logging of detected errors.
<masinter> both of the use cases were HTML
Norm: intended for all XML, on XHTML I think I'd just use an
HTML parser
<noah>
[51]http://www.w3.org/2001/tag/doc/mime-respect-20060412#consen
t
[51] http://www.w3.org/2001/tag/doc/mime-respect-20060412#consent
<noah> Constraint: An agent MUST NOT ignore or override
authoritative metadata without the consent of the party
employing the agent.
masinter: what kinds of documents would you be reading into a
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:
[52]http://home.ccil.org/~cowan/XML/tagsoup/tagsoup.pdf,
[53]http://home.ccil.org/~cowan/XML/tagsoup/
[52] http://home.ccil.org/~cowan/XML/tagsoup/tagsoup.pdf
[53] http://home.ccil.org/~cowan/XML/tagsoup/
<masinter> RSS feeds are different
Norm: that's where I've encountered this problem
<ht_home> Pyxup (declarative version from me):
[54]http://conferences.idealliance.org/extreme/html/2007/Thomps
on01/EML2007Thompson01.html
[54] http://conferences.idealliance.org/extreme/html/2007/Thompson01/EML2007Thompson01.html
noah: I've added links to the authoritative metadata finding
where we talk about this
... other than that, I don't think we're discouraging it
masinter: what about HTML Tidy?
ht: it's even less documented
... you could ask Dave Raggett to help you decompile it
timbl: I don't think Dave is a committer now
... you could fit it into the test suite
noah: the fixups you might want to do would depend on the use
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__> [55]http://tidy.sourceforge.net/
[55] http://tidy.sourceforge.net/
<timbl__> HTMLtidy - Revision 1.46 - Wed Mar 25 21:37:11 2009
UTC (3 years, 2 months ago) by arnaud02
noah: is there any followup from us?
Norm: I'm going to try to get the group re-energised
... I'm inclined to say that anyone in the TAG who wants to
influence direction should join the CG
... I can keep coming and giving status updates
<noah> [56]http://www.w3.org/community/xml-er/
[56] http://www.w3.org/community/xml-er/
(Norm is directed to upload a picture)
<masinter> given deployment of tagsoup and xmltidy, it is
likely that they won't go away, and thus the goal of the group
is there a standard for fixup won't be accomplished
Ashok: how active is the group?
Norm: there was a flurry of mail earlier in the year, and it's
been dormant over the last few months
... I'm going to try to get it going again
noah: on the TAG side, we just closed down HTML/XML work: we're
not doing anything formally now
... do we need to follow up more formally?
masinter: I think we should give them feedback to look at
tagsoup and to ask about use cases
Norm: if someone wants to chime in about tagsoup, that would be
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
Issues for Thursday
<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>
[57]http://tools.ietf.org/id/draft-ietf-iri-4395bis-irireg-04.t
xt
[57] http://tools.ietf.org/id/draft-ietf-iri-4395bis-irireg-04.txt
masinter: I like narrowing CSS prefixes to extracting
documentation of deployment plan in CSS documents and make it a
separate document
... then see if we can extract important aspects of deployment
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
Summary of Action Items
[NEW] ACTION: Ashok to propose goals and success critera for
TAG work on architectural issues relating to storage sync,
linked data, etc. Due 2012-08-15 [recorded in
[58]http://www.w3.org/2001/tag/2012/06/13-minutes#action02]
[NEW] ACTION: Ashok to propose outline for possible TAG
document (finding or rec) on architectural issues relating to
storage sync, linked data, etc. Due 2012-07-15 [recorded in
[59]http://www.w3.org/2001/tag/2012/06/13-minutes#action01]
[NEW] ACTION: Larry to reply to Hannes pointing to the minutes,
summarizing the discussion, and asking him if he has any more
specific questions. [recorded in
[60]http://www.w3.org/2001/tag/2012/06/13-minutes#action03]
[NEW] ACTION: Noah to make sure we have somewhere to meet in
London 7-9th October [recorded in
[61]http://www.w3.org/2001/tag/2012/06/13-minutes#action04]
[NEW] ACTION: Noah to record final closing of work on HTML/XML
Unification in product page Due 2012-08-01 [recorded in
[62]http://www.w3.org/2001/tag/2012/06/13-minutes#action06]
[NEW] ACTION: Noah to update product index to target date on
publishing & linking [recorded in
[63]http://www.w3.org/2001/tag/2012/06/13-minutes#action05]
[58] http://www.w3.org/2001/tag/2012/06/13-minutes#action02
[59] http://www.w3.org/2001/tag/2012/06/13-minutes#action01
[60] http://www.w3.org/2001/tag/2012/06/13-minutes#action03
[61] http://www.w3.org/2001/tag/2012/06/13-minutes#action04
[62] http://www.w3.org/2001/tag/2012/06/13-minutes#action06
[63] http://www.w3.org/2001/tag/2012/06/13-minutes#action05
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [64]scribe.perl version
1.136 ([65]CVS log)
$Date: 2012/06/19 19:17:58 $
[64] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[65] http://dev.w3.org/cvsweb/2002/scribe/
--
Jeni Tennison
http://www.jenitennison.com
Received on Tuesday, 19 June 2012 19:20:20 UTC