The goals of the meeting are:
Preparation materials include:
All current members of the TAG participated in the meeting:
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.
Other items from the proposed agenda were not discussed.
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.
We reviewed the following opportunities to meet in face-to-face:
Note announcements to W3C members regarding W3C@10 and W3C AC Meeting
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
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.
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
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.
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.
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.
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.
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.
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.
A number of comments on the 2nd (16 Aug) LC webarch draft motivated further discussion of issue httpRange-14:
Also, discussion of same on www-rdf-interest@w3.org.
Each participant was invited to give some remarks on the issue:
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.
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 an example of confusion re web resources and not web resources ;-)
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.
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.
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.
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:
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:
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
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
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
In both sides of the HashVsSlash debate, the choice of GoodURIs either obscures a document section or an RDF Property. ... HashSlashDuality
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.
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
based on IRC notes starting 13:46:59Z by RF et. al.
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
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.
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.
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.
based on IRC notes from 09:08:33 to 09:50:59
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.
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
based on IRC notes starting 14:57:55Z
After some discussion of publication mechanics, we drafted the following plan:
Would like to be there: CL, SW, TBL
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.
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.
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 ***