W3C home > Mailing lists > Public > www-archive@w3.org > October 2004

[Fwd: TAG F2F minutes, Tue 10 Aug PM]

From: Dan Connolly <connolly@w3.org>
Date: Mon, 18 Oct 2004 17:20:41 -0500
To: www-archive@w3.org
Message-Id: <1098138041.30433.927.camel@dirk>
OKd for world-access in 18 Oct telcon.

Dan Connolly, W3C http://www.w3.org/People/Connolly/

attached mail follows:

TAG F2F minutes, Tue 10 Aug PM

<paulc> Swapping AM2 and PM1 slots in original agenda.
<paulc> Swapping AM2 and PM1 slots in original agenda.
<paulc> Let's review the changes Norm is proposing to the 

WebArch document.
<paulc> Link to the Editor's draft:


<paulc> Green material is changed. Yellow material is new.
<paulc> Section 2.2 changed to include definition of 
<paulc> TimBL: I do not like "can retrieve".
<clilley> a representation of the resource could be 
requested over a network
*** Norm [ndw@] has joined #tagmem
*** Stuart [skw@] has joined #tagmem
*** DanC [connolly@] has joined #tagmem
<clilley> a representation of the resource could be 
requested over a network
<paulc> DanC: I would prefer a forward pointer to the defn 
of Information Resource.
<DanC_jam> in 2.2, suggest changing "We use the term 
information resource to refer to those resources for which 
you can retrieve a representation over the network." to "A 
special class of resources, information resources, is 
discussed in section 3.1. Information Resources and 
*** DanC left #tagmem [Client exiting]
<timbl> The term "Information Resources" refers to the 
class of things which carry information.  

<paulc> Dan proposes a two part change:
<paulc> a) make forward reference to 3.1
<paulc> b) change 3.1 "If a resource has a representation 
then it is an information resource.
<DanC_jam> in section 3.1, I prose that rather than define 
Information Resource, we bound it below as: if a resource 
has a representation, then it is an information resource.
* timbl proposes the above text
<timbl> The term "Information Resource" refers to the 
class of things that convey information.  
<paulc> In 3.1, "Information resources are resources that 
convey information."
<paulc> ... along with:
<paulc> "If a resource has a representation then it is an 
information resource."
<paulc> In Section 2.2 add a forward pointer "A special 
class of resources, information resources, is discussed in 
section 3.1, Information Resources and Represetantions."
<paulc> The forward pointer replaces the existing text "We 
use the term information resource to refer to those 
resources for which you can retrieve a representation over 
the network."

<paulc> TAG members decided to live with the above 
proposed change.
<paulc> Section 2.3.1 with regards to URI aliases.
<paulc> use the following text:
<DanC> (I think this is editorial and it's ok for the 
minutes to just say "the TAG worked on the wording of 
<paulc> Deployment of URI aliases reaises the cost or may 
even make it impossible for software to determine that the 
URIs identify the same resource.
<paulc> This was previously the third sentence and will 
now be the second sentence.
<DanC> SW gives the example of "meter"; PC gives an 
example of 2 WGs specifying the same datatype
<paulc> Change the story to ask the question "Does it 
matter which URI I bookmark?" and Nadia explains why it 
matters (it depends on weather you want the 08.03 weather 
or the current weather.
<paulc> In section 2.5  remove "sequence of characters".
<DanC> I'm uncomfortable with "URI Ownership". I'd rather 
do without it. Masinter asked for this again recently, 
which reminded me to re-find 
<paulc> Change 2.5 to say:
<paulc> A widely deployed technique to avoid URI 
overloading is delegated ownership."
<Stuart> +1 to DanC reservation on the concept of URI 
<Stuart> Also, 
<paulc> Section 2.5 should be named URI allocation with 
the text in 2002Oct/0287.html and then there would be a 
2.5.1 URI Ownership 
<DanC> the "... global agreement... " paragraph might 
overlap with the existing "... useful for a URI scheme to 
establish ..." parap
<paulc> And we will add a section 2.5.2 URIs that are not 
<DanC> q+ to suggest demoting the box "Good practice: 
Avoiding URI Overloading"
<DanC> q+ to review the TOC of 2.x esp to suggest that 
overloading goes under uri/resource relationship
<paulc> At TimBL's suggestion Section 2.4 was shortened 
(and clarified).
<paulc> Dan C's suggestions to Section 2.4 were also 
<paulc>Dan C: Section 3.3.1 should not use the WebArch 
terminology in the story.  Text was removed which stated 
"authoritative interpretation ...".

<paulc>Section 3.4, Metadata Association example added and 

<paulc> www-tag archive 2004Aug/0012.html
<paulc> contains TimBl's text for Section 3.4
<paulc> The meeting decided incorporate TimBl's text and 
to add some references to this text (to http spec and 
Apache docs).

<paulc> next change is in Section 3.5 to point out reasons 
to do post.
<paulc> Editor will add examples of why you should use 
post when no oblications are implied (reasons can be found 
in the finding).

<paulc> next change in Section 3.6.
<paulc> Delete text "There are applications ... web 
<DanC> scalability from masinter 

<paulc>Add reference to spec writer in Good Practise (to 
ensure they don't force access to URI representations).
<paulc>DanC: Do we really need this good practise since it 
is not enough of a bumper sticker saying.
<paulc>PaulC: leave the material in or go back and discuss 
the original comment again.
<paulc>DanC: Let's delete the new text and not revisit the 
<paulc>TAG agreed to move on leaving the new text in 

<paulc>Reviewing changes in Section 4.3:
<paulc>TAG changed the text "For instance ... access to 
content" to "Designers should consider appropriate 
technologies such as access control and encryption for 
limiting the audience."

<paulc> Reviewing changes to Section 4.5.1:
<paulc> Accepted except for number 9 (since it seems to 
define a loop: reasons for using a text format - it is a 
text format).

<paulc> Reviewing changes to Section 5.1:
<paulc> We added an Orthogonality priniciple and 
completely renovated the first paragraph to simplify and 
shorten it.
<paulc>Editor agreed to take another attempt at the 
example linking a bad change in HTML based on the HTTP 

<paulc> Reviewing changes to Section 5.2:
<paulc> The Editor's change was accepted.

<paulc> Reviewing changes to Glossary: defn of Resource.
<paulc> Delete "A general term for".

<paulc> Discussion on Outstanding issues:

<paulc> HTTPSubstrate-16: Should HTTP be used as a 
substrate protocol? Does W3C agree with RFC 3205? 
<paulc> Original comment from Mark is in:
<paulc> and original feedback from XML Protocol WG is in:
<paulc> RoyF reported that there is very little 

application work being done in IETF at the moment.
<paulc> PaulC: Either the problems in the IETF and XMLP 
different opinion on using HTTP are important or they are 
not important since they don't seem to have harmed us over 
the last three+ years.
<paulc> DanC: The best way of moving this forward would be 
to get someone to draft a new BCP and to engage the IETF 
via doing the work.
<paulc> DanC: Asked to poll the group:
<paulc> Option 1: Recruit someone from WS Activity to 

write a new BCP draft
<paulc> Option 2: Close the issue.
<paulc> Responses:
<paulc> ChrisL: Option 1
<paulc> RoyF: No preference
<paulc> Paulc: Option 1
<paulc> DanC: Option 1
<paulc> StuartW: Option 1 (try to recruit Mark N)
<paulc> TimBL: Option 1
<paulc> NormW: Option 1
<paulc> TimBL: maybe we should start writing a finding to 

clearly define the differences.
<paulc> PaulC: lets start a finding on how the RFC differs 
from the WebArch document.
<paulc> Summary: Action on DanC to recruit an author to 
draft a response to HTTPSubstrate-16 forward.

<paulc> RE: WebArch comment from QA WG 
<paulc> Summary: Action on StuartW to reply to QA WG that 
TAG will consider this input in is re-started work on 
Extensibility and Versioning

<paulc> Re: Pat Hayes comments in:
<paulc> Summary: Action on StuartW to respond that we have 
tried to address many of his comments and that he invite 
is review of the Second Last Call.

<paulc> The meeting recessed at 5:02pm EDT.


Paul Cotton, Microsoft Canada 
17 Eleanor Drive, Nepean, Ontario K2E 6A3 
Tel: (613) 225-5445 Fax: (425) 936-7329 

Received on Monday, 18 October 2004 22:19:45 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:32:34 UTC