See also: IRC log
<timbl__> fjhsdkjfhsjkdhfkjq
<Chris> Scribe: Chris
Stuart: Scribe for this afternoon please?
TBL: Me
<paulc> http://www.w3.org/2004/09/27-tag-summary.html is bad
Minutes of telcon 27 Sept http://lists.w3.org/Archives/Public/www-tag/2004Sep/att-0170/minutes.html
minor joshing re URI opacity and location of those minutes
<DanC_> 27 minutes, ammended to show regrets from RF, is fine to me. http://lists.w3.org/Archives/Public/www-tag/2004Sep/att-0170/minutes.html
Minutes accepted
Stuart: Next meeting 18 Oct
<timbl__> TimBL abstains
Paul: 22 Nov, week before f2f, meeting? Also US thanksgiving
Stuart: I have a conflict
Noah: So do I
Paul: Potentially so do I
<Stuart> I will have to give regrets for 15th and 22nd Nov
Stuart: So, we need a chair for the 15th and 22nd
Chris: So are we having a telcon on 6 Dec?
Norm: Happy to chair those two
<DanC_> . http://www.w3.org/2004/07/19-tagmem-irc
<DanC_> ah... aug ftf http://www.w3.org/2004/08/09-tagmem-irc http://www.w3.org/2004/08/10-tagmem-irc http://www.w3.org/2004/08/11-tagmem-irc
Minutes from yesterday
http://lists.w3.org/Archives/Public/www-tag/2004Oct/att-0006/tagtest.html
<scribe> ACTION: Chris collect IRC logs from last f2f and turn into minutes
http://lists.w3.org/Archives/Public/www-tag/2004Oct/att-0006/tagtest.html
<DanC_> # pointers for assembling meeting minutes Dan Connolly (Wednesday, 11 August) http://lists.w3.org/Archives/Member/tag/2004Aug/0026.html
Stuart: TAG welcomes
Noah again
... Mail from Ian, we no longer have Ian available
Tim: We should use WBS
more eg for meeting surveys
... Issues and actions tracking - how to do; better to have a
system like WBS that all groups can use
Norm: OK but we need a body to do that meanwhile
<DanC_> (issue tracking is all-the-worlds-problems-complete, in my experience)
Paul: Ian set a high
bar with our home page and issues list
... this issues list was immensely valuable
<DanC_> CL: the "Topic:" convention results in automated minutes tables-of-contents
Chris: small amount of effort to use topic separators in IRC pays off witjh minuteswhose sections can be linked to
<timbl__> I agree that the richness of linking in the minutes, and precision of linking for example into the minutes, has been very useful.
Paul: We may need a staff contact. Norm has dona a valiant job with editing, but the staff contact areas need to be done
<DanC_> (I'm all for a small investment in meeting records and automating various ways of consuming them. cf http://esw.w3.org/topic/MeetingRecords)
<timbl__> DanC: The home page used to always point to the next meeting, now I have reduced those expectations.
Noah: smal lamount of effort here really pays off
Roy: what tools to systeam use?
Chris: Exit is one system, not maintained
Dan: generally PHP and XSLT are okay
<timbl__> The EXIT system ran on desktop
Norm: Exit was difficult to deal with, web based forms tend to suck
<DanC_> (a little bit of automation around the email archive: http://www.w3.org/2001/tag/2004lc/lc-status-report.html )
Roy: tools tend to split the load because everyone contributes
Paul: by what date should the Team report back on how we are going to proceed, any other resources available
<scribe> ACTION: Tim to investingate possible staff contact for TAG
<scribe> ACTION: Tim to investingate possible staff contact for TAG, due date 20 October 2004
<scribe> ACTION: Tim to investingate possible staff contact for TAG, due date 20 October 2004
<DanC_> (actually, the good news is we _don't_ have hundreds of webarch LC2 comments ;-)
Stuart: for Patent Policy purposes, TAG members are treated as Invited Experts
(discussion on patent disclosure and licensing requirements)
Paul: we need to see
the charter well before the elections come around; it likely wil
laffect whether people choose to run
... The director has at least one appointment to make, and if an
appointee was from a W3C member they would need to know even
earlier
<scribe> ACTION: Stuart get a timescale from ian about charter revision and availability
Paul: Glad the Team has been responsive to TAG discussions and input here
Stuart: Yes +1
Dan makes play for scenic Kansas City, "The City of Fountains"
<DanC_> (were dates in Feb/Mar given by Stuart?)
TimBL: not available right after AC meeting
Norm: ifff I run and get elected then OK to host in Western Mass..
Stuart: week before AC? June 6-7
Paul: works for me
<DanC_> (are we skipping planning a Feb/Mar meeting?)
Noah: For TP Feb 28 or Mar 1, the proposal was a half day TAG meeting and the rest of the time meetings with other groups
TP calendar is not out yet, but our preference is earlier in the week
Dan: Mon/Tues is sufficiently constrained for now
<DanC_> PROPOSED: to meet 28Feb and 1Mar 2005 in Cannes, France
Tim: so this is mainly liaisons......
Paul: If we have a Proposed Rec we will be collecting input on WebArch Volume Two
Stuart: From last TP, TAG participation was welcomed
<DanC_> PROPOSED: to meet 1/2 day on 28Feb 2005 in Cannes, France, and for TAG members to participate on a best-effort basis in liaison meetings thruought the week
Paul: assume new TAG members would be introduced by telcon
<DanC_> PROPOSED: to meet 1/2 day on 28Feb 2005 in Boston, MA, USA, and for TAG members to participate on a best-effort basis in liaison meetings thruought the week
+1 to that (Boston) proposal
assorted +1s
Resolved: to meet 1/2 day on 28Feb 2005 in Boston, MA, USA, and for TAG members to participate on a best-effort basis in liaison meetings thruought the week
<DanC_> timbl: I have a possible conflict with the 2nd half of that week
<DanC_> SKW: 1, 2, 3 June.... [where?]
<DanC_> timbl no avail 8, 9, 10 June
8-10 June was not availab;e
Paul: avoid the new member briefing
<DanC_> the AC meeting is in Cannes, France in June
<DanC_> looking at co-locating there
Roy: half the group is unknown, so why discuss this now?
<DanC_> which days are you offering to host, Chris?
iff still on TAG I would be ok with hosting to be close to TP in Cannes
<DanC_> close to TP? you mean close to AC, no?
Uh yes
<DanC_> which days?
whenever people are available
not 8-10
<DanC_> see my earlier comment: I like to start with a specific offer from the host.
<DanC_> would you please offer specific days?
I propose Weds 1 to Fri 3 June
Noah modulo some flexibility as to Tims availability, sounds ok
Dan: cannt commit to onsite but can attend remotely
Tim: propose 8-10 and I will join remotely
Noah: if it turns out that not enough are at AC, why colocate?
Norm: we have to report to AC anyway
2 prefer after, one prefer before AC
3 prefer after *8-10), one prefer before AC
Resolved: 8-10 June, South of France near Cannes host ERCIM
<DanC_> I can only confirm for remote attendance
Stuart calls for a Kansas City proposal
in September
Noah prefers not week of 5th
Dan 13-15 Sept Kansas City
Paul: conflict
Noah: prefer not then, no actual conflict
Dan: propose 20-22
September
... propose 20-22 September Kansas City
... has done preliminary investigation of location
... Airport is MCI, Kansas City International
Resolved: 20-22 September, Kansas City, hosted by Dan
Paul: volunteer to do
next monthly report
... AC report is cumulative of the previous three reports
... get this to Steve Bratt by Oct 22
Dan: Last time there was little contribution from AC - not a hot topic apparently
Tim: Status report in the sense of are we doing OK, rather than the technical issues
Paul: in general agree; decline offer to do a panel at AC
<noah> For the record, quick search of American airlines suggests that return options from Kansas City to Boston are (Lv: 3:04P Ar: 8:42P) or (Lv: 5:13P Ar: 10:30P)...those are for March dates, Sept. 2005 is not posted yet.
<DanC_> tx, noah; so ending the meeting at noon on Thursday would let BOS-based folks get back for bed-time
<scribe> ACTION: Paul to create new monthly summary
<noah> Easily. Depending how much lead time one needs at MCI, I could see going into early afternoon. Tim and Norm's mileage may vary.
<scribe> ACTION: Paul create draft summary for AC
<break dur="15min"/>
Stuart: How much time to allocate to this
Dan: I offer to chair to next break
<scribe> Chair: Dan
Dan: So we want a proposed Rec document that answers the remaining open issues
http://www.w3.org/2001/tag/2004/10/05-07-tag
<timbl__> http://www.w3.org/2001/tag/2004lc/lc-status-report.html
<DanC_> current text: http://www.w3.org/2001/tag/2004/webarch-20040816/#information-resource
Dan constructs straww poll with three options
1) is current text, does not satisfy Stickler
2) is text on Web Resource
3) is Sandros text
Noah asks if this closes HTTPRange-14
Dan says probably not
http://lists.w3.org/Archives/Public/public-webarch-comments/2004JulSep/0086.html
"The term Web Resource is applicable to resources for which web
acesssible representations are available and/or which may be interacted
with through an exchange of representations."
Sandros text
http://lists.w3.org/Archives/Public/public-webarch-comments/2004JulSep/0057.html
Dan: fourth option: there are two sides, both have problems
<DanC_> http://esw.w3.org/topic/HashSlashDuality
These would replace current section 3.1
<Roy> Summary of (2) is in http://lists.w3.org/Archives/Public/public-webarch-comments/2004JulSep/0063.html
Paul prefers option 4
Chris prefers 2 and can live with 4
TBL prefers 1, Noah sort of
three prefer option 2
RF CL SKW
Three TBL, Noah
Four: NW, PC, CL, SKW, TBL
Objections to 1) CL PC
Roy: its what comes *after* these paras that people object to
Objections to 2: Tim, Noah
Objections to 3: NW, CL, RF
Objections to 4: None
Roy: The objectionable text is this:
the limitation of what is an information resource
Stuart: Tim seems tonot want information resource to involve having a representation
Noah: The more text we delete the more hangs on the exact meaning of 'convey'
Tim: a poem conveys information
Noah: ok so convey is underqualified
TimBL: I disagree with
Patick Sticklers view
... I move that we don't accept his comment
Tim: I absolutely reject removing Information resource from this document
Stuart: Its merely a relabelling
Dan: But the inferences drawn from the term differs
Noah: distinction between thing is browsable or not; but Web is wider and has things that are not browsable
A Web Service might not be an information resource
Stuart: OK changing the term sometimes matters
Chris: We can define Web Resource now and that does not prohibit later disuccuon of whether something has information or not
Tim: Information
resource predates the Web and is independent of the Web
... Don't tie Info Resource to the Web
Dan: pick only one this time
Norm: 4
Paul: 4
Chris: 4
Tim: 1
Stuart: 4
Noah: 1
Roy: none of them
... prefer to strike the term Information Resource entirely
... don't distinguish between "Information Resource' and
'Resource'
Option 5 added: do as roy says, remove 3.1, change all info resource to resource
Roy: Patrick disliked that we added Info Resource but didnt really talk about it
Stuart: Looking at Pats
comments, he says 'does anything apply to non Information
resources'
... So Pat Hayes argues that there is no distinction between
resource and info resource
"How could a non represented resource do anything on the web"?
<timbl__> Thos are nmot the same comment BTW
Stuart: throughout Pat Hayes comments he says things to the effect of "glad we talk about a weather report, not the weather, nbut can the weather itself be a resource?"
Chris: A resource thsat offers no representation but can be interacted with (representations sent to it) is clearly on the web according to option 2 but has no representations itself
Norm: 200 Ok response
does not define an info resource
... Can't tell an info resource from not an info resource
Tim: Important thing is to be able to work by reference instead of exchanging representations
soo i can talk about a table by URI instead of physically taking the table to you
Tim: its not that when i dereference I get something about the table, its that I always get a picture of the table
Norm: You added some additional context, like a message in which a URI was embedded
How is a message "i like this table <uri>" and "I like the bible<uri>" different; if table is a noninfo resource and bible is an inforesource
Norm: How is a message "i like this table <uri>" and "I like the bible<uri>" different; if table is a noninfo resource and bible is an inforesource
Noah: and why would the weight of the table be odd but the weight of the bible not odd
Norm: so far, no differences between inforesource or not
Chris hears no differences yet between the two classes
Stuart: I note Tim
shifted things to a picture of the table, rather than an abstract
table
... similarly the abstract bible and particular translations or
editions were not clearly distinguished
... Tim, is the particular bible in my house an info resource
Tim: No
Noah: Claude Shannon (?sp) invented information theory
http://www.comp.nus.edu.sg/~yuenck/ccst01/notes17
Claud Shannon's mathematical theory of information was a major breakthrough
in communication engineering: it allows system designers to estimate the
capacity of communication channels and the requirements of information sources,
and also has some application in data storage (since storing away information
and getting it back is rather similar to sending and receiving information)
and possibly psychology. Relation with other subjects has also been suggested
though so far not much imortant impact has occurred.
Tim: I am using info resource the same way as claude shannon
Roy: people use commonly understood terms and human ambiguity resolving mechanisms
if someone likes the design of the table, people work out the differences
Chris: ambiguities would be resolved by further interactions and progressive refinement of those ambiguities that were relevant
Roy: same in Semantic
Web, further assertions clarify
... We have to distinguish between tables and pictures of
tables
Norm: i never said a picture of a table
Dan: One difference occured to me, if you can get hold of the resource itself for commercial purposes
can the resource be duplicated, or consumed, bu looking at it
so therefore a movie, donloaded anfd not paid for is an info resource while the table is not
because looking at the table did not consume it
Roy: all the responses
to Sandros text tora apart the second and third paras, such as is
the number one an info resource or not
... info resource is self contradictiory with URI opacity
Tim: i disagree
Norm: if I give you a URI, is it an info resource or not
Tim: Depends, show me the URI
Dan: You just made Roys point
Tim: but this is licensed by the HTTP spec
Roy: No it isn't
Dan: (another round of
which is preferred, and who objects to each one)
... W3C process now onliges me to pursue 4 as it has no articulated
onjections
Noah: We have said that some combination of existing texts might be preferable
Tim: I prefer one side of thw hash/slash debate
Paul: And others have the opposite view, hence the preference for option 4
Norm: if asked to will incorporate that into the WebArch, tonight
Chris: Prefer to have the testable option 2 but not make it exclusive. if its interactable with then its a wenb resource, if its not interactable then *you don't know*
Tim: We already have that
Noah: So you want web resource not Infor rsource throughout
Chris: Yes
Paul: I could agree with Chris's definition
Norm: distinction with being consumed or not might be persuasive
Stuart: replace info resource with foobar could be okay depends on which sentences are definitive and which are informative
Chris (point about Heisenberg uncertainty principle, spin, observing, and thus an electron is an info resource - lets not go there)
Noah: what makes
something an info resource is its fundamental essence is to convey
information
... convey and carry involves motion or interaction
... table is not fundamentally information
<noah> Close, but would prefer not to use the word "convey", which I find a bit (pun intended) problematic
Norm: (info resource = intellectual property .. no? ok nevermind)
<noah> I'm happy to suggest that the editor chew on the log of this discussion and propose something specific.
<DanC_> (information theory and web architecture has been on my SomedayPile forever.)
Language, Truth and Redundancy
http://members.cox.net/xocxoc/philosophy/redundancy.htm
"Still, even if we return philosophy back to the land of ideas where it belongs, we must still have a means of communicating so that ideas can be transmitted and understood. The answer is redundancy. It is the means by which any form of communication can reduce any inherent noise."
"This redundancy idea comes from mathematician Claud Shannon. His "Information Theory" states that all forms of communication is subject to noise. This noise problem ultimately reduces the amount of information that the medium can carry successfully. Redundancy in the message can dramatically increase its chances of successful transmission.
Philosophers should follow this example. Since language is just a form of communication, we should try repeating what we are saying in different ways. Use illustrations, parables, analogies, explain your entire belief system if you have to, to avoid being misunderstood. Language is an art form, not a wall to hang the picture on. Use it."
<noah> Noah suggests out of order: what makes Tim's definition of information resource interesting is that those are the resources for which ALL the interesting characteristics can in principle be conveyed through a computer communication protocol. For a physical resource such as a table it's only SOME.
<scribe> Chair: Tim
Chris: redundancy helps succesful conveyance of information accurately. Hence the need for surrounding context when using a URI to transfer information
Lunch!!
<Roy> I expect the semantic web to do the same -- the technology must do what the humans do -- changing the humans is not an option.
<timbl__> ____________________________________________________
<timbl__> scribe: timbl__
CONVENES
[Chris missing at the moment]
<Stuart> http://lists.w3.org/Archives/Public/public-webarch-comments/2004JulSep/0082.html
<DanC_> dbooth's script http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribe.perl
[http://thesaurus.reference.com/search?q=representation -- Could we split tim:representation and roy:representation into two words]
SW: We had an inconclusive discsion with teh QA working gorup.
NW: We pushed something off until a time when we were discussing the webach coments.
PC: We say that you should provide an extensability mechanism. The QA comments suggest that extensiion is always hrmful and therefore the advanatges and disadvantages are considered before extensability is introduced in a design.
NW: I understand and maybe even agree with QAWG. But we don't always enumerate *all* the things one has tto think about. And I don't want to delete this.
PC: We should look at
the findding.
... I think we will find that extensability as a ay of doing
versioning.
<Stuart> http://www.w3.org/2001/tag/doc/versioning-20031003
PC: The actual issue
is: what are the best practices for versioning in XML?
... The finding deos not admit to the fact that ou might *not* want
extenmsibility.
... The solution for some systems may be no extensibility at
all.
NW: I added text at the start of 4.2 to admit that possibility.
<DanC_> editors' draft http://www.w3.org/2001/tag/webarch/
<Norm> http://www.w3.org/2001/tag/2004/webarch-20040816/
<noah> http://www.w3.org/2001/tag/2004/webarch-20040928/Overview.html#information-resource
<noah> http://www.w3.org/2001/tag/2004/webarch-20040928/Overview.html
<Stuart> http://www.w3.org/2001/tag/webarch/
Note: The 20040816 link above was WRONG.
<DanC_> editor's draft snapshot 28 Sep http://www.w3.org/2001/tag/2004/webarch-20040928/Overview.html
20040928 link is what we are discussing.
<DanC_> esp 4.2 http://www.w3.org/2001/tag/2004/webarch-20040928/Overview.html#ext-version
<DanC_> dom's reply http://lists.w3.org/Archives/Public/public-webarch-comments/2004OctDec/0002.html
<DanC_> "I'll pass it to the QA WG; I expect that you should hear a reply from us
<DanC_> by Monday EOB." -- Dom, 5Oct
DC: FTI, Dom sent this
comment before the QAWG did, and Chris followed up with Dom to ask
about the new 0928 text, and Dom replied (oct/5) that he would ask
the QAWG and we would have their answer by next Monday 10/11.
... I quite lik ethe current text
<DanC_> ... aside from the "should have extensiblity" box
<DanC_> ... though I can live with it
SW: How about only making this apply to "extensible languages" ? (minor outcry)
NM: In XML, some of the
gain in XML over SGML, some of the gainwas in locking down
over-extensability in SGML.
... There is a cost-benefit tradeoff.
<Stuart> No... suggest "An extensible specification SHOULD provide mechanisms that allow *any party* to create extensions"
<DanC_> a couple minutes ago I asked noah if he had alternative text and he said he'd prefer no box
TimBL: There *is* a tradeoff but the common mistake is for a working group to not allow for an extension, like the RDF working group disallowing extensions for new parseTypes.
PC: Looking at the original QA comments:
(reads fro http://lists.w3.org/Archives/Public/public-webarch-comments/2004JulSep/0082.html the asterisked comments in particular)
PC: Which comments, Dan, overlap with Dom's comments?
DC: The second one [starting * the QA WG would like to see the current wording of the first good
practice on extensibility (section 4.2.3) changed; i"]
<Zakim> DanC_, you wanted to correct timbl's skewed version of the RDF Core WG's deliberations on extensiblity and to "Other values of parseType are reserved for future specification by
<DanC_> "Other values of parseType are reserved for future specification by RDF. With RDF 1.0 other values must be treated as identical to 'Literal'."
DC: Tim, you misrepresented what the RDF WG did.
<noah> scribe: noah
<timbl__> Tim: How then woudl you like what I saif to be rephrased to make it correct:
Norm says that QA had problem with our definition of extensibility
<timbl__> DC: It was just incorrect.
<timbl__> [scrtibe was not able to determine the sense of DC's comment]
<timbl__> scribe: NM
<scribenoah> Norm reports he offered new wording. This is the new wording QA says that they'll comment on by Monday.
<scribenoah> Specifically, the updated text is at: http://www.w3.org/2001/tag/webarch/#language-extensibility
<scribenoah> The next point in their message is with respect to 4.2.3 http://www.w3.org/2001/tag/webarch/#language-extensibility
<scribenoah> Norm reports he has changed the good practice note to read: "Extensibility mechanisms MUST NOT interfere with conformance to the original specification." Does this help?
<scribenoah> RF: NO! By definition, the term 'extensibility mechanism' implies conformance to original spec.
<scribenoah> RF: I.e. it's part of the original spec.
<scribenoah> Note, QA had commented on the draft at "http://www.w3.org/2001/tag/2004/webarch-20040816/#extensibility" which said "A specification SHOULD provide mechanisms that allow any party to create extensions that do not interfere with conformance to the original specification.
<scribenoah> "
<scribenoah> NW: XSLT allows you to create arbitrary extensions using xslt:extension, and lays out conformance rules for use of that.
<scribenoah> RF: Right, but it's impossible to design a conformance mechanism that doesn't have that characteristic.
<scribenoah> NW: Right, my statement is true but vacuous.
<scribenoah> CL: But makes everyone feel like.
<scribenoah> NM: you're, uh, serious about putting a big box around a vacuous statement.
<scribenoah> Various. Um...yeah?
<scribenoah> s /around a vacuous statement/around a vacuous statement?/
<scribenoah> SW: Have we addressed QA comment number 1?
<scribenoah> NW: Yes, I think my new introductory remarks in 4.2. These are the ones on which we should get comments on Monday.
<scribenoah> SW: Lost...
<scribenoah> NW: QA did two things: a) submit comments b) participate in telcon at which they had general concerns about our optimism about extensibility.
<scribenoah> NW: In relation to (b) I (Norm) made an editorial change to section 4.2 (NOT 5.2!) that addressed the general concern expressed on the call.
<scribenoah> NW: Reiterate, by contrast, changes in 5.2 I believe address their email point 1
<Norm> Retract my subst
<scribenoah> scribe: norm
QA submited comments and participated in a telcon
<timbl__> scribe: TimBL
At the telcon, they expressed general unease about our positive statements regarding extensibility. I believe I addressed those concerns by adding new introductory text "A perfect world..." to section 4.2
<timbl__> http://lists.w3.org/Archives/Public/public-webarch-comments/2004JulSep/0082.html The QA WG message
With respect to their individual comments in http://lists.w3.org/Archives/Public/public-webarch-comments/2004JulSep/0082.html
<Chris> http://www.w3.org/2001/tag/2004/webarch-20040928/Overview.html#ext-version
I made a change to 5.2 to address the first comment in that message
<Chris> http://www.w3.org/2001/tag/2004/webarch-20040816/#ext-version
<timbl__> is the previous version
<timbl__> CL: I thought that the change they wanted was the opposite of this change (re conformance) change betwen the 8/16 and 9/28 versions
<timbl__> CL: So I am puzzled.
<timbl__> NW: They didn't like the "should" in "should include ... third party ...extensability"
<timbl__> NW: I though I addressed that
<timbl__> NW: Roy you said the text I wrote was vaccuous
<timbl__> RF: I preferred the previous text.
<timbl__> RF: It talks about what designers should do.
<timbl__> NM: I prefer the previous text .. but without the box
<timbl__> CL: The old text is still there.
<DanC_> SKW projects LC draft and 28Sep editor's draft simultaneously
<timbl__> NW: SKW, do you agree that the changes I made were editorial?
<Chris> Noah: However, languages which have no extensibility mechanisms will be extended in ad hoc ways that impact interoperability as well. is untrue
<Chris> change will be rto may be
<timbl__> NM: I am not happy with the current box [in 9/28] "Good Practice:... a spec should"
<timbl__> PROPOSAL from NM: Delete the goodpractice note
<DanC_> 2nd
<timbl__> Seconded by DanC
<timbl__> CL: If we delete first box and leave eth second one, we will
<timbl__> [disintegrates, not carried]
<DanC_> (the question wasn't put)
<DanC_> (yet; I still hope it will be)
<timbl__> [Discussion of Norm's text]
<timbl__> NW: Seems that we agree that designers should think about this problem.
<Chris> it didn't 'disintegrate'; i pointed out a problem with deleting the first box and not the second. Noah agreed
<Chris> perhaps a revised question will be put
<timbl__> Sorry, by "disintegrate" I meant that amended proposasl were suggested to the point that the proposal structure deterieoated into a general discussion.
<Chris> agreed, no problem
<timbl__> DC: I think the best way to say "think about this' is not to give them a bumper sticker.
<timbl__> PC: What effect does this have on the draft finding?
<DanC_> (yes, whether to bumper sticker or not is tricky)
<DanC_> (and I can live with it either way)
<timbl__> DC: There is a big long finding - a short finding might be nice. this very interesting stuff and worthy of study.
<timbl__> DC: If we have an impact on the finding it is OK by me.
<timbl__> PC: I would lik ethere something to say that you shoul dconsider the costa and benefos of textensibility, with a pointer to the finding/
<timbl__> Norm: Would another para of exaplantion which said more bluntly that there are traeoffs here help?
<timbl__> Norm and TimBL support NW
<Chris> Chris supports NW too
<timbl__> PROPOSED: another para of exaplantion which said more bluntly that there are traeoffs here should be added, editor salting to taste.
and leave the boxes
<Chris> Chris: deleting the top box and leaving the second box gives a bias in the other direction
PROPOSED: Add another para of exaplantion which said more bluntly that there are traeoffs here should be added, editor salting to taste and leave the boxes
<timbl__> staw poll: CL, PC, NW, NM, TBL in favour, SW objects
<timbl__> SW: I am uncomfortable sayingion teh one hand sying consider treh tradeoff and ethn giving a strong bias.
<timbl__> PROPOSAL: Take the 9/28 text and drop the first two boxes
<Zakim> DanC_, you wanted to conduct a couple straw polls and to straw poll on dropping the box
<timbl__> ack timb l
<Zakim> timbl__, you wanted to point out that the actual details of this tradeoff are very application-dependent.
<DanC_> PaulC: I'd object to dropping the box; I don' think it satisfies the QA WG comment, and it undoes an earlier decision to summarize the finding
<DanC_> RF: I don't mind not satisfying the QA WG
<DanC_> DanC: I'd like to get a decision today, somehow. I'd like enough people to abstain in the interest of consensus/progress
<DanC_> (or for the chair to put the question over objections, though I didn't say that to the meeting)
<Stuart> PROPOSED: Add another para of exaplantion which said more bluntly that there are traeoffs here should be added, editor salting to taste and leave the boxes
<timbl__> TimBL: I think that the "SHOULD" in the first box allows prople to have a good reason ffo doing otherwise, and I'd like the poriginal proposal then to pass.
<timbl__> In favor: TBL, CL, NW, PC
<timbl__> Abstain: SKW, RF, DC, NM
<DanC_> so RESOLVEd
<timbl__> ___
<timbl__> SKW: Returning to the asterisked points ...
<timbl__> PC: The third one:
<Chris> dbooths otherwise excellent script does not know how to look for resolutions
<timbl__> PC: They suggest "The QA WG would rather see this either removed, or softened (Ã la "the
<DanC_> +1 add "well-designed" in [the right place]
<timbl__> long term benefits of a well-designed extensibility mechanism..."), but
<timbl__> PC: They suggest "The QA WG would rather see this either removed, or softened (Ã la "the
<timbl__> at the very least explained."
<timbl__> long term benefits of a well-designed extensibility mechanism..."), but
<timbl__> at the very least explained."
<timbl__> PROPOSED: Make that change "the long term benefits of a well-designed extensibility mechanism...."
<timbl__> SKW: objections?
<timbl__> SKW: RESOLVED
<Stuart> http://www.w3.org/TR/2004/WD-qaframe-spec-20040830/#extensions
<timbl__> NW: The editor has already added some and will add more refeernces to the QA work to address their concerns
<timbl__> PC: Can we refer to a draft finding in eth webarch?
<timbl__> NW: Yes. We don't have "Normative references"
<timbl__> SKW: Please refer to a precise document
<timbl__> NW: I usually refer to a "latest version" link
<DanC_> ref to undated, netural "see also" text
<timbl__> PC: Can we do undates thing for this as a "see also"?
<timbl__> CONSENSUS.
<DanC_> ACTION: Norm add "for more info, see also" link to http://www.w3.org/TR/2004/WD-qaframe-spec-20040830/#extensions to 4.x
For the record, David is doing all the heavy lifting on the revised finding.
<timbl__> PC: Could the QAWG please review the draft finding? This is a respond to their last point
<DanC_> ACTION PaulC: solicit QA WG review of draft extensibility/versioning finding
<timbl__> ACTION PC: Nag the QAWG until they review the finding.
<timbl__> ACTION DC: Report back to QA on our disposition of their comments.
<timbl__> ____________________________
<timbl__> SKW returns to the last call status list
<timbl__> VREAK
<timbl__> BREAK
<timbl__> .-2s/V/B
<DanC_> Dan's action is re http://www.w3.org/mid/1095351501.2955.11.camel@stratustier
<timbl__> 10 minutes till 15:40 CET
<DanC_> break until 3:40
<roy_scribe> scribe: roy_scribe
resuming at (12)
<Stuart> http://lists.w3.org/Archives/Public/public-webarch-comments/2004JulSep/0092.html
DC: responded to
commenter, no reply received yet
... further clarification is not expected
(13)
<Stuart> http://lists.w3.org/Archives/Public/public-webarch-comments/2004JulSep/0090.html
DC: there have been
other late comments on this section
... (draws diagram) primary and secondary is a relationship between
two resources, not a typing of the resources
... It doesn't tell you that they are disjoint sets
<DanC_> Late last-call comment on AWWW Graham Klyne (Tuesday, 5 October) http://lists.w3.org/Archives/Public/public-webarch-comments/2004OctDec/0003.html
TBL: Can we think of a better word than "secondary"?
RF: we tried before and could not
SW: How do we respond to Jacek?
TBL: The first bit might be to say that we are talking about two different URIs
SW: certain irony in that -- we went through the process of this in rfc2396bis and came up with the term secondary resource in order to resolve this (i.e., give it a name so that we could explain what happens)
DC: willing to explore
more of this, or simply respond to the question
... his question is coherent and can be answered
TBL: may be related to issue httpRange-14
DC: Jacek suggests at end that real-world objects be considered secondary resources
NW: suggest that we already have a clear way of describing these things: URI with fragment and URI without fragment
RF: that train has left the station
NW: (ed hat on) hears that section 2.6 is less clear than it could be and he is willing to noodle on how to clarify
DC: unclear that there is a way to clarify it
<timbl__> TBL: He suggests by "Worldly objects (people, cars, pets) should be considered secondary resources and defined/described by the representations of their
<timbl__> respective primary resources" that the Primary Re=cource i a function of any Secondary Resoiurtce. This is not the case, though an obvious confudion from the language we use. In truth, there is for any Secondary URI an siungle corresponding Primary URI. (here may though be many primary resources which talk about a given dog, say.)
DC: suggest including diagrams to clarify it is a relationship
TBL: would you accept a change of "secondary resource" to "resource identified by a secondary URI"?
NW: may be useful to preserve the terms for later discussion
DC: likes the idea of scrubbing the definition
<timbl__> http://www.w3.org/2001/tag/2004/webarch-20040928/Overview.html#media-type-fragid
<DanC_> 3.3.1 http://www.w3.org/2001/tag/2004/webarch-20040928/Overview.html#media-type-fragid
DC: sees possible
error
... second bullet... "One cannot carry out .." not true because it
implies that secondary resource is a class.
<Chris> I agree that the term secondary resource seems to confuse more than it clarifies
NW: looking for ways to scrub the term in webarch
I would say it always clarifies -- people actually have a way to discuss the difference now, whereas they did not before.
<DanC_> RF: how about "The terms primary/secondary are only relationship; they don't refer to classes"
NM: The same resource can be identified via multiple URIs; therefore, any resource that is called secondary to another in one case may be primary via a different URI.
DC: no good way to explain this without use of a diagram
<DanC_> ... http://www.w3.org/DesignIssues/Model
NM: perhaps a diagram that shows one resource being idenitified by differrent URIs (one with fragment, another witthout)
CL: I volunteer to redraw these diagrams IF we agree to add them
[lot's of noodling over diagrams happens]
<timbl__> A URI with a fragment identifier may be used to refer to some resource without any implication that the URI without the fragment identifier can be dereferenced. accessible or will ever be accessed.
NM: suggest adding links that show a secondary resource may be both referenced using URIs without fragments and multiple different URIs with fragments, making it clear that the relationship is not exclusive
DC: poll -- for how many people does removing "secondary resource" appeal
3 or 4 say yes
<timbl__> In favor: CL TBL NM DC
<timbl__> against: DC NW PC
NW: offers to give it a whirl
DC: other option, leave document as is and I will try to make the commenter happy
ACTION Norm to create text to make someone happy on secondary resources and fragment ids
(14) spam
<DanC_> ACTION DanC: make sure "web faster" doesn't bother the chair next time he's doing an agenda
<Stuart> http://lists.w3.org/Archives/Public/public-webarch-comments/2004JulSep/0096.html
<DanC_> karl's clarification http://lists.w3.org/Archives/Public/public-webarch-comments/2004JulSep/0126.html
ACTION Norm: create text along the lines of what was discussed regarding primary/secondary resources and fragment ids
DC: understand him to
be saying that what is said about URIs is also applicable to all
W3C standards
... disagree, URI has a special place in architecture that must be
right
... GK says that we haven't said loud enough that URIs are
special.
<DanC_> stet
<DanC_> oops
<DanC_> we'll see if that works ;-)
<Chris> we both said essentially the same thing :)
PROPOSAL: s/understand him/understand Karl/
NM: For the Web architecture in the broader scope, URIs are the one thing that can't be replaced without fundamentally departing from the Web
DC: offer to use that text in response to Karl
<Chris> that works for me - point Karl to the new text and say we are not inclined to change it
<DanC_> ACTION DanC: point out new "URIs are central to web arch" text in reply to Karl, ask if that satisfies
(16) Tim Bray
NW: dealt with
editorial issues already
... [runs though reply to TB]
... 4.4.1 "has it been punctured" answer is no
... TB objects to use of non-human-readable documents as namespace
descriptions
<Chris> 4.5.4 he wants a level of indirection
<Zakim> DanC_, you wanted to propose we affirm "To achieve this goal, the Web makes use of a single global identification system: the URI. URIs are a cornerstone of Web architecture,
TBL: emphasis of TB was on human readbility -- indirection was to satisfy everyone
<Chris> OK so in 4.6, If we change "Because of their role in defining fragment identifier semantics, data" to "Data" what do we loose??
[continuing on down list of TB comments]
<timbl__> PROPOSAL: hange "Because of their role in defining fragment identifier semantics, data" to "Data"
<DanC_> (I'd be happy to lose 4.6)
<noah> s /hange/Change/
4.6 should be "Future directions"
<timbl__> I am in favor
<Chris> Bray said "Data formats enable new
<Chris> classes of applications, and the claim that this is necessarily related
<Chris> to #fragid semantics is ridiculous."
<Chris> end of http://lists.w3.org/Archives/Public/public-webarch-comments/2004JulSep/0100.html
POLL: In favor of change proposal "Because of their role in defining fragment identifier semantics, data" to "Data": RF, CL, PC, NM, SW
RESOLVED: change 4.6 from "Because of their role in defining fragment identifier semantics, data" to "Data"
DC abstains
PROPOSAL: change title of 4.6 to "Future Directions for Data Formats"
TBL: would like it to
say more
... never mind, no objection to proposal
RESOLVED: change title of 4.6 to "Future Directions for Data Formats"
<Chris> Consistent with, for example, 3.8. Future Directions for Interaction
(kd001) indicates satisfied, will close
<DanC_> (it is closed; report will be updated presently)
(kd004) we asked for input, Karl responded ...
<DanC_> KD's clarification on kd004 http://lists.w3.org/Archives/Public/public-webarch-comments/2004JulSep/0048.html
<DanC_> oops
<DanC_> rather: KD's reply http://lists.w3.org/Archives/Public/public-webarch-comments/2004JulSep/0128.html
"out of context, we don't know what URI overloading means."
DC: if we use an example out of WSDL, maybe it would be clearer
<timbl__> He says: "I understand that URI can be used in
<timbl__> another context to identify things, but it's not obvious for someone
<timbl__> who's reading your document and as always thought about URI as
<timbl__> something that gives you a Web page."
DC: isn't there any example like that in WS?
NM: not anything that is deployed, though there are some theories of such in process
<Chris> Chris: what he seems to be saying is, must every URI identify a single thing and thus web pages that talkabout multiple things are bad" oru and swer, i propose, should be "no, web pages that talk about multiole things are fine (but give each thing an anchor so it can be separately referenced"
DC: docbook example using DTD and instance [on whiteboard]
<Chris> Karl later amplified his comment here:
<Chris> http://lists.w3.org/Archives/Public/public-webarch-comments/2004JulSep/0128.html
NW: in short, we need a more compelling example that shows obvious breakage
SW: the current examples do not indicate which one is wrong and why
<Chris> So what will be the choice of a user agent to identify this feature.
<Chris> Does that mean it's a bad practice to have different functionnalities
<Chris> in a same Web page? That the URIs identifying must be something else,
<Chris> for example.
<Chris> http://php.example.org/feature1 The Web page
<Chris> -> http://cooluri.example.org/feature1#definition The definition
<Chris> -> http://cooluri.example.org/feature1#forum The forum
<Chris> Chris offers to respond to commentor along these lines
ACTION Chris: respond to Karl regarding KD004
<DanC_> recent comment from HTML WG http://lists.w3.org/Archives/Public/public-webarch-comments/2004JulSep/0133.html
PC: list appears to be lacking reference to the XLink issue
DC: will investigate
NW: he objects to our document with process objection?
DC: sentence is true (over objections), but it did follow the W3C process
PC: Taskforce has accomplished nothing over seven months
<Stuart> http://lists.w3.org/Archives/Member/tag/2004Oct/0000.html
SW: reads as effectively supporting the HTML WG conclusion prior to actually working on the issue
RF: suggest responding that the Recommendation holds until the taskforce comes up with a different solution that has wider consensus
TBL: (describes alternative solutions for XLink)
<DanC_> ... HTML linking not being reused; HTML WG building an RDF syntax that isn't RDF/XML... this points to the fact that we haven't solved the language mixing issue
<DanC_> ... something isn't working... reuse/modularity
<DanC_> acl cl
TBL: this is a side effect of larger frustration over difference between HTML direction versus XML direction, not-invented-here syndrome, and lack of cooperation with other working group solutions
<paulc> Why W3C Process failed HTML WG: see http://lists.w3.org/Archives/Public/www-tag/2002Jul/0158.html
CL: agree that there are larger issues which caused the HTML WG to go down this path where they end up reinventing XML with different restrictions/syntax
<Chris> woah!
scribe says "trying to keep up" doesn't always work
<Chris> chris:what i actually said: there are some obstactles to reuse - a spec has to be designed to be modular to be reusable in part
NM: one POV is to argue the merits of XLink, is it good, place nice explanation in webarch -- that's nice in principle, but not practical
<timbl__> CL had said that DTD limitations were part of the problem.
<Chris> Chris: I also said that restrictions on usage, content models etc were another part of the prolem
<Chris> Some of these have been solved in the years since, eg move from DTDs to 'modular unreadable DTDs' to RelaxNG
NM: other POV is to say: look, this is a recommendation, it should be considered and what we say in webarch is to simply state that -- there is no conflict with HTML WG because we only say it should be considered
<Zakim> DanC_, you wanted to note that TAG's endorsement of XLink on the merits is the issue here; let's not just say "it's a W3C Rec so you should try it"
NM: it may be worthy of debate, but that debate need not be given in webarch
DC: the opinion expressed by the TAG was actually stronger
<Chris> The fact that we picked it that shows that we feel linking is fundamental to the Web
DC: I don't think we
can cite XLink without endorsing it
... I think that what we said was that XLInk is good, please use
it
<Norm> Political problems notwithstanding, XLink is described as a specification "which allows elements to be inserted into XML documents in order to create and describe links between resources". I don't feel any obligation to make changes on the basis of this comment.
<Zakim> timbl__, you wanted to wonder whether the W3C process guarntees that stg is th ebest, or rather that it is good for some use.
NM: sounds similar to what I am saying (NW agrees)
TBL: people tend to go to whatever WG that specifies things the way that they want to pursue -- a conflict occurs when, eventually, one way is approved as a recommended specification for a given area and another direction is left behind (or placed in a less approved state than "Recommendation")
<timbl__> CL: The SVG WG has revisited the question of whether we should use xlink as not a lot of other specs use it still.
<DanC_> (when are we scheduled to stop?)
<paulc> http://www.w3.org/TR/hlink/
PC: one of the things that caused us to enter the discussion was publication of the HLink draft. I point out that it has been dormant since then. Does anyone know what the current status is within HTML WG?
<Chris> http://www.w3.org/TR/2004/WD-xhtml2-20040722/mod-hypertext.html#s_hypertextmodule
SW: has it been absorbed into larger spec? [answer: no]
<Chris> 10. XHTML Hypertext Module
PC: Is it your view that we are making a normative requirement on use of XLink?
NW: no, we have been careful to say "should" and consider
PROPOSAL: we stand by our text, respond to commenter as such
objection: CL, TBL
<Chris> http://www.w3.org/TR/2004/WD-xhtml2-20040722/mod-hyperAttributes.html
<Chris> 13. XHTML Hypertext Attributes Module
DC: please propose solution
TBL: uptake of XLink was used by SVG, considered and rejected by HTML
<DanC_> ... i.e. let's note that in webarch
<paulc> http://w3.org/2001/tag/issues.html?type=1#xlinkScope-23
PC: point about SVG is also listed in our issue list
<Stuart> Re: HLink checkout HTML-WG Roadmap http://www.w3.org/MarkUp/xhtml-roadmap/#xhtml20
<Chris> http://www.w3.org/2001/tag/issues.html?type=1#xlinkScope-23
PC: TAG issue xlinkScope-23 is at "no decision, after 1.0"
NM: why doesn't "should consider" satisfy their complaint?
DC: we don't mention other solutions
<Chris> "The HLink module defined in this specification provides XHTML Family Members with the ability to specify which attributes of elements represent Hyperlinks, and how those hyperlinks should be traversed, and extends XLink use to a wider class of languages than those restricted to the syntactic style allowed by XLink."
<Chris> http://www.w3.org/TR/2002/WD-hlink-20020913/
NM: but it is the only
recommendation that does, specifically, have the goal of satisfying
this topic
... there are other XML languages that intend to use XLink, not
just SVG
<Zakim> Chris, you wanted to talk about link vs anyURI
CL: part of the
problem, historically, is that a combinatorial explosion of
attributes that try to do the same thing as XLink is believed to be
less good than using XML elements to do the same.
... part two, although that is true, it is often the case that the
designer only wants one URI associated with an existing element,
and if that happens to remain the case it is simpler than XLink
to use attributes
<Chris> Chris outlines a possible future linking architecture that is succinct, expressive, etc
TBL: it is quite reasonable that a reader of this document might be led to believe that XLink is applicable in all cases, which is not appropriate, and thus I hesitate to endorse XLink in this way without more clarificcation
DC: hears 2 things
<Chris> Chris: And similarly to people over selling Xlink (RDF should use Xlink, etc) people have oversold RFF (XLink should use RDF)...
DC: (1) change "Xlink is an appropriate specification" to "Xlink is a specification"
<Norm> PROPOSAL XLink is not the only linking design that has been proposed for XML, nor is it universally accepted as a good design. See also TAG issue ...
DC: (2) salt to taste with reference to how SVG uses XLink, other technology uses (or does not use) Xlink, etc.
RESOLVED: add that XLink is not the only linking design that has been proposed for XML, nor is it universally accepted as a good design. See also TAG issue xlinkScope-23
ACTION Stuart: respond to commenter with this resolution
PC: are there any other new comments?