05-07-tag 66.1 KB

Raw Blame History Permalink

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
       "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head profile="http://www.w3.org/2003/g/data-view">
  <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
  <title>Basel Meeting of the W3C Technical Architecture Group, 5-7 Oct 2004</title>
  <link rel="transformation" href="http://www.w3.org/2001/tag/2004/10/groktagftf.xsl" />
  <style type="text/css">
   h1 { text-align: center }
   body { background: white; color: black }
   .cancelled {color: #BEBEBE}
   .overdue { background: red; color: black }
   dd { margin-top: .2em }
   div.minutes div { border-left: dotted; padding-left: 1em }
   div.minutes div div { border-left: solid; padding-left: 1em }
   div.minutes .resolved { background: green; color: white }
   div.minutes .action { background: orange; color: black }
   blockquote { border-left: double; padding-left: 1em; font-style: italic; text-align: justify }
   address { text-align: right }
  </style>
  <link type="text/css" rel="stylesheet" href="/StyleSheets/base.css" />
  <link />
</head>

<body>
<div><a href="../../../../">W3C</a> * <a href="../../">TAG</a> | Previous: <a
href="../09/27-tag.html">27 Sep</a></div>

<h1>TAG Meeting, 5-7 October 2004</h1>

<h2><a
href="http://lists.w3.org/Archives/Public/www-archive/2004Oct/att-0024/tag-basel-2.jpg"><img
align="right" src="tag-basel.jpg" alt="tag members on the roof in
Basel" /></a>hosted in Basel, Switzerland by <a href="http://www.day.com/">Day
Software</a></h2>

<div style="text-align: center">on this page: <a
href="#who">Participants</a> * <a href="#where">Venue</a> * <a
href="#agenda">Agenda</a> * <a href="#minutes">Minutes</a><br />
nearby: <a href="http://lists.w3.org/Archives/Public/www-tag/">www-tag
archive</a>, irc <a
href="http://www.w3.org/2004/10/05-tagmem-irc">Tue</a>, <a
href="http://www.w3.org/2004/10/06-tagmem-irc">Wed</a>, <a
href="http://www.w3.org/2004/10/07-tagmem-irc">Thu</a><br />
<small>also: fun with <a
href="http://esw.w3.org/topic/MeetingRecords">MeetingRecords</a>, <a href="http://www.w3.org/2003/g/data-view">GRDDL</a>: <a
href="groktagftf.xsl">groktagftf.xsl</a>, <a href="http://www.w3.org/2000/06/webdata/xslt?xslfile=http%3A%2F%2Fwww.w3.org%2F2003%2F11%2Frdf-in-xhtml-processor&amp;xmlfile=http%3A%2F%2Fwww.w3.org%2F2001%2Ftag%2F2004%2F10%2F05-07-tag">output</a>, <a
href="Makefile">Makefile</a>, <br /> photos by NDW: <a
href="http://lists.w3.org/Archives/Public/www-archive/2004Oct/att-0023/tag-basel-1.jpg">photo1</a>
<a
href="http://lists.w3.org/Archives/Public/www-archive/2004Oct/att-0024/tag-basel-2.jpg">photo2</a></small>
</div>

<p>The goals of the meeting are:</p>
<ul>
  <li>Propose responses to <strong>all</strong> LC#2 comments</li>
  <li>Progress on Issues and Findings</li>
</ul>

<p>Preparation materials include:</p>


<ul>
  <li><cite><a href="http://www.w3.org/TR/2004/WD-webarch-20040816/">Architecture of the World Wide Web, 1st Edition</a></cite><br />
Last Call WD 16 Aug 2004 (2nd last call)
  </li>
  <li><a href="http://www.w3.org/2001/tag/webarch/">WebArch
    Editor's draft</a> (esp. <a href="http://www.w3.org/2001/tag/2004/webarch-20040816/">28 Sep snapshot</a>)</li>
  <li><a
    href="http://lists.w3.org/Archives/Public/public-webarch-comments/">Archive of  public-webarch-comment</a>, <a href="http://www.w3.org/2001/tag/2004lc/lc-status-report.html">status report</a></li>
    <li><a href="http://www.w3.org/2001/tag/issues">TAG issues
list</a></li>
</ul>


<address>
  created by Stuart Williams, TAG co-chair<br />
  minutes by Dan Connolly<br />
  with thanks to the scribes: Noah Mendelsohn, Norm Walsh, Chris Lilley, Tim Berners-Lee, Roy Fielding, Paul Cotton<br />
  <small>$Revision: 1.38 $ of $Date: 2004/10/18 21:35:08 $; see <a href="#chlog">TODO list and change log</a></small>
</address>
<hr />

<div class="roll"><h2 id="who">Participants</h2>

<p>All <a href="../../#Membership">current members</a> of the
TAG participated in the meeting:</p>

<ol>
<li>Tim <b>Berners-Lee</b> (<i>TBL</i>)<br />
<small>arrived later on Tuesday</small></li>
<li>Dan <b>Connolly</b> (<i>DC</i>)<br />
<small>arrived later on Tuesday</small></li>
<li>Paul <b>Cotton</b> (<i>PC</i>)</li>
<li>Roy <b>Fielding</b> (<i>RF</i>)</li>
<li>Chris <b>Lilley</b> (<i>CL</i>)</li>
<li>Noah <b>Mendelsohn</b> (<i>NM</i>)</li>
<li>Norm <b>Walsh</b> (<i>NDW</i>)</li>
<li>Stuart <b>Williams</b> (<i>SW</i> chair)</li>
</ol>
</div>

<div>
<h2 id="where">Venue, Local Arrangements</h2>

<p>The meeting is at the <a
href="http://www.day.com/content/en/contact/basel.html">Day office in
Barfusserplatz</a>, <a
href="http://www.basel.ch/?lang=en&amp;ctool_page_id=663">Basel</a>.</p>
<blockquote>
Day Software AG<br />
Barfusserplatz 6<br />
4001 Basel<br />
Switzerland<br />
T +41-61-226 98 98<br />
F +41-61-226 98 97<br />
<a href="mailto:ch.info@day.com">ch.info@day.com</a><br />
</blockquote>

<p>The TAG thanks Day Software for a terrific job of hosting our
meeting, and for supporting Roy Fielding's participation in the TAG.
Special thanks to Jean-Michel Pittet for his contributions to the
hosting arrangements.
</p>

</div>


<div>
<h2 id="agenda">Agenda</h2>

<ol>
  <li><a href="#administrivia">Administrative</a>
  <ol>
    <li><a href="#start">Convene, take roll, review agenda</a></li>
    <li><a href="#meeting-plans">Future meeting plans</a></li>
    <li><a href="#revrec">Review of records</a></li>
    <li><a href="#staffcon">TAG staff support</a></li>
    <li><a href="#chartpat">TAG Charter, patent policy</a></li>
    <li><a href="#tagac">AC report for TAG</a></li>
  </ol>
  </li>

  <li><a href="#webarch-dc">A review of the 28 Sep webarch draft</a></li>
  <li><a href="#archgen">Representations over-constrained?</a></li>
  <li><a href="#lc-comments">WebArch LC#2 Comments</a></li>
  <li><a href="#infores">Information Resources, Web Resources and
  httpRange-14 (I)</a></li>
  <li><a href="#infores2">Information Resources, Web Resources and
  httpRange-14 (II)</a></li>
  <li><a href="#lc2qa">Outstanding comments from the Quality Assurance Working Group</a></li>
  <li><a href="#lcstatus2">WebArch LC#2 Comments (II)</a></li>
  <li><a href="#htxl">xlinkScope-23, comments from HTML WG</a></li>
  <li><a href="#extvers">Planning work on extensibility and versioning</a></li>
  <li><a href="#HTTPSubstrate-16">HTTPSubstrate-16</a></li>
  <li><a href="#infores234">Information Resources, httpRange-14 (Thu)</a></li>
  <li><a href="#plan234">Schedule for webarch end-game</a></li>
  <li><a href="#txhost">Adjournment, thanks to the host</a></li>
</ol>

<p><em>Other items from the
<a
href="http://lists.w3.org/Archives/Public/www-tag/2004Sep/0184.html">proposed
agenda</a> were not discussed.</em></p>

</div>

<div class="minutes">
<h2 id="minutes">Minutes</h2>

<div>
<h3 id="administrivia">Administrative</h3>

<div class="roll">
<h4 id="start">Convene, take roll, review agenda</h4>

<p>SW convened the meeting Tuesday morning at 9am. See <a href="#who">attendance</a> above.</p>

<p>SW welcomed Noah to his first TAG ftf meeting.  <em>later, after
Noah apologized for perhaps disrupting the discussion of httpRange-14,
Norm said "Don't be silly; you've helped us make more progress in one
day than we made in the last six months."</em></p>

<p>The group reviewed the <a
href="http://lists.w3.org/Archives/Public/www-tag/2004Sep/0184.html">proposed
agenda</a>, noting that comments on the 2nd (Aug 2004) last call
webarch document motivated discussion of issues httpRange-14 and
xlink23, and that DanC sent <a
href="http://lists.w3.org/Archives/Public/www-tag/2004Oct/0003.html">comments
5Oct</a> that include agenda requests.</p>

</div>


<div>
<h4 id="meeting-plans">Future meeting plans</h4>

<p>We reviewed the following opportunities to meet in face-to-face:</p>
<dl>
  <dt>29th-30th November 2004 <strong>Boston, MA, USA</strong></dt>
    <dd>already scheduled.
    <p>Note announcements to W3C members regarding
<a
    href="http://lists.w3.org/Archives/Member/w3c-ac-members/2004JulSep/0010.html">W3C@10</a>
    and <a
    href="http://lists.w3.org/Archives/Member/w3c-ac-members/2004AprJun/0060">W3C
    AC Meeting</a></p>
</dd>
  <dt>28th Feb- 4th March 2005 <strong>Boston, MA, USA</strong></dt>
    <dd>This is the schedule for the W3C Technical Plenary (per <a
    href="http://lists.w3.org/Archives/Member/chairs/2004JulSep/0092.html">13 Sep announcement</a>).</dd>
  <dt>10-14th May 2005 <strong>Chiba, Japan</strong></dt>
    <dd><a href="http://www.www2005.org/">WWW2005</a></dd>
  <dt>6-7 June 2005 <strong>Cannes, France</strong></dt>
    <dd>This is the plan for the W3C AC meeting (per <a
    href="http://lists.w3.org/Archives/Member/chairs/2004JulSep/0092.html">13
    Sep announcement</a>)
  </dd>
  <dt>Summer 2005 in Kanas City</dt>
  <dd>DanC made a tentative offer to host (<a
    href="http://lists.w3.org/Archives/Member/tag/2004Sep/0006.html">6 Sep)
  </a></dd>
  <dt>October 2005?</dt>
</dl>

<p>Regarding the Nov 2004 meeting, NM confirmed plans to attend; SW
offered regrets, noting he could travel Monday (29 Nov) at the
earliest.</p>

<p>Chris noted that the W3C Technical Plenary is a great for meeting
with others but not so good for advancing our own work. There were
some inquiries about the program committee. PC and NDW are likely to
have obligations that week that affect TAG meeting scheduling.</p>

<p>In response to a question from Paul about where the webarch
document would likely be in March 2005, there was discussion of the
division of <a href="../../tag/issues">issues</a> between those we
plan to treat in the 1st edition and those we plan to treat in later
editions, and to what extent the 1st edition not only emphasized the
deployed web but over-constrained the architecture based on it. SW
noted that our 'heartbeat' obligations to publish regularly come due
again in Nov.</p>

<p>PC asked about the timing of the TAG election; SW said the results
should be available by late Jan/early Feb; PC asked about a meeting in
the first week of February 2005 to bring new members up to speed; a
poll showed insufficient support. The importance of letting TAG
candidates know the schedule was re-iterated.</p>

<p><em>Further discussion of future ftf meetings was postponed until
on Weds AM; the meeting continued with <a href="#webarch-dc">a review
of the 28Sep editor's draft</a>.</em></p>

<p><strong class="resolved">RESOLVED: to meet next 18 Oct and cancel
the 11 Oct telcon, <em>TBL</em> abstaining.</strong>. NM at risk due
to plane flight landing 1 hour before TAG telcon.</p>

<p>PaulC asked about the 22 Nov teleconference, a week before Nov f2f,
and US thanksgiving. Stuart, Noah, and Paul reported conflicts.
Stuart offered regrets for 15th and 22nd Nov; NDW offered to chair 15
and 22 Nov.
</p>

<p>We noted that scheduling during the Technical Plenary week depends
on various factors outside our control, but based on the information
at hand, we <strong class="resolved">RESOLVED: to meet 1/2 day on 28
Feb 2005 in Boston, MA, USA, and for TAG members to participate on a
best-effort basis in liaison meetings throughout the week of the W3C
Technical Plenary.</strong> Timbl noted a possible conflict with the
2nd half of that week.  Paul suggested that if we have a Proposed Rec
we will be collecting input on the second edition of the Web
Architecture document.</p>

<p>Chris offered to host a meeting co-located with the W3C AC meeting
June 6-7 2005 in Cannes, France. We noted the risk that upcoming
elections and appointments would impact scheduling decisions, but
based on the information at hand, we <strong
class="resolved">RESOLVED: to meet 8-10 June, South of France near
Cannes host Chris/ERCIM</strong>.  Dan offered tentative regrets, not
having enough information to commit to anything beyond remote
participation at this time. TimBL was also unable to comfirm
in-person attendance.</p>


<p>Norm offered to host in Western Mass, contingent on his availability
to stand for election and subsequently getting elected.</p>

<p>Dan confirmed his offer to host in Kansas City, "The City of
Fountains"; he noted the relevant airport is MCI, Kansas City
International and gave a brief geography lesson about Kansas City
Kansas, Kansas City Missouri, and Overland Park.  Several members
asked about when flights arrive and leave Kansas City; DanC wasn't
familiar with the schedules but Noah noted that a quick search of
American Airlines (for March dates, as Sep 2005 is not posted yet)
suggests that return options from Kansas City to Boston are (Lv: 3:04P
Ar: 8:42P) or (Lv: 5:13P Ar: 10:30P).  Noting the various risks as
before, we <strong class="resolved">RESOLVED: to meet 20-22 September,
in Kansas City, DanC to host</strong>

</p>
</div>

<div><h4 id="revrec">Review of records</h4>

<p><strong class="resolved">RESOLVED: to accept <a href=
"http://lists.w3.org/Archives/Public/www-tag/2004Sep/att-0170/minutes.html"
>27 Sep minutes</a>, amended to show regrets from RF.</strong></p>

<p>PaulC reported, with regret, that he had not yet found time to
make substantial progress toward a summary
of the Aug ftf meeting. Chris reported success with David Booth's IRC
post-processing tool (<a
href="http://lists.w3.org/Archives/Public/www-tag/2004Oct/att-0006/tagtest.html">output
from yesterday's IRC log</a>) and offered to help. <strong
class="action">ACTION CL: Chris collect IRC logs from last f2f ( cf <a
href="http://lists.w3.org/Archives/Member/tag/2004Aug/0026.html">pointers
for assembling meeting minutes</a> of 11 Aug) and turn into
minutes.</strong></p>
</div>

<div>
<h4 id="staffcon">TAG staff support</h4>

<p>Stuart noted that Ian Jacobs has taken on the role of head of W3C
Communications, and is consequently not available to participate in
the TAG (cf <a
href="http://lists.w3.org/Archives/Member/tag/2004Sep/0062.html">Role
changes</a>, member only).  In discussion of how to recover from the
loss of Ian's contributions, several lauded Norm for his performance
as editor, but we observed that organizing the homepage and issues
list well makes the group much more productive, and lack of staff
support here is costly.  DanC said he had done a bit to reduce
expectations about how up-to-date the TAG home page should be: it
shows the regular teleconference schedule but not exceptions.
</p>


<p>TimBL reported success with <a
href="http://www.w3.org/2002/09/wbs/1/">WBS surveys</a> accross a
range of W3C groups and encouraged its use in the TAG. He said he
looks forward to something similarly useful and reusable for action
tracking.  RF asked what tools the W3C systems team is comfortable
supporting; DanC said they are comfortable deploying PHP/mySQL tools
and to a lesser extent, XSLT, perl, python, etc. Chris noted Exit, the
system that Ian used and developed, but this is a desktop/client tool,
and not something that distributes the work as RF noted many tools do.
Norm said Exit was difficult to deal with, and that he is often
frustrated by web based forms. DanC noted the LC2 tracking system is
fundamentally email-based, and Noah pointed out that he often works
offline and favors email.  <strong class="action">ACTION TBL: to
investigate possible staff contact for TAG, due date 20 October
2004</strong>
</p>
</div>

<div>
<h4 id="chartpat">TAG Charter, patent policy</h4>

<p>Stuart reported that the outcome of recent AB and team discussions
of which role TAG members play for patent policy purposes is that TAG
members are treated as Invited Experts. There was some discussion of
when this outcome takes effect, what opportunities there were for
commenting on the specific text, etc. Paul suggested that the
resulting charter may impact potential candidates' choices about
whether to run. <strong class="action">ACTION SW: get a timescale
from Ian about charter revision and availability</strong>. Paul,
Stuart, and others expressed their appreciation for the responsiveness
of the team to TAG discussion of this topic.
</p>

</div>

<div><h4 id="tagac">AC report for TAG</h4>

<p>Paul volunteered to do the next monthly report and noted that
the AC report is cumulative of the previous three reports.
<strong class="action">ACTION PC: create draft summary for AC, get it
to Steve Bratt by Oct 22</strong></p>

<p>Stuart relayed a <a
href="http://lists.w3.org/Archives/Member/w3c-ac-forum/2004JulSep/0029.html">request
for 'hot topics' for the AC meeting</a>.  DanC said that when he
presented to the previous AC on behalf of the TAG, he got little
response to webarch-related questions and suggested that this is to be
expected: the AC is not a technical forum. TimBL concurred; we should
seek organizational input from the AC, not technical. There was little
support for doing a TAG panel at the AC.
</p>

</div>

</div>


<div>

<h3 id="webarch-dc">A review of the 28 Sep webarch draft</h3>

<p><em>based on <a
href="http://www.w3.org/2004/10/05-tagmem-irc#T09-03-19">IRC log
starting Tue 09:03:19Z</a></em></p>

<p>In preparation for the meeting, DanC sent <a
href="http://lists.w3.org/Archives/Public/www-tag/2004Oct/0003.html">comments on the 28Sep editor's draft</a>, some of which were flagged for discussion.</p>

<p>DanC's suggested rewrite of the abstract appealed to the editor and others; suggestions included splitting a long sentence into 3, resulting in something like:</p>

<blockquote>

The World Wide Web uses relatively simple technologies with sufficient
scalability, efficiency and utility that they have resulted in a
remarkable information space of interrelated resources, growing across
languages, cultures, and media. In an effort to preserve these
properties of the information space as the technologies evolve, this
architecture document discusses the core design components of the
Web. They are identification of resources, representation of resource
state, and the protocols that support the interaction between agents
and resources in the space. We relate core design components,
constraints, and good practices to the principles and
properties they support.

</blockquote>

<p>The group discussed proper use of <a href="http://www.ietf.org/rfc/rfc2119">RFC2119</a> keywords, esp</p>

<blockquote>6. Guidance in the use of these Imperatives
    Imperatives of the type defined in this memo must be used with care
    and sparingly. In particular, they MUST only be used where it is
    actually required for interoperation or to limit behavior which has
    potential for causing harm (e.g., limiting retransmissions) For
    example, they must not be used to try to impose a particular method
    on implementors where the method is not required for
    interoperability.
</blockquote>

<p>After discussion, it seemed that the use of these keywords in
webarch is as appropriate as the use in RFC2119 itself. Concerns about
"conformance" turned out to be misplaced; the constraints in RFC2119
regard interoperability, and as such, the editor was advised to change
the "however" in "in accordance with RFC 2119 [RFC2119]. However,
...".</p>

<p>DanC's request to
add the http/dns example back into section 2.2.1.1. URI ownership and to discuss <tt>data:</tt> as an allocation scheme other than ownership gained some support and the editor is inclined to make that change.</p>

<p>After some discussion of the merits of <q>The distinguishing
characteristic of representation reuse, as opposed to aliasing, is
that the underlying resources are different.</q> from 2.3.2, the
editor dropped it.</p>

<p>DanC expressed disappointment that section 2.5 URI Opacity didn't
make the point about providers rights to choose names, and suggested
adding a link to the siteData-36 issue; NDW said he'd take a look.</p>

<p>There was support for changing <q>Principle: Data-metadata
inconsistency</q> in 3.4 to a constraint, related to 5.3 <q>Principle:
Error recovery</q></p>

<p>Regarding some of the good practice notes, DanC suggested noting QA
in addition to I18N and WAI in the scope section of the introduction;
this appealed to several TAG members and the editor was advised to do
so.</p>

<p>Several concurred with DanC suggested replacement text in 3.3:</p>
<blockquote>a representation consists of a sequence of bytes plus an Internet Media Type [RFC2046] which tells whether the bytes represent text, graphics, video, a spreadsheet, etc. The IANA registry [MEDIATYPEREG] maps media type names to data format specifications (section 4). </blockquote>

<p>NDW expressed willingness to note the security risk DanC raised
regarding "Also, they[binary formats] can be consumed more rapidly by
agents in those cases where they can be loaded into memory and used
with little or no conversion."</p>

<p>DanC congratulated NDW on elaborating on the trade-off regarding
extensibility in section 4.2, but said he would prefer not to include
such a strong good practice note: "A specification SHOULD provide
mechanisms that allow any party to create extensions.". NM concurred,
arguing that there are many, many dimensions to any spec. Most of
these dimensions shouldn't be extensible. Should we allow XML to go
non-Unicode? The trick and the art is to choose just those you want to
worry about. PC expressed a concern regarding synchronization between
the extensiblity/versioning finding and this section of
webarch. <em>Discussion was inconclusive at this point; it continued
in <a href="lc2qa">discussion of QA comments</a>.</em></p>

<p><em>TimBL joined at about 10:33:38Z</em></p>

<p>Regarding the "Good practice: QNames Indistinguishable from URIs"
note in 4.5.5, i.e. "A specification in which QNames represent
URI/local-name pairs SHOULD NOT allow both QNames and URIs in
attribute values or element content, where they would be
indistinguishable."DanC suggested rephrasing as a constraint, perhaps
replacing "SHOULD NOT" with "do not". This was generally
supported.</p>
</div>

<div><h3 id="archgen">Representations over-constrained?</h3>

<p>NM raised a related concern that current web arch is too strong in
implying that all representations are single streams, are specifically
octet streams, and need to be typed with IANA media
types. Generalizing appealled to several group members, but there was
some concern about the impact of such a change at this point in the
process; for example, whether we would owe the community another last
call. <strong class="action">ACTION NM: to take a run through to see how
generalizing 'representation' to be less constrained would look with
more careful terminology, report on whether this looks feasible or
not.</strong> <em>later in the meeting, NM agreed to try to do this in
preparation for the 18Oct telcon</em></p>
</div>

<p><em>Then we had lunch.</em></p>

<div>
<h3 id="lc-comments">WebArch LC#2 Comments</h3>

<p><em>based on <a
href="http://www.w3.org/2004/10/05-tagmem-irc#T12-23-05">IRC logs
starting 12:23:05Z</a></em></p>

<p>We started reviewing the pending <a
href="http://lists.w3.org/Archives/Public/public-webarch-comments/">comments</a>,
viewed thru the <a
href="http://www.w3.org/2001/tag/2004lc/lc-status-report.html">status
report</a> Revision 1.10 of 2004/10/05 12:21:52.</p>

<ol>
<li><b>Request for Review of TAG AWWW 2nd LC Draft.</b>
ACTION SW: to review <a href="http://lists.w3.org/Archives/Public/public-webarch-comments/2004JulSep/0131.html">comments from PatH</a> for issues that merit discussion. <em>DONE later in the meeting</em></li>

<li><b><a href="http://www.w3.org/mid/623505000.20040829013738@bumerang.ro">Comments on Working Draft 5 July 2004</a> - URI Overloading</b> is actually spam (based on a comment on an earlier draft)</li>

<li><b><a href="http://www.w3.org/mid/1E4A0AC134884349A21955574A90A7A50A1C84@trebe051.ntc.nokia.com">"information resource"</a></b> was postponed until <a href="#infores">discussion of comments regarding httpRange-14</a></li>

<li><b><a href="http://www.w3.org/mid/4137E592.8070007@cisra.canon.com.au">non-authoritative syntaxes for fragment identifiers</a></b> RF reported on discussion with the commentor which suggest that removing the "One may compare ..." sentence and the one before it would satisfy the commentor. NDW said that as a result of the discussion he is inclined to remove the sentences and make the point in the section on URI opacity.</li>
<li>postponed till <a href="#infores">discussion of comments regarding httpRange-14</a></li>

<li><b>AWWW, 20040816 release, sections 1 and 2</b> <strong class="action">ACTION NDW: to note
this thread [closed] in the archive per msg from gk.</strong></li>

<li><b>resources/representations [was: random comments on 2nd LC of WebArch]</b> postponed till <a href="#infores">discussion of comments regarding httpRange-14</a></li>

<li><b>too positive on extensibility [was: random comments on 2nd LC
of WebArch]</b> NDW suggested recent edits to 4.x are responsive to
this comment. <strong class="action">ACTION CL: to respond to the commenter for issue
8 pointing to the new draft on extensibility</strong> <em>CL sent <a
href="http://lists.w3.org/Archives/Public/public-webarch-comments/2004OctDec/0001.html">such
a message</a> during the meeting, but it seems worthwhile to leave
this action on the agenda for another meeting to check for a response
from the commentor.</em></li>

<li><b>section 2.2 - what does it mean to 'take on meaning'</b> DC
attempted to satisfy the commentor without changes to webarch, but no
reply has come; DanC suggests that it's reasonable to take silence as
assent in this case, accepting a risk that the commentor will object
at some later point.</li>

<li><b><a
href="http://www.w3.org/mid/0I43008JYYDMD0@mailsj-v1.corp.adobe.com">Use
of "assign" for URI -> resource</a></b> <p>RF found the suggestion to excise "URI owner" helpful, but several others preferred the current text that
explains that 'URI ownership' regards the relationship between URIs
and resources; we <strong class="resolved">RESOLVED: to keep " Constraint: URIs
Identify a Single Resource Assign distinct URIs to distinct
resources." despite the new information from LMM's
comment. <em>RF</em> abstained.</strong>
<strong class="action">ACTION SW: to tell the commenter.</strong>
<strong class="action">ACTION NDW: to fix cross references to "uri allocation" that read "uri assignment"</strong>
</p>

<p>After discussion of other parts of LMM's message, we <strong
class="resolved">RESOLVED: that the TAG uses the term URI ownership
rather than resource ownership because some URIs identify resources
that the URI owner (a.k.a., minter) does not own. For example, when a
URI identifies a physical object that is merely named by the URI
owner.</strong> <strong class="action">ACTION SW: to make this
response to Larry</strong></p>
</li>
</ol>

</div>

<p><em>Then we took a break; remaining comments were discussed later:
<a href="#lc2qa">QA comments</a>, <a href="#lcstatus2">others</a>.</em></p>


<div>
<h3 id="infores">Information Resources, Web Resources and httpRange-14</h3>

<p>A number of comments on the 2nd (16 Aug) LC webarch draft motivated
further discussion of issue <a
href="http://www.w3.org/2001/tag/ilist#httpRange-14">httpRange-14</a>:</p>

<ul>
  <li><a
    href="http://lists.w3.org/Archives/Public/www-tag/2004Sep/0000.html">Patrick
    Stricker's comment</a> and resulting <a
    href="http://lists.w3.org/Archives/Public/www-tag/2004Sep/thread.html#0">thread</a>
    on "information resource".</li>
  <li><a
    href="http://lists.w3.org/Archives/Public/public-webarch-comments/2004JulSep/0057.html">Sandro
    Hawke's proposed alternate text</a> and <a
    href="http://lists.w3.org/Archives/Public/www-tag/2004Sep/thread.html#59">www-tag
    thread</a>.</li>
  <li><a
    href="http://lists.w3.org/Archives/Public/public-webarch-comments/2004JulSep/0086.html">Stuart's
    web resource proposal</a> (and <a
    href="http://lists.w3.org/Archives/Public/www-tag/2004Sep/0151.html">revised</a>)
    and <a
    href="http://lists.w3.org/Archives/Public/www-tag/2004Sep/thread.html#132">www-tag
    thread</a>.</li>
  <li>For background: <a
    href="http://lists.w3.org/Archives/Public/www-tag/2004Sep/0111.html">Harry
    Halpin/Henry Thompson on "Web Proper Names"</a>.
    <p>Also, discussion of same on <a
    href="http://lists.w3.org/Archives/Public/www-rdf-interest/2004Sep/thread.html#120">www-rdf-interest@w3.org</a>.</p>
  </li>
</ul>

<p>Each participant was invited to give some remarks on the issue:</p>

<ul>
<li>DanC said while he still finds the LC text acceptable, the fact
that it doesn't distinguish between the position that some dogs are
information resources (expressed by Stickler, among others) and the
position that no dogs are information resources (expressed by TimBL,
among others) shows that it's not very useful.</li>

<li>RF said that what we have currently is sufficiently vague that it
doesn't have anything architecturally meaningful to say. Stickler's
comment was: if that's what you want to say then why not call it a web
resource. RF noted that Sandro agreed that what was in the webarch [as
of the 16Aug LC draft] did not actually define information resource as
intended, and thus his proposal was to add meat to that definition and
that his proposal was discussed on the mailing lists with very little
support from others in evidence. RF expressed a preference for
Stickler's proposal.
</li>

<li>NM said that it's not clear that the distinction is crisp enough
to be of benefit to readers, but that he didn't have a well-informed
opinion about what answer is right.</li>

<li>SW said that the 'information resource' distinction was introduced
in response to some comments [on the Dec 2003 LC draft] and seems to
have helped.  WS noted a possibly related bit from a conversation
with Larry about ownership: there's need for implicit or explicit
indirection between URIs that are web-page like and URIs that are
real-world or conceptual artifacts; with respect to httpRange-14, one
direction is to use the hash for indirection; the Dublin Core folks
seem to use http redirection, which seems interesting.

<p>SW said that in making the web resource proposal, he got Stickler
to agree that there's nothing in the document that he takes exception
to; his concern is that people will read an implicit resolution into
the httpRange-14 issue in the use of "information resource"; if we're
going to resolve it, we should do so more explicitly.</p>
</li>

<li>Chris said his position was expressed in a <a
href="http://lists.w3.org/Archives/Public/www-tag/2004Sep/0137.html">message
</a>
in the thread where Stuart proposed and Jacek seconded to change info
resource to web resource:

<blockquote>
    It can be
    determined whether a given resource is a Web Resource or not. It exposes
    an electronic protocol (such as, for example, HTTP) and it can be
    interacted with. It need not return a representation (it might refuse
    to, or it might say there are no acceptable representations, etc) but
    again, this is all testable technical specification.
    It was not possible to determine whether a resource was an information
    resource. By the very fact of someone referring to it, all resources
    have at least one bit of information (the 'alleged to exist' bit).
</blockquote>

<p><em>in IRC, CL noted an <a
href="http://www.strangehorizons.com/2004/20040405/badger.shtml">example
of confusion re web resources and not web resources</a> ;-)</em></p>
</li>

<li>PC concurred with CL because it answers the question of what is on
the web: is it my intention that makes it so, or is it that it's up a
lot, or does it come and go with the server? He went on to note with
regret that the we're likely to have outstanding dissent regardless of
what we decide, and that this issue is the biggest risk in any plans
to get webarch to REC in 2004.</li>

<li>NDW expressed support for the web resource proposal and
willingness to incorporate it into the webarch draft. He went on to
say that we say you should give URIs to important resources; people
have given them to dogs, and that he has yet to see a useful
distinction between web resources and other resources, though it was
not something he feels strongly about.</li>

<li>TBL said that this is an issue he feels strongly about, though he
has sometimes been a minority of one on the TAG. He explained:

<p>The recent webarch drafts don't make the philosophical distinction
about whether the URI refers to the dog or a picture of the dog; these
drafts have been supported by a community of people who have
experience with the widely deployed web technology where the
distinction is rarely evident, so they don't see the pain. But we're
building the SemWeb architecture on top of the Web architecture, and
in the semantic web, confusing the dog with the picture of the dog is
a serious error. Then we have people like Dublin Core using a URI
without a hash to identify the concept of a title of a book; they
haven't worried about the fact that it's a kind of URI that they would
also use for a web page; since they haven't recursively applied
semantic web technology rigorously to web pages, they don't see the
pain either.</p>

<p>He said he sees only one consistent architecture that isn't in
several layers: the thing up to the hash is a document and the stuff
after the hash gives you a global identifier for something that the
document talks about. This conflicts with existing practice in Dublin
Core, FOAF, and other grass roots ontologies; to pursue this
architecture would be to ask them to stop and please put in a
hash. There are a lot of FOAF documents out there and it would be
painful to put in a hash, but there are a lot more web pages out there
and this seems to be the price of a consistent architecture.</p>
</li>
</ul>

<p>When asked to demonstrate the inconsistency, TimBL said the <a
href="http://www.w3.org/2004/ontaria/">Ontaria</a> service/project is
making progress toward making the issues clear.</p>

<p>RF observed ambiguity in, for example, the first example in the RDF
Primer, which provides a URI for a "web page" and whether, in the case
of a page including images, that actually refers to the collection of
resources that are combined to make the page or to the HTTP interface
to that web server for only the initial request, or something else? He
suggested that the existing architecture has a variety of
interpretations for a URI: when using a URI to make a request, that
only refers to the initial response that you get back; in other cases
it's identifying the HTML page.  He suggested the use of additional
assertions should be used in case it's necessary to determine which is
meant. TimBL said that there's a particular identification
relationship in web architecture, and it's not the relationship
between a URI and an HTML representation, but rather between a URI and
the resource which the HTML document represents.</p>

<p>In the case of a web page consisting of HTML and images, TimBL said
the images are part of the web page resource; that the image tag is
just a shorthand for having the pixels in the HTML file. RF noted that
the HTTP specification doesn't say these things are part of the
relevant resource.  NM noted that if we take the URI to refer to the
composed page, that raises questions about what it would mean to
delete it or manipulate it.  RF suggested the URI refers to the
application steady state that you get after you interpret the
representation. TimBL suggested the resource is an information bearing
object, and that webarch must say what information it contains: the
image is part of the resource and the message conveyed does include
the picture.</p>

<p>CL gave an example of URI that, when dereferenced, returns a
frameset that contains a single HTML page and pointed out that from a
web architecture perspective, the single page and the framed page are
different; though people will use the URI in the same way, to use the
URI for the HTML page and for the collection of things is a URI
collision.  TBL responded that no, none of the URIs in the example
refers to the bits of the representation. <em>It's not clear that
TimBL understood Chris at this point.</em></p>

<p><em>TBL began to relate this to issues with XInclude, which seems
to fit into the architecture at a lower level, but line of discussion
turned out to be not particularly relevant.</em></p>

<p>RF explored the question of the last modified date of such compound
documents, suggesting that using the steady state model avoids
problems with considering all the images, stylesheets etc. in the
answer.  NM suggested that in the case of a composed page, a URI for
each of the components is evident, but the composition is a separate
resource which may or may not be clearly named.</p>

<p>RF claimed that ambiguity about what a URI refers to doesn't break
the Semantic Web. TBL stipulated that the core logic of the Semantic
Web is agnostic to many of these issues, but gave an example of one
party using a URI (without a hash) to refer to something that has such
a birthday, and someone else says it has a copyright, and someone else
says that things that have birthdays don't have copyrights; this is
the sort of conflict that webarch should take a side on.</p>

<p><em>Discussion continued, including topics such as ambiguity,
genericity etc.</em></p>


<p>DanC suggested <a
href="http://esw.w3.org/topic/HashSlashDuality">HashSlashDuality</a>,
whose opening statement is "In both sides of the HashVsSlash debate,
the choice of GoodURIs either obscures a document section or an RDF
Property." <em>Discussion of whether to use this in the webarch
document or perhaps a finding was inconclusive at this point, but
continued later.</em></p>

<p>The group considered the <a
href="http://lists.w3.org/Archives/Public/public-webarch-comments/2004JulSep/0057.html">definition
of information resource offered by Sandro</a> briefly.</p>

</div>

<p><em>At this point, we recessed for the evening.  Discussion on this
issue continued Weds AM after <a href="#tagac">AC report for
TAG</a>.</em></p>

<div>

<h3 id="infores2">Information Resources, Web Resources and
httpRange-14 (II)</h3>


<p>DanC led a discussion around a list of proposals, asking which one
proposal each person preferred and which proposals, if any, each
person would object to:</p>

<ol>
<li><a href="http://www.w3.org/2001/tag/2004/webarch-20040816/#information-resource">current (28Sep) section 3.1</a></li>

<li>
<a
    href="http://lists.w3.org/Archives/Public/public-webarch-comments/2004JulSep/0086.html">Stuart's
    'web resource' proposal</a>
</li>
<li>
<a
    href="http://lists.w3.org/Archives/Public/public-webarch-comments/2004JulSep/0057.html">Sandro
    Hawke's elaborated definition of information resource</a>
</li>
<li>
<a
href="http://esw.w3.org/topic/HashSlashDuality">HashSlashDuality</a>
</li>
</ol>

<p>When asked if the proposals should be judged
on whether they resolve the whole of HTTPRange-14, DanC said no, the
target was addressing the outstanding last call comments, though
closing the whole issue would be nice.</p>

<p>RF clarified that the objectionable part of Sandro's proposal was after the 1st paragraph; the part that says 1 is not an information resource, etc.</p>

<p>NM expressed a concern that to use the term 'web resource' for the
set constrained to have representations or be network-accessible or
anything like that overly constrains Web Architecture.</p>

<p>A fifth option emerged from the
discussion: s/information resource/resource/ and remove section 3.1 (ish).
Stuart suggested that RF's 5th option is responsive to comments
from Hayes, e.g. "does anything apply to non Information resources?"</p>

<p>TBL suggests that what he means by 'information resource' is a
concept that predates the Web and is not necessarily connected to
availability on the Web. Norm and Chris observed that
the concept did not seem sufficiently well-defined, testable, nor operational.
TBL suggested that there's something fundamentally different
between a table and a textual work such as the bible.
NM suggested that Claude Shannon's work on information theory
might provide a suitable definition; TBL agreed that yes, that's
the sense in which he's using 'information'. Chris found:</p>

<blockquote>
    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 important impact has occurred.

    <address>
      <a href="http://www.comp.nus.edu.sg/~yuenck/ccst01/notes17">notes on Shannon's work</a>
    </address>
</blockquote>

<p>CL suggested that this supports RF's argument that surrounding
context should be used to disambiguate what URIs identify, since
surrounding context serves to provide redundancy. NM clarified that he
wasn't referring to lossy channels or redundancy when he suggested
that information theory could help us; he was pretty sure that Shannon
gives a definition of something like "pure information" that is
essentially what you are <em>trying</em> to communicate through the
channel. He said that by analogy, we need not have redundancy in a
temperature value or the words in a poem to say that they are
"information"; we may need redundancy to communicate them with some
predictable probability of success through a noisy channel; HTTP needs
redundancy on the wire, but the "information resource" definition as
information does not involve redundancy.
</p>

<p>Dan suggested that a a textual work can be consumed over the web in
a way that a table cannot; if you see a table and a movie in a product
catalog, while you can learn about the table using HTTP, you can never
consume it to the point where you owe the vendor the price in the
catalog, while with information resources, you can consume them to the
point where you owe the price just by observing representations.</p>

<p>RF argued that definitions of information resource that interact
with URI syntax contradict the principle of URI opacity. TBL countered
that URI opacity only says not to make unlicensed inferences, but this
inference is licensed by the HTTP specification. RF did not agree.</p>

<p>The last straw poll of the session showed:</p>

<ol>
<li><blockquote>
The term Information Resource refers to resources that convey information. Any resource that has a representation is an information resource. A representation consists logically of two parts: data (expressed in one or more formats (Â§4) used separately or in combination) and metadata (such as the Internet media type (Â§3.3) of the data). ...
<address>
<a href="http://www.w3.org/2001/tag/2004/webarch-20040816/#information-resource">current (28Sep) section 3.1</a>


</address>
</blockquote>

<dl><dt>Pref:</dt><dd>TBL, NM</dd>
<dt>Object:</dt><dd>PC, CL</dd>
</dl>
</li>

<li>
<blockquote>
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. Any resource that has a web
accessible  representation is an web resource ...
<address>
<a
    href="http://lists.w3.org/Archives/Public/public-webarch-comments/2004JulSep/0086.html">Stuart's
    web resource proposal</a>
</address>
</blockquote>

<dl><dt>Pref:</dt>
<dt>Object</dt><dd>TBL, NM</dd>
</dl>

</li>
<li>
<blockquote>
 An "Information Resource" is a collection of information
   potentially transmittable via a computer network.  Digital forms of
   creative works (such as documents and images) are Information
   Resources, while certain conceptual entities (such as numbers and
   RDF properties) are not.  This distinction is becoming useful as
   people develop ways to use URIs to identify things which are not
   Information Resources.
   <p>...</p>
<address>
<a
    href="http://lists.w3.org/Archives/Public/public-webarch-comments/2004JulSep/0057.html">Sandro
    Hawke's proposed alternate text</a>
</address>
</blockquote>
<dl>
<dt>Pref:</dt>

<dt>Object:</dt><dd> NDW, CL, RF, PC</dd>
</dl>
</li>
<li>
<blockquote>
In both sides of the HashVsSlash debate, the choice of GoodURIs either obscures a document section or an RDF Property. ...
<address>
<a
href="http://esw.w3.org/topic/HashSlashDuality">HashSlashDuality</a>
</address>
</blockquote>

<dl><dt>Pref:</dt><dd>PC, CL, SKW, DC</dd>
<dt>Object:</dt>
</dl>
</li>

<li>s/information resource/resource/ and remove section 3.1 (ish)
<dl>
<dt>Pref:</dt><dd>RF, NDW</dd>
<dt>Object:</dt><dd>TBL</dd>
</dl>
</li>
</ol>

<p>Dan noted that as only option 4 had no objections, W3C process
suggests it should be pursued. At Noah's suggestion, we explored some
variations on the proposals and combinations of them, without
conclusion. The editor was encouraged to prepare something for discussion
later in the meeting.</p>

</div>

<p><em>Then we went to lunch.</em></p>

<div><h3 id="lc2qa">Outstanding comments from the Quality Assurance
Working Group</h3>

<p><em>based on <a
href="http://www.w3.org/2004/10/06-tagmem-irc#T12-05-25">IRC log
starting at 12:05:25Z, TimBL serving as scribe</a></em></p>

<p>SW noted that our <a href="http://lists.w3.org/Archives/Public/www-tag/2004Sep/att-0170/minutes.html#item04">27 Sep discussion with the QA WG</a> about <a
href="http://www.w3.org/mid/1095351501.2955.11.camel@stratustier">their
comments</a> was inconclusive.</p>

<p>Though many supported the elaboration on the trade-offs around
extensibility and versioning in <a
href="http://www.w3.org/2001/tag/2004/webarch-20040928/Overview.html#ext-version">section
4.2 of the 28 Sep webarch draft</a>, there were mixed opinions on
whether the boxed notes communicated good/best practices
effectively. DanC noted a <a
href="http://lists.w3.org/Archives/Public/public-webarch-comments/2004OctDec/0002.html">message
from Dom</a> to the effect that the QA WG was reviewing the 28 Sep
text and would tell us Monday if it satisfies them.</p>

<p>The participants were sympathetic to the QA WG's point that for
some designs, no extensibility is best; PC checked to see if the <a
href="http://www.w3.org/2001/tag/doc/versioning-20031003">draft
finding on extensibility and versioning</a> reflected this and
discovered that it does not. PC asked if the risk that decisions made
here would affect the finding was acceptable; several said yes, they
don't mind if the finding needs to change as a result of decisions
made today. Eventually, we <strong class="resolved">RESOLVED: to add
another para of explanation in section 4.2.3. Extensibility that says
more bluntly that there are trade-offs here should be added, editor
salting to taste, and to leave the good practice note boxes,
<em>SKW</em>, <em>RF</em>, <em>DC</em>, <em>NM</em>
abstaining.</strong> After review of other points made by the QA WG,
we <strong class="resolved">RESOLVED: Make that change "the long term
benefits of a +well-designed+ extensibility mechanism...."</strong>.
NDW said he has already added some and will add more references to the
QA work to address their comments. <strong class="action">ACTION NDW:
add "for more info, see also" link to <a
href="http://www.w3.org/TR/2004/WD-qaframe-spec-20040830/#extensions">a
section of a QA spec</a> to 4.x</strong>.  <strong
class="action">ACTION DC: Report back to QA on our disposition of <a
href="http://www.w3.org/mid/1095351501.2955.11.camel@stratustier">their
comments</a>.</strong></p>

<p>PC asked could the QAWG please review the draft finding? NW
acknowledged that David Orchard is doing most of the technical work on
the finding.  <strong class="action">ACTION PC: solicit QA WG review
of draft extensibility/versioning finding</strong></p>

</div>

<div><h3 id="lcstatus2">WebArch LC#2 Comments (II)</h3>

<p><em>based on <a href="http://www.w3.org/2004/10/06-tagmem-irc#T13-46-59">IRC notes starting 13:46:59Z by RF et. al.</a></em></p>

<ol start="12">
  <li><b><a href="http://www.w3.org/mid/20040920110533.JVAV9978.mta13.adelphia.net@mail.adelphia.net">Cyberspace analogous to set of all sets: URIs &amp; URLs</a></b> DC found few specific suggestions in this comment; he responded, asking if the commentor could be more specific.</li>
<li><b><a
href="http://www.w3.org/mid/1095782045.2943.125.camel@Kalb">Representation
of a secondary resource?</a></b> We reviewed the primary/secondary
terminology in <a
href="http://www.w3.org/2001/tag/2004/webarch-20040928/Overview.html#media-type-fragid">section
3.3.1</a>, and noted a related comment, <a
href="http://lists.w3.org/Archives/Public/public-webarch-comments/2004OctDec/0003.html">Late
last-call comment on AWWW</a> Graham Klyne (Tuesday, 5 October). We
discussed ways to clarify that primary/secondary is a relationship
between resources, not disjoint sets of resources: replacing the
terms, getting rid of them, diagrams (ala <a
href="http://www.w3.org/DesignIssues/Model">a design note</a>),
etc. RF noted the terms are defined in the URI specification. DC
pointed out an error in the second bullet... "One cannot carry out
.."; this is not true because it assumes that secondary resource is a
class. ACTION NDW: draft for section 3.3.1 to clarify
primary/secondary (<em>done in <a href="#lc345">later comment review
session</a></em>).
</li>

<li><b>web faster</b> spam. <strong class="action">ACTION DC: make sure "web faster" doesn't bother the chair next time he's doing an agenda</strong></li>
<li><b>KD002</b> <a href="http://lists.w3.org/Archives/Public/public-webarch-comments/2004JulSep/0126.html">Karl's clarification</a> DC said Karl seems to be asking that we say that all Web standards are just as important as the URI standard; he disagreed, noting that URIs have a distinguished place in Web architecture; he noted a comment from Klyne asking that we state the special role of URIs more strongly, and some recent text to that effect:

<blockquote>To achieve this goal, the Web makes use of a single global identification system: the URI. URIs are a cornerstone of Web architecture, providing identification that is common across the Web.
</blockquote>

<p>NM concurred, noting URIs are the one thing that can't be replaced without fundamentally departing from the Web architecture.
<strong class="action">ACTION DC: point out new "URIs are central to web arch" text in reply to Karl, ask if that satisfies</strong>
</p>
</li>

<li><b>[Tim Bray] Review of webarch-20040816</b> NW reviewed Bray's
comments, noting which he had incorporated and which he had
declined. There was considerable support for Bray's comment
regarding section 4.6; we <strong class="resolved">RESOLVED: to change
4.6 from "Because of their role in defining fragment identifier
semantics, data" to "Data", <em>DC</em> abstaining.</strong> Since
"future directions" appears in the section headings of similar
sections for identification and interaction, we
<strong class="resolved">RESOLVED: change title of 4.6 to "Future Directions for Data Formats"</strong>
</li>

<li><b>KD-001 [was: Comments on Web Arch WD - 2004-07-05]</b> has since been closed; the status report will be updated to show this presently.</li>

<li><b>KD 004 [was: Comments on Web Arch WD - 2004-07-05]</b> Further
<a
href="http://lists.w3.org/Archives/Public/public-webarch-comments/2004JulSep/0128.html">clarification
from KD</a> prompted discussion of section 2.4 URI Overloading. DC
suggested using an example of an example document vs. a DTD, where the
problem would be evident to software. CL and RF noted the comment
seemed to be asking whether, since every URI identify a single thing,
are web pages that talk about multiple things? CL suggested answering
"no, web pages that talk about multiple things are
fine (but give each thing an anchor so it can be separately
referenced)" which was generally supported.
<strong class="action">ACTION CL: respond to Karl regarding KD004</strong>
</li>

<li><b>Some Phone Links</b> spam.</li>
<li><b>Bookmarks02</b> spam.</li>
</ol>

<p>PC asked if there were more recent comments. DC noted that the
deadline has passed; while TAG members are welcome to request
discussion of late comments, we have less and less obligation to do so
as time goes by. PC noted the status report seems to be missing <a
href="http://lists.w3.org/Archives/Public/public-webarch-comments/2004JulSep/0133.html">the
29 Sep comment from the HTML WG</a>; DC said that looked like a bug
and he'd investigate.</p>

</div>

<div><h3 id="htxl">XLink-23, comments from HTML WG</h3>

<p><em>based on <a
href="http://www.w3.org/2004/10/06-tagmem-irc#T15-13-33">IRC notes
starting 15:13:33Z</a></em></p>

<p>The <a
href="http://lists.w3.org/Archives/Public/public-webarch-comments/2004JulSep/0133.html">the
29 Sep comment from the HTML WG</a> prompted discussion of issue <a
href="http://www.w3.org/2001/tag/issues.html?type=1#xlinkScope-23">xlinkScope-23</a>. The
discussion started with process/social issues; PC and others noted
that the linking task force has made little progress in the last seven
months; TBL noted several cases of one group not re-using the work of
another. CL noted some technical obstacles to reuse, noting that
designing for reuse intentionally is important. We noted that the SVG
WG chose to use XLink, but the SMILE and HTML WG and perhaps MathML
WGs did not. We noted that <a
href="http://www.w3.org/TR/hlink/">hlink</a> has not been updated in
quite some time, nor has it been integrated into XHTML 2.0; the <a
href="http://www.w3.org/TR/2004/WD-xhtml2-20040722/mod-hypertext.html#s_hypertextmodule">hypertext
module</a> does not use hlink.  After discussion of various textual
changes we <strong class="resolved">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. to section 4.5.2. Links in
XML</strong> <strong class="action">ACTION SW: ask the HTML WG if the
qualification we made regarding XLink satisfies their
comments.</strong></p>

</div>

<p><em>Then we broke for the day.</em></p>

<div>
<h3 id="extvers">Planning work on extensibility and versioning</h3>

<p><em>based on <a href="http://www.w3.org/2004/10/07-tagmem-irc#T09-01-43">IRC notes starting 09:01:43Z</a></em></p>

<p>PC asked for a plan for work on extensibility and versioning (<a
href="http://www.w3.org/2001/tag/issues.html?type=1#XMLVersioning-41">XMLVersioning-41</a>). DC
said he'd like to see a shorter (5 page?) finding. NDW said that he's
busy in Nov, so a finding in Oct would suit him better; he said that
Dave Orchard is doing the "heavy lifting". NDW also encouraged dialog
with the XML Schema WG. NM said he participates in the XML Schema WG,
so we now have a direct connection; his <a
href="http://lists.w3.org/Archives/Public/www-tag/2004Aug/0010.html">message
of 6aug to www-tag</a> is relevant. <strong class="action">ACTION
NDW: to report workplan and dates for Extensibilty and Versioning
work.</strong></p>
</div>

<div><h3 id="lc345">Responses from Last Call commenters</h3>

<p><em>based on <a
href="http://www.w3.org/2004/10/07-tagmem-irc#T09-08-33">IRC notes
from 09:08:33 to 09:50:59</a></em></p>

<ol start="16">
<li><b>[Tim Bray] Review of webarch-20040816</b> NDW led discussion of
<a
href="http://lists.w3.org/Archives/Member/tag/2004Oct/0019.html">further
input from Bray</a>. NDW is inclined to fix "If rep communicates the
state of the resource inaccurately, this inaccuracy or ambiguity may
lead to URI collision" in 3.2.1. Regarding "exceptional circumstances" NDW is inclined to add a clarifying example.
There was little support for Bray's suggestion to remove XML
Schemas from the list of acceptable representations of namespace
documents.</li>
</ol>
<ol start="13">
<li><b><a href="http://www.w3.org/mid/1095782045.2943.125.camel@Kalb">Representation of a secondary resource?</a></b> After further discussion of how to clarify,
we <strong class="resolved">RESOLVED to clarify ala: "The terms ?primary? and
?secondary? in this context do not limit the nature of the
resource?they are not classes. In this context, primary and secondary
simply indicate that there is a relationship between the resources for
the purposes of one URI: a URI with a fragment identifier. Any
resource can be identified as a secondary resource. It might also be
identified using a URI without a fragment identifier, and a resource
may be identified as a secondary resource via multiple URIs. The
purpose of these terms is to enable discussion of the relationship
between such resources, not to limit the nature of a resource." with
some discretion to the editor regarding pronoun references.
</strong> <strong class="action">ACTION DC: to reply to commenter re primary and secondary resources.</strong>
</li>
</ol>

</div>

<div><h3 id="HTTPSubstrate-16">HTTPSubstrate-16</h3>

<p><em>based on <a
href="http://www.w3.org/2004/10/07-tagmem-irc#T09-51-33">IRC notes
starting 09:51:33Z</a></em></p>

<p>DanC noted an upcoming W3C/IETF liaison meeting 14 Oct. After some
discussion of the history and status of issue <a
href="http://www.w3.org/2001/tag/issues.html?type=1#HTTPSubstrate-16">HTTPSubstrate-16</a>,
<strong class="action">ACTION DC: recruit someone to write a
counterpoint to RFC3205 CONTINUES</strong>.</p>

</div>

<div><h3 id="infores234">Information Resources, httpRange-14 (Thu)</h3>

<p><em>based on <a
href="http://www.w3.org/2004/10/07-tagmem-irc#T07-36-08">IRC notes
starting 07:36:08Z</a>, continuing with <a
href="http://www.w3.org/2004/10/07-tagmem-irc#T12-48-09">notes
starting 12:48:09Z</a></em></p>

<p>NW introduced <a
href="http://www.w3.org/2001/tag/2004/webarch-20040928/Infosrc-rewrite.html#information-resource">a
rewrite of section 3.1. Information Resources and Representations</a>
for discussion. While it addressed CL's objection, RF and DC found it
had insufficient motivation.</p>

<p><em>We then went on to discuss <a href="#extvers">extensibility and
versioning</a>, and came back to this topic after other agenda were
done.</em></p>

<p>In discussion of rationale for the "information resource"
distinction, TBL and CL pointed out that all the material on
representations and much of the material on interactions applies
mostly to information resources and suggested that the term is useful
to contrast "resource", the top/unconstrained class, with the class
that's like documents/files in many discussions. NDW proposed:</p>

<blockquote>
<p>By design a URI identifies one resource. We do not limit the scope of what might be a resource. The term "resource" is used in a general sense for whatever might be identified by a URI. It is conventional on the hypertext web to describe web pages, images, product catalogs, etc. as ?resources?. The distinguishing characteristic of these resources is that all of their essential characteristics can be conveyed in a message. We identify this set as ?information resources?.
</p>
<p>This document is an example of an information resource. It consists of words and punctuation symbols and graphics and other artifacts that can be encoded, with varying degrees of fidelity, into a sequence of bits. There is nothing about the essential information content of this document that cannot in principle be transfered in a representation.</p>
<p>
 However, our use of the term resource is intentionally more broad. Other things, such as cars and dogs (and, if you?ve printed this document on physical sheets of paper, the artifact that you are holding in your hand), are resources too. They are not information resources, however, because their essence is not information. Although it is possible to describe a great many things about a car or a dog in a sequence of bits, the sum of those things will invariably
    be an approximation of the essential character of the resource.
</p>
<p>
    We define the term ?information resource? because we observe that it is useful in discussions of web technology and may be useful in constructing specifications for facilities built for use on the web.</p>
</blockquote>

<p><strong class="resolved">RESOLVED: to replace section 3.1 Information
Resources with an updated to section 2.2 as above, "... We identify
this set as ?information resources?. ..."</strong> <strong
class="action">ACTION SW: to respond to Pat Hayes, Patrick Stickler
and Sandro Hawke giving proposed resolution of Information
Resource</strong>. NDW suggested that the HashSlashDuality text
was no longer worthwhile, and we <strong class="resolved">RESOLVED: to
drop the HashSlashDuality text (section 2.2.1 and descendants in a
draft that was projected) and use as input to finding on HTTPrange-14,
<em>DC</em>, <em>TBL</em> abstaining.</strong> <strong
class="action">ACTION DC: with Norm, develop a finding on httpRange-14
starting with the HashSlashDuality text</strong></p>

</div>

<div><h3 id="plan234">Schedule for webarch end-game</h3>

<p><em>based on <a
href="http://www.w3.org/2004/10/07-tagmem-irc#T14-57-55">IRC notes
starting 14:57:55Z</a></em></p>


<p>After some discussion of publication mechanics, we drafted
the following plan:</p>

<dl><dt>18 Oct</dt>
<dd>NW to provide Editor's Draft<br />
    NM to provide branch (NM at risk)<br />
    DC to produce PR request (at risk)<br />
</dd>
<dt>
    25 Oct</dt>
<dd>
    Decide to go to PR</dd>
<dt>    01 Nov</dt>
<dd>    Director's Decision telcon
<p>
    Would like to be there: CL, SW, TBL</p>
</dd>
<dt>    05 Nov</dt>
<dd>    i's dotted, t's crossed<br />
    Publication as a PR draft<br />
    Call for testimonials
</dd>
<dt>    18 Nov - 06 Dec</dt>
<dd>
    Blackout</dd>
<dt>08 Dec</dt>
<dd>
    AC Reviews due (05 Nov plus four weeks and a few days)<br />
    Testimonials due</dd>
<dt>
    13 Dec</dt>
<dd>
    i's dotted, t's crossed</dd>
<dt>14 Dec</dt>
<dd>REC published<br />
    Press release</dd>
<dt>    25 Dec</dt>
<dd>DC dines on PC's nickle. ;-)</dd>
</dl>

<p><strong class="action">ACTION NDW: to produce an editor's draft by
14 Oct (COB EDT)</strong>. <strong class="action">ACTION DC: draft a
request for proposed recommendation, based on Norm's draft</strong>
<strong class="action">ACTION CL: to cause draft of press release to
happen</strong>
</p>

<p>RF asked what the Nov meeting in Boston would be about, if we
proceed according to this plan; thinking about the next edition of the
Architecture document was the response given by several.</p>

</div>

<div><h3 id="txhost">Adjournment, thanks to the host</h3>

<p><strong class="resolved">RESOLVED: The TAG thanks Day Software for
a terrific job of hosting our meeting, and for supporting Roy
Fielding's participation in the TAG.  Special thanks to Jean-Michel
Pittet for his contributions to the <a href="#where">hosting
arrangements</a>.</strong></p>

</div>

</div>


<div><h2 id="chlog">TODO list and Change Log</h2>

<p>In addition to getting this record reviewed by the participants, I
plan to:</p>

<ul>
<li>formally connect LC comments to relevant actions and minutes; integrate into <a href="http://www.w3.org/2001/tag/2004lc/lc-status-report.html">status report</a></li>
<li>formally connect issues to actions (and decisions?); think about how to integrate into
<a
href="http://www.w3.org/2001/tag/ilist">issues list</a>
</li>
</ul>

<p>And I hope to:</p>
<ul>
<li>distinguish "awaiting reply from commentor" from other states in last call comment tracking</li>
<li>note (formally) the lat/long of the meeting place, or at least the nearby airport/train station</li>
<li>photo metadata: foaf:depicts, lat/long</li>
<li>sign the record? include the pgp fingerprints that were exchanged as part of the record?</li>
</ul>

<p>These are the changes v1.12 of 2004/09/30 14:27:15, sent in an <a
href="http://lists.w3.org/Archives/Public/www-tag/2004Sep/0184.html">agenda
announcement</a>:</p>

<pre><!-- lot starts on next line -->
$Log: 05-07-tag.html,v $
Revision 1.38  2004/10/18 21:35:08  connolly
minutes are no longer DRAFT

Revision 1.37  2004/10/14 03:13:18  connolly
markup fix

Revision 1.36  2004/10/14 03:12:36  connolly
- NDW's action re 3.3.1 was done during the meeting
- moved "then we broke for lunch" notes outside topic divs
- spell-check

Revision 1.35  2004/10/11 16:59:26  connolly
- input from SW re meeting planning
- typos, missing "RESOLVED", spurious para break

Revision 1.34  2004/10/11 16:30:41  connolly
fix month in title

Revision 1.33  2004/10/11 15:55:42  connolly
added link to GRDDL output

Revision 1.32  2004/10/11 15:52:43  connolly
- summarized last httpRange item, planning item
- summarized httpSubstrate
- summarized adjournment, thanks to the host
- normalized some topic headings, finished agenda section
- added some links where the minutes go out of time order
- folded one of the httpRange sessions into the last one
- moved my TODO items into the changelog section
- finished scribe list

Revision 1.31  2004/10/11 14:48:09  connolly
HTTPsubstrate-16 discussion

Revision 1.30  2004/10/11 14:44:29  connolly
another lc comment session; hmm... merge them together?

Revision 1.29  2004/10/11 14:30:10  connolly
- item: Planning work on extensibility and versioning

Revision 1.28  2004/10/10 18:49:51  connolly
- another infores session
- started on extvers item

Revision 1.27  2004/10/10 13:06:45  connolly
- added grddl profile, transformation link

Revision 1.26  2004/10/10 12:58:13  connolly
summarized xlinkScope-23/HTML WG item

Revision 1.25  2004/10/10 12:37:14  connolly
- finished "Return to the last call status list" agendum
- fixed roll call markup
- fixed abstention markup
- started on xlinkScope-23 discussion

Revision 1.24  2004/10/09 20:36:16  connolly
- summarized item on QA WG lc comments
- normalized some aka's
- tx Jean-Michel

Revision 1.23  2004/10/09 19:27:04  connolly
group photo

Revision 1.22  2004/10/09 13:28:08  connolly
- started working on QA comment session, TBL scribing
- added some pointers from topics to spefic parts of the IRC log

Revision 1.21  2004/10/09 13:05:54  connolly
- summarized the session DanC led on httpRange-14 options
- link attendance info to list on TAG home page
- note xlink23 in agenda
- move some links re W3C@10, AC meeting
- link to WBS from TBL's comments
- figured out which msg CL was using as his opening position on httpRage-14

Revision 1.20  2004/10/09 00:18:21  connolly
connected changelog to agenda announcement

Revision 1.19  2004/10/08 22:57:16  connolly
lots more summarized; started GRDDLing

Revision 1.18  2004/10/08 00:51:35  connolly
- fix heading levels in minutes
- use CSS to clarify nesting of topics in the minutes
- use class markup for decisions/actions, mix with css
- fun with CSS for blockquote

Revision 1.17  2004/10/08 00:19:42  connolly
summarized thru 14:04:17Z break after 1st pass thru LC2 comments

Revision 1.16  2004/10/07 23:36:43  connolly
summarized thru lunch on Tue: DanC's review of webarch

Revision 1.15  2004/10/07 22:00:40  connolly
summarized to 08:44:36Z morning break

revision 1.14
date: 2004/10/07 20:56:47;  author: connolly;  state: Exp;  lines: +43 -24
organizing the meeting page as minutes as well as agenda

revision 1.13
date: 2004/10/05 11:03:07;  author: swilliam;  state: Exp;  lines: +2 -2
*** empty log message ***

revision 1.12
date: 2004/09/30 14:27:15;  author: swilliam;  state: Exp;  lines: +2 -2
*** empty log message ***
</pre>
</div>

</body>
</html>