Administrative

A review of the 28 Sep webarch draft

based onIRC logstarting Tue 09:03:19Z

In preparation for the meeting, DanC sentcomments 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 sufficientscalability, efficiency and utility that they have resulted in aremarkable information space of interrelated resources, growing acrosslanguages, cultures, and media. In an effort to preserve theseproperties of the information space as the technologies evolve, thisarchitecture document discusses the core design components of theWeb. They are identification of resources, representation of resourcestate, and the protocols that support the interaction between agentsand resources in the space. We relate core design components,constraints, and good practices to the principles andproperties they support.

The group discussed proper use ofRFC2119 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 inwebarch is as appropriate as the use in RFC2119 itself. Concerns about"conformance" turned out to be misplaced; the constraints in RFC2119regard interoperability, and as such, the editor was advised to changethe "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 discussdata: 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 ofThe distinguishingcharacteristic of representation reuse, as opposed to aliasing, isthat the underlying resources are different. from 2.3.2, theeditor dropped it.

DanC expressed disappointment that section 2.5 URI Opacity didn'tmake the point about providers rights to choose names, and suggestedadding a link to the siteData-36 issue; NDW said he'd take a look.

There was support for changingPrinciple: Data-metadatainconsistency in 3.4 to a constraint, related to 5.3Principle:Error recovery

Regarding some of the good practice notes, DanC suggested noting QAin addition to I18N and WAI in the scope section of the introduction;this appealed to several TAG members and the editor was advised to doso.

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 raisedregarding "Also, they[binary formats] can be consumed more rapidly byagents in those cases where they can be loaded into memory and usedwith little or no conversion."

DanC congratulated NDW on elaborating on the trade-off regardingextensibility in section 4.2, but said he would prefer not to includesuch a strong good practice note: "A specification SHOULD providemechanisms that allow any party to create extensions.". NM concurred,arguing that there are many, many dimensions to any spec. Most ofthese dimensions shouldn't be extensible. Should we allow XML to gonon-Unicode? The trick and the art is to choose just those you want toworry about. PC expressed a concern regarding synchronization betweenthe extensiblity/versioning finding and this section ofwebarch.Discussion was inconclusive at this point; it continuedindiscussion 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 representURI/local-name pairs SHOULD NOT allow both QNames and URIs inattribute values or element content, where they would beindistinguishable."DanC suggested rephrasing as a constraint, perhapsreplacing "SHOULD NOT" with "do not". This was generallysupported.

Representations over-constrained?

NM raised a related concern that current web arch is too strong inimplying that all representations are single streams, are specificallyoctet streams, and need to be typed with IANA mediatypes. Generalizing appealled to several group members, but there wassome concern about the impact of such a change at this point in theprocess; for example, whether we would owe the community another lastcall.ACTION NM: to take a run through to see howgeneralizing 'representation' to be less constrained would look withmore careful terminology, report on whether this looks feasible ornot.later in the meeting, NM agreed to try to do this inpreparation for the 18Oct telcon

WebArch LC#2 Comments

based onIRC logsstarting 12:23:05Z

We started reviewing the pendingcomments,viewed thru thestatusreport Revision 1.10 of 2004/10/05 12:21:52.

1. Request for Review of TAG AWWW 2nd LC Draft.ACTION SW: to reviewcomments 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 untildiscussion 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 tilldiscussion of comments regarding httpRange-14
6. AWWW, 20040816 release, sections 1 and 2ACTION NDW: to notethis thread [closed] in the archive per msg from gk.
7. resources/representations [was: random comments on 2nd LC of WebArch] postponed tilldiscussion of comments regarding httpRange-14
8. too positive on extensibility [was: random comments on 2nd LCof WebArch] NDW suggested recent edits to 4.x are responsive tothis comment.ACTION CL: to respond to the commenter for issue8 pointing to the new draft on extensibilityCL sentsucha message during the meeting, but it seems worthwhile to leavethis action on the agenda for another meeting to check for a responsefrom the commentor.
9. section 2.2 - what does it mean to 'take on meaning' DCattempted to satisfy the commentor without changes to webarch, but noreply has come; DanC suggests that it's reasonable to take silence asassent in this case, accepting a risk that the commentor will objectat some later point.
10. Useof "assign" for URI -> resource

    RF found the suggestion to excise "URI owner" helpful, but several others preferred the current text thatexplains that 'URI ownership' regards the relationship between URIsand resources; weRESOLVED: to keep " Constraint: URIsIdentify a Single Resource Assign distinct URIs to distinctresources." despite the new information from LMM'scomment.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, weRESOLVED: that the TAG uses the term URI ownershiprather than resource ownership because some URIs identify resourcesthat the URI owner (a.k.a., minter) does not own. For example, when aURI identifies a physical object that is merely named by the URIowner.ACTION SW: to make thisresponse to Larry

Information Resources, Web Resources and httpRange-14

A number of comments on the 2nd (16 Aug) LC webarch draft motivatedfurther discussion of issuehttpRange-14:

• Patrick Stricker's comment and resultingthread on "information resource".
• Sandro Hawke's proposed alternate text andwww-tag thread.
• Stuart's web resource proposal (andrevised) andwww-tag thread.
• For background:Harry Halpin/Henry Thompson on "Web Proper Names".

  Also, discussion of same onwww-rdf-interest@w3.org.

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

• DanC said while he still finds the LC text acceptable, the factthat it doesn't distinguish between the position that some dogs areinformation resources (expressed by Stickler, among others) and theposition that no dogs are information resources (expressed by TimBL,among others) shows that it's not very useful.
• RF said that what we have currently is sufficiently vague that itdoesn't have anything architecturally meaningful to say. Stickler'scomment was: if that's what you want to say then why not call it a webresource. RF noted that Sandro agreed that what was in the webarch [asof the 16Aug LC draft] did not actually define information resource asintended, and thus his proposal was to add meat to that definition andthat his proposal was discussed on the mailing lists with very littlesupport from others in evidence. RF expressed a preference forStickler's proposal.
• NM said that it's not clear that the distinction is crisp enoughto be of benefit to readers, but that he didn't have a well-informedopinion about what answer is right.
• SW said that the 'information resource' distinction was introducedin response to some comments [on the Dec 2003 LC draft] and seems tohave helped. WS noted a possibly related bit from a conversationwith Larry about ownership: there's need for implicit or explicitindirection between URIs that are web-page like and URIs that arereal-world or conceptual artifacts; with respect to httpRange-14, onedirection is to use the hash for indirection; the Dublin Core folksseem to use http redirection, which seems interesting.

  SW said that in making the web resource proposal, he got Sticklerto agree that there's nothing in the document that he takes exceptionto; his concern is that people will read an implicit resolution intothe httpRange-14 issue in the use of "information resource"; if we'regoing to resolve it, we should do so more explicitly.

• Chris said his position was expressed in amessagein the thread where Stuart proposed and Jacek seconded to change inforesource to web resource:

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

  in IRC, CL noted anexampleof confusion re web resources and not web resources ;-)

• PC concurred with CL because it answers the question of what is onthe web: is it my intention that makes it so, or is it that it's up alot, or does it come and go with the server? He went on to note withregret that the we're likely to have outstanding dissent regardless ofwhat we decide, and that this issue is the biggest risk in any plansto get webarch to REC in 2004.
• NDW expressed support for the web resource proposal andwillingness to incorporate it into the webarch draft. He went on tosay that we say you should give URIs to important resources; peoplehave given them to dogs, and that he has yet to see a usefuldistinction between web resources and other resources, though it wasnot something he feels strongly about.
• TBL said that this is an issue he feels strongly about, though hehas sometimes been a minority of one on the TAG. He explained:

  The recent webarch drafts don't make the philosophical distinctionabout whether the URI refers to the dog or a picture of the dog; thesedrafts have been supported by a community of people who haveexperience with the widely deployed web technology where thedistinction is rarely evident, so they don't see the pain. But we'rebuilding the SemWeb architecture on top of the Web architecture, andin the semantic web, confusing the dog with the picture of the dog isa serious error. Then we have people like Dublin Core using a URIwithout a hash to identify the concept of a title of a book; theyhaven't worried about the fact that it's a kind of URI that they wouldalso use for a web page; since they haven't recursively appliedsemantic web technology rigorously to web pages, they don't see thepain either.

  He said he sees only one consistent architecture that isn't inseveral layers: the thing up to the hash is a document and the stuffafter the hash gives you a global identifier for something that thedocument talks about. This conflicts with existing practice in DublinCore, FOAF, and other grass roots ontologies; to pursue thisarchitecture would be to ask them to stop and please put in ahash. There are a lot of FOAF documents out there and it would bepainful to put in a hash, but there are a lot more web pages out thereand this seems to be the price of a consistent architecture.

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

RF observed ambiguity in, for example, the first example in the RDFPrimer, which provides a URI for a "web page" and whether, in the caseof a page including images, that actually refers to the collection ofresources that are combined to make the page or to the HTTP interfaceto that web server for only the initial request, or something else? Hesuggested that the existing architecture has a variety ofinterpretations for a URI: when using a URI to make a request, thatonly refers to the initial response that you get back; in other casesit's identifying the HTML page. He suggested the use of additionalassertions should be used in case it's necessary to determine which ismeant. TimBL said that there's a particular identificationrelationship in web architecture, and it's not the relationshipbetween a URI and an HTML representation, but rather between a URI andthe resource which the HTML document represents.

In the case of a web page consisting of HTML and images, TimBL saidthe images are part of the web page resource; that the image tag isjust a shorthand for having the pixels in the HTML file. RF noted thatthe HTTP specification doesn't say these things are part of therelevant resource. NM noted that if we take the URI to refer to thecomposed page, that raises questions about what it would mean todelete it or manipulate it. RF suggested the URI refers to theapplication steady state that you get after you interpret therepresentation. TimBL suggested the resource is an information bearingobject, and that webarch must say what information it contains: theimage is part of the resource and the message conveyed does includethe picture.

CL gave an example of URI that, when dereferenced, returns aframeset that contains a single HTML page and pointed out that from aweb architecture perspective, the single page and the framed page aredifferent; though people will use the URI in the same way, to use theURI for the HTML page and for the collection of things is a URIcollision. TBL responded that no, none of the URIs in the examplerefers to the bits of the representation.It's not clear thatTimBL understood Chris at this point.

TBL began to relate this to issues with XInclude, which seemsto fit into the architecture at a lower level, but line of discussionturned out to be not particularly relevant.

RF explored the question of the last modified date of such compounddocuments, suggesting that using the steady state model avoidsproblems with considering all the images, stylesheets etc. in theanswer. NM suggested that in the case of a composed page, a URI foreach of the components is evident, but the composition is a separateresource which may or may not be clearly named.

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

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

DanC suggestedHashSlashDuality,whose opening statement is "In both sides of the HashVsSlash debate,the choice of GoodURIs either obscures a document section or an RDFProperty."Discussion of whether to use this in the webarchdocument or perhaps a finding was inconclusive at this point, butcontinued later.

The group considered thedefinitionof information resource offered by Sandro briefly.

Information Resources, Web Resources andhttpRange-14 (II)

DanC led a discussion around a list of proposals, asking which oneproposal each person preferred and which proposals, if any, eachperson 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 judgedon whether they resolve the whole of HTTPRange-14, DanC said no, thetarget was addressing the outstanding last call comments, thoughclosing 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 theset constrained to have representations or be network-accessible oranything like that overly constrains Web Architecture.

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

TBL suggests that what he means by 'information resource' is aconcept that predates the Web and is not necessarily connected toavailability on the Web. Norm and Chris observed thatthe concept did not seem sufficiently well-defined, testable, nor operational.TBL suggested that there's something fundamentally differentbetween a table and a textual work such as the bible.NM suggested that Claude Shannon's work on information theorymight provide a suitable definition; TBL agreed that yes, that'sthe 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 surroundingcontext should be used to disambiguate what URIs identify, sincesurrounding context serves to provide redundancy. NM clarified that hewasn't referring to lossy channels or redundancy when he suggestedthat information theory could help us; he was pretty sure that Shannongives a definition of something like "pure information" that isessentially what you aretrying to communicate through thechannel. He said that by analogy, we need not have redundancy in atemperature value or the words in a poem to say that they are"information"; we may need redundancy to communicate them with somepredictable probability of success through a noisy channel; HTTP needsredundancy on the wire, but the "information resource" definition asinformation does not involve redundancy.

Dan suggested that a a textual work can be consumed over the web ina way that a table cannot; if you see a table and a movie in a productcatalog, while you can learn about the table using HTTP, you can neverconsume it to the point where you owe the vendor the price in thecatalog, while with information resources, you can consume them to thepoint where you owe the price just by observing representations.

RF argued that definitions of information resource that interactwith URI syntax contradict the principle of URI opacity. TBL counteredthat URI opacity only says not to make unlicensed inferences, but thisinference 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 processsuggests it should be pursued. At Noah's suggestion, we explored somevariations on the proposals and combinations of them, withoutconclusion. The editor was encouraged to prepare something for discussionlater in the meeting.

Outstanding comments from the Quality AssuranceWorking Group

based onIRC logstarting at 12:05:25Z, TimBL serving as scribe

SW noted that our27 Sep discussion with the QA WG abouttheircomments was inconclusive.

Though many supported the elaboration on the trade-offs aroundextensibility and versioning insection4.2 of the 28 Sep webarch draft, there were mixed opinions onwhether the boxed notes communicated good/best practiceseffectively. DanC noted amessagefrom Dom to the effect that the QA WG was reviewing the 28 Septext and would tell us Monday if it satisfies them.

The participants were sympathetic to the QA WG's point that forsome designs, no extensibility is best; PC checked to see if thedraftfinding on extensibility and versioning reflected this anddiscovered that it does not. PC asked if the risk that decisions madehere would affect the finding was acceptable; several said yes, theydon't mind if the finding needs to change as a result of decisionsmade today. Eventually, weRESOLVED: to addanother para of explanation in section 4.2.3. Extensibility that saysmore bluntly that there are trade-offs here should be added, editorsalting to taste, and to leave the good practice note boxes,SKW,RF,DC,NMabstaining. After review of other points made by the QA WG,weRESOLVED: Make that change "the long termbenefits of a +well-designed+ extensibility mechanism....".NDW said he has already added some and will add more references to theQA work to address their comments.ACTION NDW:add "for more info, see also" link toasection of a QA spec to 4.x.ACTION DC: Report back to QA on our disposition oftheircomments.

PC asked could the QAWG please review the draft finding? NWacknowledged that David Orchard is doing most of the technical work onthe finding.ACTION PC: solicit QA WG reviewof draft extensibility/versioning finding

WebArch LC#2 Comments (II)

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

12. 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.
13. Representationof a secondary resource? We reviewed the primary/secondaryterminology insection3.3.1, and noted a related comment,Latelast-call comment on AWWW Graham Klyne (Tuesday, 5 October). Wediscussed ways to clarify that primary/secondary is a relationshipbetween resources, not disjoint sets of resources: replacing theterms, getting rid of them, diagrams (alaa design note),etc. RF noted the terms are defined in the URI specification. DCpointed out an error in the second bullet... "One cannot carry out.."; this is not true because it assumes that secondary resource is aclass. ACTION NDW: draft for section 3.3.1 to clarifyprimary/secondary (done inlater comment reviewsession).
14. web faster spam.ACTION DC: make sure "web faster" doesn't bother the chair next time he's doing an agenda
15. KD002Karl'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

16. [Tim Bray] Review of webarch-20040816 NW reviewed Bray'scomments, noting which he had incorporated and which he haddeclined. There was considerable support for Bray's commentregarding section 4.6; weRESOLVED: to change4.6 from "Because of their role in defining fragment identifiersemantics, data" to "Data",DC abstaining. Since"future directions" appears in the section headings of similarsections for identification and interaction, weRESOLVED: change title of 4.6 to "Future Directions for Data Formats"
17. 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.
18. KD 004 [was: Comments on Web Arch WD - 2004-07-05] Furtherclarificationfrom KD prompted discussion of section 2.4 URI Overloading. DCsuggested using an example of an example document vs. a DTD, where theproblem would be evident to software. CL and RF noted the commentseemed 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 arefine (but give each thing an anchor so it can be separatelyreferenced)" which was generally supported.ACTION CL: respond to Karl regarding KD004
19. Some Phone Links spam.
20. Bookmarks02 spam.

PC asked if there were more recent comments. DC noted that thedeadline has passed; while TAG members are welcome to requestdiscussion of late comments, we have less and less obligation to do soas time goes by. PC noted the status report seems to be missingthe29 Sep comment from the HTML WG; DC said that looked like a bugand he'd investigate.

XLink-23, comments from HTML WG

based onIRC notesstarting 15:13:33Z

Thethe29 Sep comment from the HTML WG prompted discussion of issuexlinkScope-23. Thediscussion started with process/social issues; PC and others notedthat the linking task force has made little progress in the last sevenmonths; TBL noted several cases of one group not re-using the work ofanother. CL noted some technical obstacles to reuse, noting thatdesigning for reuse intentionally is important. We noted that the SVGWG chose to use XLink, but the SMILE and HTML WG and perhaps MathMLWGs did not. We noted thathlink has not been updated inquite some time, nor has it been integrated into XHTML 2.0; thehypertextmodule does not use hlink. After discussion of various textualchanges weRESOLVED: add that XLink is notthe only linking design that has been proposed for XML, nor is ituniversally accepted as a good design. to section 4.5.2. Links inXMLACTION SW: ask the HTML WG if thequalification we made regarding XLink satisfies theircomments.

Planning work on extensibility and versioning

based onIRC notes starting 09:01:43Z

PC asked for a plan for work on extensibility and versioning (XMLVersioning-41). DCsaid he'd like to see a shorter (5 page?) finding. NDW said that he'sbusy in Nov, so a finding in Oct would suit him better; he said thatDave Orchard is doing the "heavy lifting". NDW also encouraged dialogwith the XML Schema WG. NM said he participates in the XML Schema WG,so we now have a direct connection; hismessageof 6aug to www-tag is relevant.ACTIONNDW: to report workplan and dates for Extensibilty and Versioningwork.

Responses from Last Call commenters

based onIRC notesfrom 09:08:33 to 09:50:59

16. [Tim Bray] Review of webarch-20040816 NDW led discussion offurtherinput from Bray. NDW is inclined to fix "If rep communicates thestate of the resource inaccurately, this inaccuracy or ambiguity maylead 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 XMLSchemas from the list of acceptable representations of namespacedocuments.

13. Representation of a secondary resource? After further discussion of how to clarify,weRESOLVED to clarify ala: "The terms ?primary? and?secondary? in this context do not limit the nature of theresource?they are not classes. In this context, primary and secondarysimply indicate that there is a relationship between the resources forthe purposes of one URI: a URI with a fragment identifier. Anyresource can be identified as a secondary resource. It might also beidentified using a URI without a fragment identifier, and a resourcemay be identified as a secondary resource via multiple URIs. Thepurpose of these terms is to enable discussion of the relationshipbetween such resources, not to limit the nature of a resource." withsome discretion to the editor regarding pronoun references.ACTION DC: to reply to commenter re primary and secondary resources.

HTTPSubstrate-16

based onIRC notesstarting 09:51:33Z

DanC noted an upcoming W3C/IETF liaison meeting 14 Oct. After somediscussion of the history and status of issueHTTPSubstrate-16,ACTION DC: recruit someone to write acounterpoint to RFC3205 CONTINUES.

Information Resources, httpRange-14 (Thu)

based onIRC notesstarting 07:36:08Z, continuing withnotesstarting 12:48:09Z

NW introducedarewrite of section 3.1. Information Resources and Representationsfor discussion. While it addressed CL's objection, RF and DC found ithad insufficient motivation.

We then went on to discussextensibility andversioning, and came back to this topic after other agenda weredone.

In discussion of rationale for the "information resource"distinction, TBL and CL pointed out that all the material onrepresentations and much of the material on interactions appliesmostly to information resources and suggested that the term is usefulto contrast "resource", the top/unconstrained class, with the classthat'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 InformationResources with an updated to section 2.2 as above, "... We identifythis set as ?information resources?. ..."ACTION SW: to respond to Pat Hayes, Patrick Sticklerand Sandro Hawke giving proposed resolution of InformationResource. NDW suggested that the HashSlashDuality textwas no longer worthwhile, and weRESOLVED: todrop the HashSlashDuality text (section 2.2.1 and descendants in adraft that was projected) and use as input to finding on HTTPrange-14,DC,TBL abstaining.ACTION DC: with Norm, develop a finding on httpRange-14starting with the HashSlashDuality text

Schedule for webarch end-game

based onIRC notesstarting 14:57:55Z

After some discussion of publication mechanics, we draftedthe 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 by14 Oct (COB EDT).ACTION DC: draft arequest for proposed recommendation, based on Norm's draftACTION CL: to cause draft of press release tohappen

RF asked what the Nov meeting in Boston would be about, if weproceed according to this plan; thinking about the next edition of theArchitecture document was the response given by several.

Adjournment, thanks to the host

RESOLVED: The TAG thanks Day Software fora terrific job of hosting our meeting, and for supporting RoyFielding's participation in the TAG. Special thanks to Jean-MichelPittet for his contributions to thehostingarrangements.