See also: IRC log
As above
http://www.w3.org/2001/tag/2005/05/10-agenda.html
Next telcon next week (17 May)
Regrets from Ed Rice, Henry Thompson, Roy Fielding, Vincent Quint, Noah and Tim at risk
RESOLUTION: Meeting cancelled
Date of next telcon 24 May?
<DanC> I'm travelling 24 May for XTech... haven't done the timezone calculations to see if I'm available.
DO is at risk, VQ is travelling
VQ: Should meet, need a chair -- volunteer?
<DanC> (I'm happy for VQ to ask NDW to chair 24 May)
NM: Will chair if NDW is not able to, would prefer NDW, who is more experienced
VQ: Will help with agenda
RESOLUTION: NDW will be asked to chair 24 May telcon, whom failing NM
<DanC> "Memorial Day Last Monday in May Monday, May 30, 2005" -- http://web.mit.edu/hr/empservices/mit_holidays.html
<DanC> DO: regrets 31 May
<DanC> RF: regrets 31 May
<DanC> NM: small risk 31 May
Minutes script fell over
DO: Will try to recover today
Raw minutes are at http://www.w3.org/2005/05/03-tagmem-irc
<scribe> ACTION: VQ to return to approval of these minutes in two weeks [recorded in http://www.w3.org/2005/05/10-tagmem-minutes.html#action01]
VQ: Will prepare a first draft
later this week
... Floor is open for some preliminary suggestions
DC: Acked to discuss 1) RDDL, the
XQuery namespaces, Schema Component Designators and abstractComponentRefs-37/WSDL
... 2) Outline of next doc
NM: Rather than next doc, the
larger question of agenda for the next year
... Goals, planned pubs (vol 2 vs. revised vol 1)
... A large topic, split over several slots might be good,
<DanC> +1 multiple sessions for what's next. (I still prefer working on an outline)
NM: so that OOB discussion can happen and have a place to feed back.
NM, DC: Can do both
<DanC> hmm... another idea: diagrams, formalisms, for extensibility esp
DO: More diagramming might go in a companion to versioning and extensibilyt finding
<noah> I think we want to ask ourselves "what is success for the TAG this year"?
<noah> e.g., is it to make sure the architecture supports the semantic web?
<noah> With that in hand, I think we can do an outline to support the goal
<noah> I have some ideas on goals that I will send in email, probably later this week
HST: Difference between namespace documents and language definitions
<DanC> yes, I expect to need diagrams or formalisms of some sort to get very far on "Difference between namespace documents and language definitions"
DO: More on extensibility and versioning, Noah to contribute?
NM: Yes, I will try to work with DO
<noah> Noah notes: this week not too bad for doing some work. Next week I'm traveling Tues-Fri, including to Schema meeting
VQ: Continuation of previous
discussion -- where are we, what will we say to whom?
... Conclusion of that discussion: update the email-exchanged
docs, and ER has done this
http://lists.w3.org/Archives/Public/www-tag/2005May/0007.html
ER: I tried to capture the discussion
from last week
... Hoping for review and feedback
DC: Hoping to go through point-by-point
VQ: yes, a bit faster than last
time
... 12 points
<DanC> I'd like #2 (and others?) reduced to one sentence? "The Working Group did not provide benchmarks that
<DanC> indicate a high likelihood that a single format will sufficiently alter
<DanC> the mix of properties of text xml to be worth standardization at the
<DanC> W3C. "
DC: This is the conclusion, not a particular point
NM: Needs re-writing
ER: Yes, this isn't polished from-the-TAG version
DC: Would like to reduce 2 to 2(b), as above
VQ: Editorial issue: ER and DO were main contributors, either in position to produce a clean version?
ER: Yes, I can do that, after point-by-point discussion
VQ: Point 1 should be intro or summary
DC: Or neither -- let's wait until the end of the discussion
VQ: Point 2 -- just (b)?
DO: Why can't we have (c) -- seems to me we should be able to contribute input to e.g. the AB on process points
DC: It's in the charter:
<DanC> "The TAG should not consider administrative, process, or organizational policy issues of W3C, which are generally addressed by the W3C Advisory Committee, Advisory Board, and Team." -- http://www.w3.org/2004/10/27-tag-charter
NM: But that's not what DO is
saying -- i.e. not "The Process is broken, you should fix it
..."
... Rather, we are suggesting how the W3C could/should use
the Process at this point
DC: Still not happy with 2(c)
NM: I agree that 2(c) is not
productive, it's retrospective
... What we should do is say something prospective -- what
should happen next
DO: But the arg't about what happens next follows from what didn't happen in the past
VQ: Separated from technical discussion, at any rate
DO: OK, move from here
VQ: OK, we'll come back to this
at the end of the (document,discussion)
... On to point 3
DC: Don't see a crisp statement here, prefer to remove
DO: Finding this point-by-point
traversal difficult, because I can't tell where we're going to
end up
... So maybe I'll be arguing to pull things back at the
end.
VQ: Yes, we go item by item but
can bring stuff back to discuss at the end
... Item 3 out, for the time being
... On to item 4
DC: Isn't this a repeat of the benchmarking point
ER: No, the parser impl question is about opportunities for improving the status quo, instead of a new approach
VQ: DC, ER's point make sense?
HST: DC, what's your goal here, wrt one sentence?
DC: Not necessarily 1 sentence, just need to find concrete propositions I can agree to
DO: Trying to focus on properties of the parser that can be modified
VQ: Back to point 3, aren't you?
ER: The fact they never apparently considered improving the status quo is what's being discussed here
NM: Maybe what's going on here is that the ordering of these points isn't right
<DanC> (that's a quite reasonable tactic... rather than going in ascending order, call for anybody to nominate a point they like)
NM: Downside as well as upside to
a new format, is starting point of TAG response
... So we need to see whether advantages outweigh the
disadvantages
... So we need to see the detailed assessment of the room for
improvement
... and identify a small number of key use cases which are
compelling argued to be the sweet-spot that must be hit
... [scribe fell too far behind]
VQ: OK, we will open up the order and allow to start anywhere -- NM, you want to start with item 7?
NM: Not really, rather adapt this
to start with the 0 or 1 new formats, not 1 or 2 or 3
... Clear disadvantages, as well as potential advantages, to
doing a binary format
... List some of the disadvantages
... So to justify a binary form effort, compelling case has to be made
that the advantages outweight the disadvantages
... The work to date doesn't appear to make that case
... Then move on to individual points
DC: Thought most of this goes w/o saying, or is just the conclusion
VQ: We can't take too long over
this, or the point is lost
... Must comment this month
DO: Suggesting we stop now?
<DanC> (I'm content to make the "lack of benchmarks" point (quoting from webarch) and leave it at that)
VQ: Continue briefly, then decide
what to do next
... What are key points we want to keep?
... Hard for ER to get a document from this discussion
... Around the table
DC: Lack of benchmarks, leave it at that
DO: Provide a framework and some
detail of what the TAG would like to see
... Hence tradeoffs between properties and how to measure
this
... We have to answer the question, "So what would be enough
evidence?"
<DanC> [[ It is important to emphasize that intuition as to such matters as data size and processing speed is not a reliable guide in data format design; quantitative studies are essential to a correct understanding of the trade-offs. ]] -- http://www.w3.org/TR/webarch/#binary
ER: Agree with what's been said, add human readability as a key point
HST: NM's point about taking the
option of improving the performance wrt the existing format
... seriously
NM: Agree with DC, but have to suggest what the goals are for benchmarking -- what's good enough
RF: Anything is good
VQ: Measurements of technologies needed, along with specific targets that have to be reached
<DanC> (hmm... re "optimizing use of the present format hasn't been sufficiently considered" ... not sure what to think of that. I don't object to it.)
VQ: ER, are you prepared to try
to produce something based on today's discussion?
... Have enough information?
ER: I can draft "What the TAG is planning to say", will send it to tag@w3.org
DC: Two reviewers?
NM: I volunteer
DO: ditto
<scribe> ACTION: ER to draft a new version of the proposed reply, NM and DO to review by end of this week [recorded in http://www.w3.org/2005/05/10-tagmem-minutes.html#action02]
NM: Decide by email, or not until 2 weeks?
<DanC> PROPOSED: to resolve binaryXML-30 as discussed today (quantitative goals, benchmarking), contingent on agreement between Ed, Noah, DaveO on text.
VQ: Planning for revised, final, version of the doc't by next week, then email 'vote' to approve
<noah> Fine with me.
<noah> Actually, either Dan's or Roy's approaches are fine with me
DC: If I'm not happy, have to convince one of those three
<Roy> Dan's version is fine by me
VQ: OK, so if you three get to be happy about a doc't, we're done
<DanC> (I gather we are so RESOLVED.)
VQ: No matter what we close in two weeks
PROPOSED: Once ER, DO and NM are agreed on a draft, they submit it to the whole group. Reply in the negative within 3 days, or we will send the doc't to the XBC list.
<DanC> second
<noah> third
<Ed> fourth
RESOLUTION: Once ER, DO and NM are agreed on a draft, they submit it to the whole group. Reply in the negative within 3 days, or we will send the doc't to the XBC list.
HST: I don't think there's an issue here -- how we say it politely is another problem
RF: No architectural issue here
<Zakim> DanC, you wanted to say no and to suggest a straw poll
DC: No issue, no reply
VQ: Consensus to reject
... Reply?
DC: It's on the agenda so we have to
VQ: Could just say "We don't consider this an architectural issue" and that's it
<scribe> ACTION: VQ to send a short reply to ERH saying "no" [recorded in http://www.w3.org/2005/05/10-tagmem-minutes.html#action03]
VQ: DC started this thread,
http://lists.w3.org/Archives/Member/tag/2005Apr/0097.html
... ... but ended by saying we should do nothing about this
DC: I was more worried when I
thought this was a big threat, now I don't
... Minimal resolution is to say "Use URIs"
HST: We said that already
DC: No, we said "don't use a new scheme"
DO: And they said, we're not using URIs so we can ignore you
NM: They seem to be arguing that it's not a URI because we're not going to use it in any URI contexts
<DanC> (well, they were quite polite and didn't say "so we can ignore you" in so many words)
NM: but you should want to use them on the Web, so you should want them to be URIs
DC: So why aren't IRIs broken?
NM: We've gone to great lengths to make that work as best it can
DC: Devil's advocate then says "We're just doing the same thing with XRIs"
ER: But we showed that they could use existing scheme, a fortiori with URIs
HST: I'm not happy -- it's not good citizenship to do something that confusing
DC: I'm happy with any reply which cites:
<DanC> http://www.w3.org/TR/webarch/#pr-use-uris
HST: I'll do a single para
<scribe> ACTION: HST to draft a para and circulate, send if no reply after 48 hours [recorded in http://www.w3.org/2005/05/10-tagmem-minutes.html#action04]
DC: Nothing in the public record you can cite as what you're responding to
HST: Can you forward it to public list?
DC: Please you do so, with the copy I sent to tag@
<DanC> http://lists.w3.org/Archives/Member/tag/2005Apr/0097.html
HST: Will do
<DanC> (I got his permission to forward to public fora)
HST: That's sufficient
HST: I'll look at this (RFC3023bis wrt fragmentInXML-28) in the coming week
VQ: NM, what about schemeProtocols-49?
NM: Will work on that this week
VQ: DC, what about standardizedFieldValues-51 ?
DC: No progress yet, but will do it
VQ: I would like to add this to
the issues list, but will wait for DC to post to www-tag
... Adjourned, until 24 May