See also: IRC log
<DanC_lap> Scribe: DanC
<DanC_lap> ScribeNick: DanC_lap
NM reviews goals...
"Review F2F Goals
* Bring new TAG members "up to speed" on continuing work
* Make progress on high priority technical issues
* Establish TAG priorities for coming year - ensure issues list reflects actual priorities
* Refine TAG administrative procedures
"
TimBL: welcome to new tag members!
I'm excited to get the burst of new momentum that comes with new
members...
... and thanks Noah for chairing!
NM: by way of agenda review... not as
much in the way of drafts to review in preparation for this
meeting...
... thanks, ashok, for arranging the meeting facilities
... we'll start with active technical work on the 1st day before
stepping back to look at overall priorities
... we'll talk about meeting schedule etc. this PM; if you can
check your calendar during a break, that'll probably help
LMM: for this AM, I should defer input on priorities?
NM: well, I don't want to start 1st thing with wiping the slate and setting priorities, but this will be iterative
AM: conneg and redirections are related but scheduled separately...
NM: yes, they're related... we'll
see... we don't yet have an issue on conneg
... minutes 19 Feb http://www.w3.org/2001/tag/2009/02/19-minutes
...
2009/02/23 21:03:34
NM: we'll look at that later
JK: John Kemp, working for Nokia ~6
years; prior to that, liberty aliance, OASIS Security Services
Technical Committee; so my background in SOAP based Web Services,
XML, ...
... web applications, a few start-ups doing software as a services;
that goes back to ~1996
... I'm interested in the versioning and error handling stuff...
and web application security
LMM: Larry Masinter I'm Adobe. Was
doing metdata for video. Web Standards is now my full time job. In
the 1980s I worked on the Common Lisp standard...
... I was at Xerox Parc when KR was done with ()s rather than
<>s. Overlapped HT there.
... at Xerox we had experiments in networked information
retrieval... then I went to a gopher conn... then I heard about WWW
and downloaded a client...
... in the Common Lisp standards process, one of my main
contributions was an issue form where you had to describe the
problem independent of the solution and such.
... so I brought some of that experience to chairing the IETF URI
WG and the HTTP WG.
... I was on the W3C advisory board and helped develop the TAG
charter. I thought it was important to deal with conflicts between
WGs and show leadership
TVR: Raman ... at Google... I care a lot about the Web and I'm concerned that the Web is being defined in terms of browsers too much; perhaps in reaction to being too far from browsers for a decade or so.
TBL: never mind history, where I am
at now... when I find time for software, I work on systems where
the Web and the Semantic Web are completely integrated...
... where systems are connected with other systems we haven't
invented yet
<Zakim> timbl, you wanted to say Interested in arch coherence of the whole network of systems; the tech getting better not just older; very integrated sem web and web viewpoint; modularity
TimBL: I'm interested in the Web continuing to improve and involve and not fossilize
AM: Ashok Malhotra at Oracle, mostly
doing Web Services...
... but I'm also looking at taking relational data and mapping it
to the Semantic Web
HT: Henry Thompson; I'm half time W3C
Team and half time U. Edinburgh. My TAG time comes from the U.
Edinburgh time...
... some conflict with teaching duties this spring
... my background is in computational linguistics...
... a theme in my TAG work is to find ways to apply that
background
... I have a number of paused TAG tasks; some because I'm stuck,
some [for other reasons?]
... some of you know Harry Halpin, also at E. Edinburgh...
... Harry Halpin has now submitted his PhD thesis [applause]
<ht> scribenick: ht
DC: WebArch scales down as well as
up, I've been learning about that with my new G1 phone
... Stuff about privacy, caching, web on hip connecting to the big
Web
... HTML5 has a bit about offline apps
... The WebApps WG has published a WD on Widgets
... There's a Google OpenWeb advocacy group which I pointed ot the
Widgets work
... Free Software background, purposely multi-platform
... I'm the official Team Contact for the TAG
NM: DC is the human archive of the TAG
<scribe> scribenick: DanC_lap
JAR: my background is in computer
science, esp programming languages...
... was involved in capability security... and scheme standards
[much scheme/lisp experience in the TAG]
JAR: [something?] led me to the
phrama industry, molecular biology, which led me to science
commons...
... so I'm trying to help make the web better for science...
... URIs/naming, data integration, etc.
... I gather there's friction in using the web that we could do
something about
NM: Noah Mendelsohn... was at IBM...
operating systems... highly transparent distributed unix... XML and
SOAP... Java at IBM when Java was an "emerging technology"...
... I enjoy the overlap between my personal interests, my
employer's business interest and what the TAG does
... what Dan said about the smaller platforms... smartphones and
such... I see a tipping point approaching
SKW: Stuart Williams at Hewlett
Packard in Bristol, England. working in an HP labs group on
Semantic Web... growing with the linked data stuff...
... naming and addressing is a focus of mine... from bits, bytes
and nibbles... LAN mac addresses are 48bits and not [n]
bytes...
... also some work on how you can introduce devices that didn't
know each other; e.g. a phone and printer
... got involved in W3C... found myself elected to the TAG... found
myself co-chairing; after the WebArch, took a break for a couple
years, then another go at chairing... it's been a wonderful
community to work with
... expect to continue to do related work
"Background:
Several recent email threads have raised questions about the proper use of content negotiation on the Web. ..."
<DanC_> (hmm.. URI for "view on this bug" vs "this bug"; no, doesn't sound like a case for conneg to me)
<raman> correct.
<noah> Yes, Stuart, thank you. The Martin Nally question is squarely within webApplicationState-60
<ht> HST: I've produced a review of http://www.ltg.ed.ac.uk/~ht/TAG_conneg_200903.html
(hmm.. copy should go to www-archive. here's hoping)
<DanC_> "The RDF response (modulo the lack of redirection) implies the resource is not an IR" huh?
<skw> Raman wrote a finding on Generic Resources which also bears on this issue... and I'm wondersing whether there was a TAG issues that that was written against.
<DanC_> (for reference: http://www.w3.org/2001/tag/doc/alternatives-discovery.html )
<DanC_> HT's notes on conneg for TAG meeting
HT: in sum, yes, I see issues in this conneg thread that should be re-opened or opened
LMM: background... in the '80s, the
convention was naming, addressing, and routing... variant content
types wasn't the norm...
... [Weiser?] had an idea of variant forms... Xerox work at the
time asked these questions about "the gettysburg address" and such
when tim visited us... I wonder if that's where Tim got the
idea
TimBL: we could check the dates of my web architecture notes...
LMM: at the time, the idea was one
HTTP transaction per click...
... there's some stuff in the HTTP spec that should be updated...
just because the client knows 1000s of media types doesn't mean you
should send 1000s of accept headers... "deprecate conneg" wasn't
really what I meant
... I'm concerned that web architecture refers so directly to
HTTP-specific mechanisms...
... questions of best practices should be approached with extreme
caution...
... better to come up with descriptive findings "if you do X, then
Y" rather than "you should X"
[chair seems to be writing on the whiteboard; scribe hasn't looked at it]
JAR: I think the advice from the TAG
is pretty consistent and we could quickly address this...
... conneg came up "cool URIs for the semantic web", came up in
"XRDs" which they have since abandoned in favor of [x?], came up in
MH's question...
... this group's answer seems to be: we'd rather you didn't conneg
in [which situation?]
... a test for conneg is: does it violate common expectations
around a URI; does it lead a user to wrong [?] information. [?]
<timbl> Advice: Don't use conneg when it would mess up th eexpectations of normal web users
<jar> Test: If conneg might lead a use of the URI to the wrong result for some client, try to figure out a different way to do what you want to do.
<johnk> I agree with timbl's advice, however, a) what is the "wrong result" for a client that says it prefers RDF?
TVR: thanks for the nice summary, HT... on the generic resources finding... it was written using the old model of the web: one click, one http transaction...
<jar> see my email. The RDF might be viewable in a browser, so info provided by RDF should be same info as infor provided in HTML rep
TVR: then you got CGI... and conneg
still works...
... but with active content, where the HTTP response is a program
to run on the client, that turns the conneg situation upside
down
<ht> HST thinks his TAG blog entry refers wrt Ramans point: http://www.w3.org/QA/2007/10/the_impact_of_javascript_and_x.html
<Zakim> johnk, you wanted to ask about TAG finding on authoritative metadata in this context
JK: the authoritative metadata
finding has this notion of metadata in the container...
... is it relevant? does any of this [thread?] run counter to that
finding?
<johnk> http://www.w3.org/2001/tag/doc/mime-respect-20060412#why
HT: the authoritative metadata finding tells what should be done; it's relevant in that it tells me that the punning examples are not at all compelling
JK: conneg is not just about the server saying what the server has; there are cases where the client wants only RDF and leaves the server in a position of [?]
<Zakim> timbl, you wanted to say conneg between metadata and a document it s is about is always wrong.
TimBL: Larry, yes, a lot of webarch
is only implemented in HTTP. So while it's important to distinguish
generic architecture for HTTP, it's also natural to talk about HTTP
specifically
... I was a little disappointed that MH had to ask; I thought there
was a community consensus that no, don't use conneg for [that]. So
yes, perhaps we need to write it down.
<masinter> conneg definition was carefully hammered out in HTTP-WG, and some assumptions about it seem to be counter to the intent and (I hope) the written spec
TimBL: setting up the tabulator has
been important in working out the practicalities of content
negotiation...
... and for using RDF as a human-readable format
<timbl> 1) Much of web arch is only implemented in HTTP. 2) TAG giving advice is asked for and useful; 3) never use conneg between a document and metadata about that document.
<Zakim> DanC_lap, you wanted to suggest that HTTP is design as an embodyment of webarch and to suggest that the conneg story includes all 3 cases: server side, transparent, and client-side
LMM: I think it's useful to move
beyond what is to belief/intent...
... getting that worked out in HTTP was tricky but worthwhile
... [image/rdf ?] is a big leap that I don't think we should be
making
<DanC_> [darn; forgot to make my point about safety and POST and onload, which is the most important of the N things I q'd for]
AM: so this idea that conneg is only
to be used for "equivalent" representations...
... am I hearing others say we should move away from that?
NM: I think [Martin?] is sympathetic to that position... that distinct URIs should be used, but he finds that when he builds it that way his users aren't happy
<johnk> is the only case where conneg is actually an arch issue in the link between data and metadata?
whiteboard experiment:
[[
* AWWW discusses mainly the simple cases
* When conneg is used, how many resources are there?
* should "web" arch be independent of HTTP where possible?
* AJAX returns a program. conneg needs to be rethought for this?
(pertinent issues: generic resources & web app state)
* role of authoritative metadata & content type
* proposed test: "same information in different form?"
]]
<DanC_> aha... I like that formulation of the test: "same information in different form?"
LMM: there's a section of the HTTP
spec that's being revised... it's non-normative... about what
conneg is for
... I have an action in the HTTP WG to work on that; I'm happy to
get TAG input on that
TimBL: light-weight issue... yes... I'll help Larry
LMM: yes, same from the point of view of the speaker
<ht> LMM: and if you abuse that you'll confuse people
NM: the ajax bullet seems still live... let's take that under web applications tate
<Zakim> ht, you wanted to say "clarify same info in different form" should be done
HT: another point to capture: ... everything that needs to be said about the relationship between relationships in the generic resources finding...
NM: that sounds like the "how many resources" bullet...
<Zakim> DanC_lap, you wanted to suggest re-using generic resource rather than making a new issue
NM: considering: to re-open the generic resources issue re the "how many resources" bullet
issue-53?
<trackbot> ISSUE-53 -- Generic resources -- CLOSED
<trackbot> http://www.w3.org/2001/tag/group/track/issues/53
RESOLUTION: to re-open Generic resources ISSUE-53
LMM opposed, TVR abstains [ I think]
<scribe> ACTION: Larry to draft replacement for "how to use conneg" stuff in HTTP spec [recorded in http://www.w3.org/2009/03/03-tagmem-irc]
<trackbot> Created ACTION-231 - Draft replacement for \"how to use conneg\" stuff in HTTP spec [on Larry Masinter - due 2009-03-10].
<ht> trackbot, status?
<ht> ACTION: ht to Follow-up to Hausenblas once there's a draft of HTTPbis which has advice on conneg [recorded in http://www.w3.org/2009/03/03-tagmem-irc]
<trackbot> Created ACTION-232 - Follow-up to Hausenblas once there's a draft of HTTPbis which has advice on conneg [on Henry S. Thompson - due 2009-03-10].
"Goals:
* Review history, successes, and challenges with respect to TAG's efforts ..."
JK: mixing XML languages with HTML... is that the goal?
<Zakim> ht, you wanted to review the founding statement
HT: "Is the indefinite persistence of 'tag soup' HTML consistent with a sound architecture for the Web?" -- http://www.w3.org/2001/tag/group/track/issues/54
<Zakim> DanC_lap, you wanted to say that space for unstructured discusion helps
DanC: space for unstructured discussion here helps balance social dynamics in the HTML WG
LMM: is this an HTML issue or a
webarch issue?
... is extensibility, versioning, error handling... are these HTML
problems or webarch problems?
<masinter> well, they're all webarch, but are they restricted only to HTML
HT: I noted "Is the indefinite persistence of 'tag soup' HTML consistent with a sound architecture for the Web?"; but note also " If so, what changes, if any, to fundamental Web technologies are necessary to integrate 'tag soup' with SGML-valid HTML and well-formed XML?"
LMM: yes, this is an architectural issue, but is it wider than HTML? [?]
HT: it's wider because it's the thin
end of a long wedge...
... extensibility mechanisms in HTML are likely to be picked up
elsewhere
<Stuart> Larry's "no" above was in response to an aside question "Stuart wonders whether when speaking of HTML Larry is also including XHTML?"
HT: what I heard in the ARIA discussion was "we don't need extensibility because extension happens rarely"; applying that generally is at the very least a general architectural issue
<jar> (noodling on what raman's saying: html = 'shell' for the OS=web ?)
TVR: [missed some] a model was: how
can we make a web where lots of languages can play at the end of
one link?
... in the 1990's, we thought mixed namespaces, DOM, events
bubbling, was the way things would work...
... more recently, others say no, [this other thing] is how it
works
... does this mean we need to re-design SVG, ...
<Zakim> DanC_lap, you wanted to comment on XML and HTML, esp RSS, SVG, RDFa
DanC: on the one hand, HTML is just
one among many content types in web architecture, but on the other
hand the web _is_ HTML to 3 or 4 significant digits...
... and [more... even though larry repeated it...]
<Zakim> timbl, you wanted to suggest creative commons as a nice case in point, whcih suggest that there si no lace where we can draw a clean lin between html and xhtml
TimBL: some say "HTML is its own
thing, not XML"; on the other hand, RDFa is designed in the XHTML
context ...
... then a discussion was sparked by Creative Commons suggesting
use of RDFa in HTML, regardless of whether it's XHML or HTML...
<masinter> is this issue about "namespaces" really?
TimBL: so attempts to keep XHTML and HTML separate have broken down
<Zakim> raman, you wanted to add that we need to remember that like namespace extensibility at its time, tagsoup today is also an experiment. Some would say that the experiment is not
TVR: we've taken the namespace-based
architecture as orthodoxy for a while, but that was an experiment
as much as the tag soup approach...
... for all we know, either could fail in the 4 year
timeframe...
... if you look in the 10 year timeframe, we should acknowledge
that experiments will fail... and we should look for ways that they
can live together [close to that, anyway]
LMM: the name of this issue misled
me...
... I think maybe it's re-considering namespace based
architecture
... a story: somebody came to me a the W3C TPAC and said "we need a
registry; how do we make one?" I tried to make a joke about
"there's this way of doing decentralized naming..." but they didn't
get the joke
... namespaces were introduced as a way of decentralized naming...
they were rejected for perhaps technical/usability reasons...
[scribe lost train of thought here]
... one position is "within this context, we don't need
distribution; we can manage the chaos by getting all the browser
developers in the room/group" ...
<raman> union of namespaces was proposed by people like Tantek multiple times
LMM: we probably need union namespaces
<DanC_> (reminds me of prospero... union links are a great idea; I wonder if they can ever get widely deployed in filesystems. )
<Zakim> ht, you wanted to mention the sniffing draft
issue-24?
<trackbot> ISSUE-24 -- Can a specification include rules for overriding HTTPcontent type parameters? -- OPEN
<trackbot> http://www.w3.org/2001/tag/group/track/issues/24
<masinter> jar: seen something like this before -- Common Lisp package system
http://ietfreport.isoc.org/idref/draft-abarth-mime-sniff/
HT: perhaps we would re-open the authoritative metadata issue for that
DanC: yes, issue-24 was re-opened for that
NM notes it's in an "unscheduled" pile in the agenda
NM: I think decentralized naming
using URIs is architecturally important, but I've never seen a
user-friendly syntax for it...
... looking at Java packages, people can see the use case for
DNS-based naming when they borrow code from elsewhere
... but there are screw cases with bug fixes across domains and
such
<DanC_> (+1 look at both sides)
NM: I think both sides are making important points and we should take both seriously
<Zakim> noah, you wanted to point to lack of agreement on need for extensibility
NM: [something about convenient syntaxes being less self-describing ...]
<masinter> I don't think we can abandon namespaces, but without namespaces, may need registries or some other clear extensibility mechanism
TimBL: something is either
self-describing or it's not...
... I think we can solve the problem with manageable cost for all
the relevant parties
... HTML parsers are already huge; a little more code to handle
namespaces is a negligible cost...
... [an example elsewhere; scribe missed; help?]
... I think yes, it's a goal to get the creative commons feature
working on HTML 5
<masinter> +1
TimBL: by whatever technical or social means necessary
<Zakim> ht2, you wanted to query state of media-typed based NS defaulting
<Zakim> timbl, you wanted to suggest etchnically that html5 adopt ns for new browsers.
<johnk> agree with timbl, masinter that a good concrete goal is to get RDFa working in HTML5
HT: this idea about default
namespaces based on media types has been discussed in "we
should..." mode, though I don't know that anybody's actively
working on it
... I'd like to establish a reward for cleaner markup in _this_
life...
... it was at best naive to expect XHTML would dominate; but we
don't have to give up on the idea that XHTML has real benefit.
TVR: absolutely
HT: I concur with the idea that tim has presented: let's remove the step function in the reward of cleaning up HTML markup. [?]
<johnk> is there a link to that work?
<masinter> not sure "media type based namespace declaration" is the right formulation
<timbl> You can addd xmlns for cc and get the benefit of having cc markup without having to put quotes around attribute values everywhere for example.
LMM: not sure "media type based
namespace declaration" is the right formulation... but perhaps
formulate it in terms of mapping rules between contexts
... i.e. how to interpret one as the other
<Zakim> masinter, you wanted to separate costs to readers, cost to authors
<Zakim> noah, you wanted to discuss wrapup
NM: I made some notes on the board [scribe wishes for a photo in www-archive] but let's not go into those
LMM: let's keeping working toward a
deliverable... finding/note no matter
... esp. on conversion between namespaced and non-namespaced
forms
TVR: I think the TAG has a critical role in bringing 2 sides of the community together
<Zakim> DanC_lap, you wanted to note HTML WG agenda for this week
close ACTION-226
<trackbot> ACTION-226 Report at March on tagSoup progress since TPAC closed
<noah> DC: Chris Wilson has an action HTML WG action to write up distributed extensibility
<masinter> trackbot, action-226?
<trackbot> Sorry, masinter, I don't understand 'trackbot, action-226?'. Please refer to http://www.w3.org/2005/06/tracker/irc for help
<noah> ACTION-226?
<trackbot> ACTION-226 -- Dan Connolly to report at March on tagSoup progress since TPAC -- due 2009-02-24 -- CLOSED
<trackbot> http://www.w3.org/2001/tag/group/track/actions/226
<noah> scribenick: noah
TBL: Henry mentioned talk I gave at
AC meeting suggesting both sides should make some concessions to
come together on this. I can review it.
... It met with some criticism that it's asking too much of both
sides, but my opinion hasn't changed.
<Zakim> johnk, you wanted to ask about timbl's idea of addressing the CC use-case in HTML5
TBL: Henri Sivonen pointed out that current HTML browsers don't actually populate DOM namespace properties.
<masinter> if it is parsed as an HTML document
<Zakim> noah, you wanted to discuss use cases
JK: so, you think discussing the CC use case is important.
TBL: yes
<timbl> Hmmm. yes sorry that is in fact not totally written up ... it has bullet point in it
<DanC_lap> Cleaning up the Web
<DanC_lap> (crud; I marked the essay world-readable, with permission, but I didn't link it from http://www.w3.org/2008/10/TPAC/TPDay-Agenda.html )
<timbl> Those are notes from the talk, but should go with the slides
<DanC_lap> you didn't use slides when you presented it at TPAC 2008
<jar> danc: The namespace skeptics are in the minority in the marketplace.
DC: Dominant browser ships namespace-based extensibility. Similar in spirit to XML namespaces, but not exactly XML.
TBL: Does it use xmlns?
DC: not remembering
<masinter> Chris Wilson from MS will report on this in HTML WG
<DanC_lap> HTML WG ACTION-97
<DanC_lap> Following SVG-in-HTML thread, propose decentralized extensibility strategy for HTML5
HT: What I want us to do is: "produce a document which specifies a mechanism for bridging the gap between namespaced and non-namespaced forms of languages conveying the same things"
<DanC_lap> break for lunch, resuming at 1:15pm
<DanC_lap> scribe: John Kemp
<DanC_lap> scribenick: johnk
HT: introduces issue, noting languishing of this issue
http://www.w3.org/2001/tag/doc/namingSchemes.html
ht: intends that this doc is the one
to be blessed
... origins of this issue were concerns about uri scheme and
namespace proliferation
... OASIS eg. uses URNs for XML namespaces
... thus no straightforward way to dereference
... notes URI scheme examples such as XRI
... wrote a doc to defend the proposition that http: was sufficient
for naming
... concern was that original doc would not actually help those who
needed it most
... there is an opinion that everything relevant to be said is said
already in the relevant RFC already
... Dirk & Nadia attempt to document the story a la AWWW
... example: boss says we want names, Dirk says let's use URNs,
Nadia says new scheme!
... biggest problem is the taxonomy of requirements: e.g. what is
persistence?
... (describes document structure)
... not worked on this doc recently
... but wanted to introduce this to new members and give us a
memory jog
NM: (asks the room what we
think)
... not sure the description reveals the issues
... gives HT the chair for this session
LMM: describes link on problems URIs *won't* solve
<masinter> problems URIs Don't Solve
LMM: people confuse name assignment
with service level agreement about name resolution
... when you buy domain name, you get a service guarantee
... (discusses control and monetization in name assignment)
... biggest piece of puzzle from Dirk & Nadia is issue of
control
biggest piece of puzzle _missing_ is issue of control
LMM: new URI scheme, or URNs may provide more benefit than cost for some
DanC: URI space owned by all, not
"some"
... issue of namespace collision
timbl: (challenges)
LMM: use uuids
... (see XMP uuids)
... they weren't locators
<ht> No-one ever expects the network effect
DanC: http is good for domain + path hierarchy
<DanC_lap> ... but uuids are outside that case
LMM: look at lifecycle of content and its movements
HT: introduction of Dirk & Nadia needs to say that interest is in naming things with a Web context, not other naming
is widget naming "for the Web"?
<jar> danc: anyone smart enough to use large random numbers doesn't need to go to school at our school
DanC: people want to recreate a naming hierarchy, is the issue
HT: previous document set out to sell
HTTP, Dirk & Nadia provides instead a cost/benefit
analysis
... lookup + hierarch will meet most requirements, and HTTP URI
already provides that
... intent of doc is to show you how to sharpen your reqs, and if
you use HTTP URIs, how to meet them
LMM: distinction between a film and
the (actors) in it
... identification problems are different
... identifying media means identifying the content container
... identifying concepts described in the content is different
HT: doc not written to address those problems
JAR: assumes you have your own theory of naming
LMM: no one has a well-defined theory of naming
JAR: there are some theories that work
(in practice)
<Zakim> noah, you wanted to ask if we've documented costs
NM: have we documented or understood
the _costs_
... to what extent do you plan to dig into the costs of
alternatives?
<jar> in reply to Larry who said xxxx is not well-defined: well-defined and adequate are not the same thing
HT: moved costs to 'spare parts' section
<jar> what I mean to say is that the theory of what is named is orthogonal to naming system mechanics. can solve the 2 independently
HT: large analysis of the tradeoffs -
how you get confidence in certain guarantees, by contract or
otherwise
... that level of analysis did not belong in the finding
NM: namespace pollution is only part
of the issue
... ... other reason is association of HTTP URI with
widely-deployed dereference mechanism
... two parts of this story could be told fairly simply
... your decisions affect other people (if you take a name, no-one
else can)
... wide deployment of existing schemes may be useful to you
<Zakim> masinter, you wanted to ask: who needs this finding? What W3C work depends on an answer to this question?
LMM: prioritizing - whose work depends on us answering this?
HT: we were asked by W3C members
NM: will discuss explicit priorities tomorrow
TVR: (echoes LMM)
JAR: (thinks a contribution can be
made here)
... ... particularly when trust is lacking, naming is an issue
HT: D&N does address that somewhat (by noting checksums in URIs)
JAR: we should talk about priorities, issue is important in SemWeb
<masinter> *IF* we could resolve this effectively *THEN* there might be value
TBL: rate of non-HTTP ways has remained steady
LMM: (mentions TDB, DURI schemes in this context)
HT: next decision points comes with a next draft
LMM: [trust, authority, control, monetisation] all go together
NM: one time only (we will not repeat
this in future meetings)
... we had 28 open issues at time of writing agenda
<masinter> ... as motivating factors for why people want new schees
http://www.w3.org/2001/tag/2009/03/03-agenda#issues
NM: believes that some issues are open because we think there is something to be done here, but in practice it is not clear what we should do
<DanC_lap> (not just to remind ourselves that it's open, but as a marker in the community that yes, you're not the only one with this problem)
NM: proposes we close issues which
fall below some mark
... and sort the rest appropriately
... (wants to get others involved in managing the issues
well)
... (profers the issues list at http://www.w3.org/2001/tag/2009/03/03-agenda#issuetable)
... proposal to schedule two sessions with break
... first session, divide into groups
... new TAG members circulate between groups
... (shows tracker)
... (introduces tracker functions)
... nowhere does it say in tracker item where are we?
DanC: (expresses enthusiasm to move forward)
<timbl> http://www.w3.org/2001/tag/group/track/issues/open
<noah> deliverables are we expecting to produce
<noah> http://www.w3.org/2001/tag/group/track/agenda
NM: describes how he creates the
agenda
... some day it would be nice if the summary of agenda input were
more to the point
... shows a template for describing issues
... (describes template)
TVR: we need to figure out the meaning of the criteria
LMM: what other activities depend on the work?
NM: let's take ISSUE-50
... and work a real example
HT: where do you propose to put the info (from the template)
NM: show tracker fields are very
fixed
... put this information in the description field
JAR + LMM: use Notes instead?
NM: 'notes' falls to the bottom when read
TBL: limit each of the things in the template to one line?
LMM: does priority belong in description?
(working ISSUE-50)
NM: priority: 'medium'
(discussion about whether this is right)
TBL: which are the issues that we're doing while Noah is chair?
NM: concurs
... (describes how he will handle issues)
AM: can we add a field?
NM: tables the question
... and all other 'meta' questions
... trying to capture where we are accurately
LMM: what is the priority, and how certain of it are you?
NM: OK to say 'don't know'
DanC: no way to find priority in our (past) records
NM: use your collective consciousness
to work it out
... in many cases, you know
LMM: what do you think the priority
of each issue was?
... vs. what do you think the ongoing priority _should be_?
AM: questions how we do this for very long-running issues
NM: (back to ISSUE-50)
... edits tracker item - http://www.w3.org/2001/tag/group/track/issues/50
<DanC_lap> ("current deliverables: ...namingSchemes" is redundant w.r.t. actions; I suppose that's sorta by design.)
(group discusses communities affected by ISSUE-50)
HT: 'raised by' now means 'principally responsible'
NM: external commitments on
ISSUE-50?
... goal is to do all issues by 16:00
... (proves, by PIE, that not all administrivia is bad)
(group breaks into two to divide issues list)
(no more minutes for now)
<jar> re issue-24: http://lists.w3.org/Archives/Public/www-tag/2002Jun/0116.html
<timbl> http://www.w3.org/TR/WICD/
<DanC_lap> issue-30: http://www.w3.org/2001/tag/issues.html#binaryXML-30
<trackbot> ISSUE-30 Standardize a "binary XML" format? notes added
<DanC_lap> issue-30: http://www.w3.org/TR/exi-best-practices/
<trackbot> ISSUE-30 Standardize a "binary XML" format? notes added
(back to minutes)
NM: summarizes what happened wrt the
tracker issues
... would like to appoint a shepherd for each active issue to help
prepare related agenda items
JAR: could it be done via ACTION assignment?
NM: would propose we do add an action for each one which is not in shape
each one == each issue
LMM: issues not open don't need
shepherds
... some issues should be moved from 'open' to 'raised' (or
'closed')
... ones marked as background don't need shepherds
NM: "au contraire"
... let's go over the issues and decide how to resolve
DanC chairing this session
NM: go till 16:30
... (moves to open issues)
ISSUE-7
http://www.w3.org/2001/tag/group/track/issues/7
HT: HTML WG work on ping attributes is believed to be moribund
DC: (disagrees)
HT: Seems unlikely we need to do
anything about this
... Revive if discussion is raised again in HTML
(discussion over who should shepherd)
LMM: could we close it?
<timbl> NM, 2009-03-03
DC: does anyone volunteer to declare victory?
HT: do we want to give that message?
NM: if we leave it open, I'l monitor this
<timbl> NM, date +"%Y-%m-%d"
LMM: worthwhile to discuss what it
means to close an issue
... communicate to community what it means when we close an
issue
HT: sending any such message in this case would be inflammatory
NM: history about how we use the
'open' designation
... community has expectations based on that designation
... do other TAG members agree with Larry?
LMM: if we close a number of issues
at once we're sending a different message
... not saying anything specific about any particular issue
DC: in this specific issue (ISSUE-7) feel compelled by Henry's argument
TBL: There are issues with 'ping',
and then close it
... see the whenToUseGET finding
... notes other issues (beyond using GET)
NM: Is there consensus over text I'm typing?
(seems not)
DC: Is this proposal to close?
NM: just to agree text for current description?
DC: (asks group for thoughts on decision to close)
HT: (some dissent)
NM: don't want to change the criteria for closing
JK: would abstain
NM: if we believe we should keep an
eye on some issue, we keep it open
... if no obvious reason to come back to the issue, then close
it
... I would rather look over definitions of open and closed over
time
... that is not the goal for this session
TBL: am I allowed to ask about how we use tracker?
DC: polls whether to close ISSUE-7
NM: describes 3 possible actions mostly missed by the scribe
DC: is this text (ISSUE-7 description) what you would like on record as resolution for this issue?
NM: keep it open, is text OK?
(agreement)
ISSUE-16
http://www.w3.org/2001/tag/group/track/issues/16
JAR: kept open in case RFC 3205 was too restrictive
LMM: BCPs not normative
NM: what is the TAG's role
here?
... appoint shepherd
DC: not worth the effort needed to
close it
... mark pending review
http://www.w3.org/2001/tag/group/track/issues/20
come back to ISSUE-20 tomorrow
http://www.w3.org/2001/tag/group/track/issues/24
HT: what does description text mean?
DC: AWWW says something about this
<scribe> ACTION: Larry to report back from IETF/HTML liason meeting in March regarding MIME type override [recorded in http://www.w3.org/2009/03/03-tagmem-irc]
<trackbot> Created ACTION-233 - Report back from IETF/HTML liason meeting in March regarding MIME type override [on Larry Masinter - due 2009-03-11].
DC: connection to tagSoup unclear,
happy to delete from text
... shepherd?
LMM: (nominates himself)
NM: will discuss role of 'shepherd' later
http://www.w3.org/2001/tag/group/track/issues/27
DC: rank high is surprising
HT: open action actively pursued
NM: high rank is related to a big piece of work we will do this year
HT: medium is OK for me
NM: (marks it as medium)
... (adds more context)
LMM: issue is misnamed
DC: proposal?
LMM: "Use of IRIs in W3C Specifications" as new title
NM: do we mean only W3C specs?
TBL: "when should IRIs be used"?
LMM: don't want to talk about IRIs in email e.g.
NM: what have we actually been doing?
<ht> LMM and DC please note http://www.w3.org/TR/leiri/ wrt your ACTION
TBL: everywhere you use URI you should use IRI
(that's what we've been saying)
DC: this is an involved
discussion
... suggest we move on
<timbl> s/verywhere you use URI you should use IRI/We were saying "verywhere you use URI you should use IRI"/
HT: no title proposal has yet attracted support
old title: Should W3C specifications start promoting IRIs?
NM returns as chair
NM: this work is important, even if
unpleasant
... proposes we put the exercise down for now, perhaps return
Thursday
<DanC_lap> (I wonder about a shotgun approach to sheperds...)
NM: designation approach for naming shepherds
DC seems to agree ^
NM: goal is come out with a more
refined view
... any concerns about this?
JAR: if you want to get through the list come up with an offline procedure to follow
NM: will do that and see how it goes
<Zakim> DanC_lap, you wanted to propose to close httpSubstrate-16 and to suggest merging fragmentInXML-28 with abstractComponentRefs-37 and to note 12 May 2004 decision that puts 28 in
AM: fragment in XML brought up by
WSDL group
... this is water under the bridge
<DanC_lap> PROPOSED: to close issue-28 on the grounds that WSDL 2.0 is a REC
NM: will entertain a proposal to close ISSUE-28
LMM: mark pending review
... will look at it
<DanC_lap> (+1 pending review an LMM to look at it)
<DanC_lap> RESOLVED: to close issue-28 on the grounds that WSDL 2.0 is a REC
NM: http://www.w3.org/2001/tag/coordination/TAGGuide.html
... (describes reasons for writing the document)
... are we willing to agree that this describes how we will
work?
... reads text about good scribing practices to help the
chair
... also updated document to note that draft minutes should include
plaintext
LMM: sent feedback that document combines procedural things with TAG "philosophy"
NM: would you like to rewrite
this?
... Will think about your feedback
... intend this to be a hitchhikers' guide to the TAG
LMM: procedural issues may have no
longevity, philosophical ones may have more
... perhaps should be separated for that reason?
... if you're asking whether this is a good starting point, then
agree
NM: (would like to have practices
that he can "enforce")
... do you buy the goal?
... do you have any objections?
JK: what actually though are the long term goals of this document?
(essentially agreeing with Larry about the impression of mixing two separate, perhaps both important but perhaps better separate subjects)
<DanC_lap> (I have a bias against standing items.)
AM: (raises procedural issue I didn't really catch)
TBL: concerned that this doc is not public
NM: I want this doc to be for us, not
for public feedback
... but if we decide that our public commitment is obvious
elsewhere would be OK with this being public
... asks whether he should schedule additional work on this
document or whether it works roughly
(group agrees to work with what is written)
NM: next TAG meeting
scheduling?
... would like to do another f2f meeting around summertime
... any sympathy for Boston area meeting for early June?
HT: have scheduling difficulties generally
NM: proposes 2/3/4 June
16/17/18 June?
27/28/29 May in Boston?
or 17/18/19 June
TVR: Is this just about picking
dates?
... can we do this in email?
two concrete proposals: i) 27-29 May, ii) 17-19 June
23-25 June?
PROPOSED: tentative 23-25th June meeting
RESOLUTION: to check this against the previous proposals
NM: adjourns meeting