W3C * TAG | Previous: 27 Sep

TAG Meeting, 5-7 October 2004

tag members on the roof in
Baselhosted in Basel, Switzerland by Day Software

on this page: Participants * Venue * Agenda * Minutes
nearby: www-tag archive, irc Tue, Wed, Thu
also: fun with MeetingRecords, GRDDL: groktagftf.xsl, output, Makefile,
photos by NDW: photo1 photo2

The goals of the meeting are:

Preparation materials include:

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

Participants

All current members of the TAG participated in the meeting:

  1. Tim Berners-Lee (TBL)
    arrived later on Tuesday
  2. Dan Connolly (DC)
    arrived later on Tuesday
  3. Paul Cotton (PC)
  4. Roy Fielding (RF)
  5. Chris Lilley (CL)
  6. Noah Mendelsohn (NM)
  7. Norm Walsh (NDW)
  8. Stuart Williams (SW chair)

Venue, Local Arrangements

The meeting is at the Day office in Barfusserplatz, Basel.

Day Software AG
Barfusserplatz 6
4001 Basel
Switzerland
T +41-61-226 98 98
F +41-61-226 98 97
ch.info@day.com

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.

Agenda

  1. Administrative
    1. Convene, take roll, review agenda
    2. Future meeting plans
    3. Review of records
    4. TAG staff support
    5. TAG Charter, patent policy
    6. AC report for TAG
  2. A review of the 28 Sep webarch draft
  3. Representations over-constrained?
  4. WebArch LC#2 Comments
  5. Information Resources, Web Resources and httpRange-14 (I)
  6. Information Resources, Web Resources and httpRange-14 (II)
  7. Outstanding comments from the Quality Assurance Working Group
  8. WebArch LC#2 Comments (II)
  9. xlinkScope-23, comments from HTML WG
  10. Planning work on extensibility and versioning
  11. HTTPSubstrate-16
  12. Information Resources, httpRange-14 (Thu)
  13. Schedule for webarch end-game
  14. Adjournment, thanks to the host

Other items from the proposed agenda were not discussed.

Minutes

Administrative

Convene, take roll, review agenda

SW convened the meeting Tuesday morning at 9am. See attendance above.

SW welcomed Noah to his first TAG ftf meeting. 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."

The group reviewed the proposed agenda, noting that comments on the 2nd (Aug 2004) last call webarch document motivated discussion of issues httpRange-14 and xlink23, and that DanC sent comments 5Oct that include agenda requests.

Future meeting plans

We reviewed the following opportunities to meet in face-to-face:

29th-30th November 2004 Boston, MA, USA
already scheduled.

Note announcements to W3C members regarding W3C@10 and W3C AC Meeting

28th Feb- 4th March 2005 Boston, MA, USA
This is the schedule for the W3C Technical Plenary (per 13 Sep announcement).
10-14th May 2005 Chiba, Japan
WWW2005
6-7 June 2005 Cannes, France
This is the plan for the W3C AC meeting (per 13 Sep announcement)
Summer 2005 in Kanas City
DanC made a tentative offer to host (6 Sep)
October 2005?

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

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.

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 issues 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.

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.

Further discussion of future ftf meetings was postponed until on Weds AM; the meeting continued with a review of the 28Sep editor's draft.

RESOLVED: to meet next 18 Oct and cancel the 11 Oct telcon, TBL abstaining.. NM at risk due to plane flight landing 1 hour before TAG telcon.

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.

We noted that scheduling during the Technical Plenary week depends on various factors outside our control, but based on the information at hand, we 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. 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.

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 RESOLVED: to meet 8-10 June, South of France near Cannes host Chris/ERCIM. 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.

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

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 RESOLVED: to meet 20-22 September, in Kansas City, DanC to host

Review of records

RESOLVED: to accept 27 Sep minutes, amended to show regrets from RF.

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 (output from yesterday's IRC log) and offered to help. ACTION CL: Chris collect IRC logs from last f2f ( cf pointers for assembling meeting minutes of 11 Aug) and turn into minutes.

TAG staff support

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 Role changes, 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.

TimBL reported success with WBS surveys 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. ACTION TBL: to investigate possible staff contact for TAG, due date 20 October 2004

TAG Charter, patent policy

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. ACTION SW: get a timescale from Ian about charter revision and availability. Paul, Stuart, and others expressed their appreciation for the responsiveness of the team to TAG discussion of this topic.

AC report for TAG

Paul volunteered to do the next monthly report and noted that the AC report is cumulative of the previous three reports. ACTION PC: create draft summary for AC, get it to Steve Bratt by Oct 22

Stuart relayed a request for 'hot topics' for the AC meeting. 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.

A review of the 28 Sep webarch draft

based on IRC log starting Tue 09:03:19Z

In preparation for the meeting, DanC sent comments on the 28Sep editor's draft, some of which were flagged for discussion.

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:

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.

The group discussed proper use of RFC2119 keywords, esp

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.

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, ...".

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

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

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.

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

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.

Several concurred with DanC suggested replacement text in 3.3:

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

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

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. Discussion was inconclusive at this point; it continued in discussion of QA comments.

TimBL joined at about 10:33:38Z

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.

Representations over-constrained?

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. 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. later in the meeting, NM agreed to try to do this in preparation for the 18Oct telcon

Then we had lunch.

WebArch LC#2 Comments

based on IRC logs starting 12:23:05Z

We started reviewing the pending comments, viewed thru the status report Revision 1.10 of 2004/10/05 12:21:52.

  1. Request for Review of TAG AWWW 2nd LC Draft. ACTION SW: to review comments from PatH for issues that merit discussion. DONE later in the meeting
  2. Comments on Working Draft 5 July 2004 - URI Overloading is actually spam (based on a comment on an earlier draft)
  3. "information resource" was postponed until discussion of comments regarding httpRange-14
  4. non-authoritative syntaxes for fragment identifiers 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.
  5. postponed till discussion of comments regarding httpRange-14
  6. AWWW, 20040816 release, sections 1 and 2 ACTION NDW: to note this thread [closed] in the archive per msg from gk.
  7. resources/representations [was: random comments on 2nd LC of WebArch] postponed till discussion of comments regarding httpRange-14
  8. too positive on extensibility [was: random comments on 2nd LC of WebArch] NDW suggested recent edits to 4.x are responsive to this comment. ACTION CL: to respond to the commenter for issue 8 pointing to the new draft on extensibility CL sent such a message 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.
  9. section 2.2 - what does it mean to 'take on meaning' 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.
  10. Use of "assign" for URI -> resource

    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 RESOLVED: to keep " Constraint: URIs Identify a Single Resource Assign distinct URIs to distinct resources." despite the new information from LMM's comment. RF abstained. ACTION SW: to tell the commenter. ACTION NDW: to fix cross references to "uri allocation" that read "uri assignment"

    After discussion of other parts of LMM's message, we 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. ACTION SW: to make this response to Larry

Then we took a break; remaining comments were discussed later: QA comments, others.

Information Resources, Web Resources and httpRange-14

A number of comments on the 2nd (16 Aug) LC webarch draft motivated further discussion of issue httpRange-14:

Each participant was invited to give some remarks on the issue:

When asked to demonstrate the inconsistency, TimBL said the Ontaria service/project is making progress toward making the issues clear.

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.

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.

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. It's not clear that TimBL understood Chris at this point.

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.

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.

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.

Discussion continued, including topics such as ambiguity, genericity etc.

DanC suggested HashSlashDuality, whose opening statement is "In both sides of the HashVsSlash debate, the choice of GoodURIs either obscures a document section or an RDF Property." Discussion of whether to use this in the webarch document or perhaps a finding was inconclusive at this point, but continued later.

The group considered the definition of information resource offered by Sandro briefly.

At this point, we recessed for the evening. Discussion on this issue continued Weds AM after AC report for TAG.

Information Resources, Web Resources and httpRange-14 (II)

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:

  1. current (28Sep) section 3.1
  2. Stuart's 'web resource' proposal
  3. Sandro Hawke's elaborated definition of information resource
  4. HashSlashDuality

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.

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.

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.

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

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:

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.
notes on Shannon's work

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 trying 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.

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.

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.

The last straw poll of the session showed:

  1. 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). ...
    current (28Sep) section 3.1
    Pref:
    TBL, NM
    Object:
    PC, CL
  2. 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 ...
    Stuart's web resource proposal
    Pref:
    Object
    TBL, NM
  3. 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.

    ...

    Sandro Hawke's proposed alternate text
    Pref:
    Object:
    NDW, CL, RF, PC
  4. In both sides of the HashVsSlash debate, the choice of GoodURIs either obscures a document section or an RDF Property. ...
    HashSlashDuality
    Pref:
    PC, CL, SKW, DC
    Object:
  5. s/information resource/resource/ and remove section 3.1 (ish)
    Pref:
    RF, NDW
    Object:
    TBL

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.

Then we went to lunch.

Outstanding comments from the Quality Assurance Working Group

based on IRC log starting at 12:05:25Z, TimBL serving as scribe

SW noted that our 27 Sep discussion with the QA WG about their comments was inconclusive.

Though many supported the elaboration on the trade-offs around extensibility and versioning in section 4.2 of the 28 Sep webarch draft, there were mixed opinions on whether the boxed notes communicated good/best practices effectively. DanC noted a message from Dom to the effect that the QA WG was reviewing the 28 Sep text and would tell us Monday if it satisfies them.

The participants were sympathetic to the QA WG's point that for some designs, no extensibility is best; PC checked to see if the draft finding on extensibility and versioning 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 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, SKW, RF, DC, NM abstaining. After review of other points made by the QA WG, we RESOLVED: Make that change "the long term benefits of a +well-designed+ extensibility mechanism....". NDW said he has already added some and will add more references to the QA work to address their comments. ACTION NDW: add "for more info, see also" link to a section of a QA spec to 4.x. ACTION DC: Report back to QA on our disposition of their comments.

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. ACTION PC: solicit QA WG review of draft extensibility/versioning finding

WebArch LC#2 Comments (II)

based on IRC notes starting 13:46:59Z by RF et. al.

  1. Cyberspace analogous to set of all sets: URIs & URLs DC found few specific suggestions in this comment; he responded, asking if the commentor could be more specific.
  2. Representation of a secondary resource? We reviewed the primary/secondary terminology in section 3.3.1, and noted a related comment, Late last-call comment on AWWW 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 design note), 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 (done in later comment review session).
  3. web faster spam. ACTION DC: make sure "web faster" doesn't bother the chair next time he's doing an agenda
  4. KD002 Karl's clarification 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:
    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.

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

  5. [Tim Bray] Review of webarch-20040816 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 RESOLVED: to change 4.6 from "Because of their role in defining fragment identifier semantics, data" to "Data", DC abstaining. Since "future directions" appears in the section headings of similar sections for identification and interaction, we RESOLVED: change title of 4.6 to "Future Directions for Data Formats"
  6. KD-001 [was: Comments on Web Arch WD - 2004-07-05] has since been closed; the status report will be updated to show this presently.
  7. KD 004 [was: Comments on Web Arch WD - 2004-07-05] Further clarification from KD 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. ACTION CL: respond to Karl regarding KD004
  8. Some Phone Links spam.
  9. Bookmarks02 spam.

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 the 29 Sep comment from the HTML WG; DC said that looked like a bug and he'd investigate.

XLink-23, comments from HTML WG

based on IRC notes starting 15:13:33Z

The the 29 Sep comment from the HTML WG prompted discussion of issue xlinkScope-23. 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 hlink has not been updated in quite some time, nor has it been integrated into XHTML 2.0; the hypertext module does not use hlink. After discussion of various textual changes we 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 ACTION SW: ask the HTML WG if the qualification we made regarding XLink satisfies their comments.

Then we broke for the day.

Planning work on extensibility and versioning

based on IRC notes starting 09:01:43Z

PC asked for a plan for work on extensibility and versioning (XMLVersioning-41). 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 message of 6aug to www-tag is relevant. ACTION NDW: to report workplan and dates for Extensibilty and Versioning work.

Responses from Last Call commenters

based on IRC notes from 09:08:33 to 09:50:59

  1. [Tim Bray] Review of webarch-20040816 NDW led discussion of further input from Bray. 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.
  1. Representation of a secondary resource? After further discussion of how to clarify, we 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. ACTION DC: to reply to commenter re primary and secondary resources.

HTTPSubstrate-16

based on IRC notes starting 09:51:33Z

DanC noted an upcoming W3C/IETF liaison meeting 14 Oct. After some discussion of the history and status of issue HTTPSubstrate-16, ACTION DC: recruit someone to write a counterpoint to RFC3205 CONTINUES.

Information Resources, httpRange-14 (Thu)

based on IRC notes starting 07:36:08Z, continuing with notes starting 12:48:09Z

NW introduced a rewrite of section 3.1. Information Resources and Representations for discussion. While it addressed CL's objection, RF and DC found it had insufficient motivation.

We then went on to discuss extensibility and versioning, and came back to this topic after other agenda were done.

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:

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

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.

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.

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.

RESOLVED: to replace section 3.1 Information Resources with an updated to section 2.2 as above, "... We identify this set as ?information resources?. ..." ACTION SW: to respond to Pat Hayes, Patrick Stickler and Sandro Hawke giving proposed resolution of Information Resource. NDW suggested that the HashSlashDuality text was no longer worthwhile, and we 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, DC, TBL abstaining. ACTION DC: with Norm, develop a finding on httpRange-14 starting with the HashSlashDuality text

Schedule for webarch end-game

based on IRC notes starting 14:57:55Z

After some discussion of publication mechanics, we drafted the following plan:

18 Oct
NW to provide Editor's Draft
NM to provide branch (NM at risk)
DC to produce PR request (at risk)
25 Oct
Decide to go to PR
01 Nov
Director's Decision telcon

Would like to be there: CL, SW, TBL

05 Nov
i's dotted, t's crossed
Publication as a PR draft
Call for testimonials
18 Nov - 06 Dec
Blackout
08 Dec
AC Reviews due (05 Nov plus four weeks and a few days)
Testimonials due
13 Dec
i's dotted, t's crossed
14 Dec
REC published
Press release
25 Dec
DC dines on PC's nickle. ;-)

ACTION NDW: to produce an editor's draft by 14 Oct (COB EDT). ACTION DC: draft a request for proposed recommendation, based on Norm's draft ACTION CL: to cause draft of press release to happen

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.

Adjournment, thanks to the host

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 hosting arrangements.

TODO list and Change Log

In addition to getting this record reviewed by the participants, I plan to:

And I hope to:

These are the changes v1.12 of 2004/09/30 14:27:15, sent in an agenda announcement:


$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 ***