TAF f2f Day 2 AM
6 Oct 2004


See also: IRC log


Tim, Dan, Norm, Paul, Chris, Noah, Roy, Stuart
Stuart (with help from others)
Chris, timbl__, noah, NM, norm, TimBL, roy_scribe




<timbl__> fjhsdkjfhsjkdhfkjq

<Chris> Scribe: Chris

Stuart: Scribe for this afternoon please?


<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

f2f minutes

<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


<scribe> ACTION: Chris collect IRC logs from last f2f and turn into minutes

people changes


<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 ;-)

Charter update

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

future meeting plans

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

AC report for TAG

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"/>

Agenda review redux

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


<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


"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


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


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


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


"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


<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__


Last Call comments

[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


<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?

Summary of Action Items

[NEW] ACTION: Chris collect IRC logs from last f2f and turn into
... minutes
[NEW] ACTION: Norm add "for more info, see also" link to
... http://www.w3.org/TR/2004/WD-qaframe-spec-20040830/#extensions
... to 4.x
[NEW] ACTION: Paul create draft summary for AC
[NEW] ACTION: Paul to create new monthly summary
[NEW] ACTION: Stuart get a timescale from ian about charter
... revision and availability
[NEW] ACTION: Tim to investingate possible staff contact for TAG
[NEW] ACTION: Tim to investingate possible staff contact for TAG,
... due date 20 October 2004

Minutes formatted by David Booth's scribe.perl 1.90 (CVS log)
$Date: 2004/08/10 15:51:28 $