IRC log of tagmem on 2003-07-22

Timestamps are in UTC.

15:14:05 [RRSAgent]
RRSAgent has joined #tagmem
15:16:26 [DanC-AIM]
DanC-AIM has joined #tagmem
15:17:10 [DanC-AIM]
Hi from Rosie's.
15:17:27 [DanC-AIM]
Ping?
15:18:34 [TBray]
TBray has joined #tagmem
15:19:09 [IanYVR]
Hi Dan
15:20:44 [Norm]
Norm has joined #tagmem
15:22:19 [DanC-AIM]
Hi. I'm walking over.
15:22:20 [Roy]
Roy has joined #tagmem
15:22:38 [DanC-AIM]
Zakim, who's here?
15:22:38 [Zakim]
sorry, DanC-AIM, I don't know what conference this is
15:22:39 [Zakim]
On IRC I see Roy, Norm, TBray, DanC-AIM, RRSAgent, Zakim, IanYVR
15:23:33 [IanYVR]
Roll call: TBL, NW, TB, RF, DO, PC, SW, IJ
15:23:51 [IanYVR]
Agenda: http://www.w3.org/2001/tag/2003/07/21-tag
15:24:05 [IanYVR]
Section 4 of agenda
15:24:18 [Stuart]
Stuart has joined #tagmem
15:24:23 [IanYVR]
TBray: I think that for issues 7, 20, 24, 31, 37, there is enough info in arch doc.
15:25:57 [Norm]
Norm has changed the topic to: http://www.w3.org/2001/tag/2003/07/21-tag
15:26:07 [IanYVR]
[Process discussion around last call]
15:26:59 [IanYVR]
PC: Need to schedule last call with groups where there are dependencies
15:27:37 [DanC-AIM]
Hmm... How to ask IETF to review it?
15:29:04 [DaveO]
DaveO has joined #tagmem
15:29:07 [IanYVR]
TBL: If there's a group where you know there are issues, resolve those before last call.
15:29:36 [IanYVR]
TBL: Don't say "we think we're done" while people are still banging on the document on the list.
15:30:42 [IanYVR]
TBray: If we wait to go to last call before reaching consensus with web ont folks, that's going to take a long time.
15:31:03 [IanYVR]
TBL: We have an elephant in the room. People are telling us we're not using terms consistently.
15:31:28 [DanC-AIM]
same room today?
15:31:35 [IanYVR]
TBL: Namely, "resource" is being used in two different ways that makes the document unreadable (issue 14).
15:31:53 [DanC-AIM]
Should I ring the schemasoft door or the antarctica door?
15:32:07 [IanYVR]
You can get all the way to the door of the ping pong room
15:32:24 [IanYVR]
DO: I think you can elicit the problem without solving.
15:32:37 [DanC-AIM]
From the entrance on homer?
15:32:39 [IanYVR]
Yes
15:33:16 [IanYVR]
PC: Unlike other groups, we will have open issues when we go to last call.
15:33:46 [IanYVR]
[Chris joins]
15:33:52 [DaveO]
q+
15:34:08 [IanYVR]
[DanC joins]
15:34:47 [Stuart]
q?
15:35:46 [Stuart]
ack Dave0
15:36:03 [TBray]
q+
15:36:33 [IanYVR]
DO: I think we need to explain to people why arch doc is different from other specs.
15:36:48 [IanYVR]
CL: The model is that we have a stream of issue and we gradually refine the document over time.
15:37:13 [Stuart]
q?
15:37:21 [Stuart]
ack TBray
15:37:59 [IanYVR]
TBray: I think that we still can benefit the community by publishing something that's not complete.
15:38:08 [DavidOrch]
DavidOrch has joined #tagmem
15:38:14 [DavidOrch]
q?
15:38:29 [Stuart]
ack Dave0
15:39:08 [IanYVR]
DO: Need to explain why we chose to stop where we did for v1.
15:40:04 [IanYVR]
PC: Need to explain to people also that we expect to skip CR.
15:40:19 [DavidOrch]
And say that there will be a V2..
15:40:24 [DanC_jam]
DanC_jam has joined #tagmem
15:40:52 [IanYVR]
TBray: We could call this web arch level 0
15:42:03 [IanYVR]
PC: Question of whether to create a new mailing list just for last call comments.
15:42:21 [DavidOrch]
q-
15:42:39 [IanYVR]
q- DaveO
15:42:55 [IanYVR]
PC: I prefer a separate comments list.
15:43:04 [IanYVR]
SW: Me too, with discussion on www-tag
15:43:22 [IanYVR]
TBray: It's going to be hard from keeping discussion going on last call list.
15:44:37 [IanYVR]
PC: Create a monitored list and force every message to be permitted.
15:45:50 [IanYVR]
DC: I agree that cross-posted threads are a pain.
15:46:58 [DanC_jam]
hmm... a moderated list isn't a bad idea... we'll pretty much have to do the equivalent of moderating it anyway
15:47:35 [Norm]
Norm has joined #tagmem
15:48:45 [IanYVR]
"www-tag-review"
15:48:53 [IanYVR]
s/www/public
15:49:03 [DanC_jam]
yeah... public-webarch-comments@w3.org
15:49:55 [IanYVR]
SW: Cost of going to last call on group: increased tracking of issues on doc, ongoing agenda item
15:50:22 [IanYVR]
TBL: It's my opinion that the document is imperfect and we're saying we want to take to last call anyway.
15:50:33 [IanYVR]
TBray: It's incomplete, but I think good enough to go to last call.
15:51:03 [IanYVR]
RF: Last call fine with me. I think it needs a lot of work, but I think it's useful for the process to put out a draft.
15:51:17 [TBray]
TBray: What we have is consistent and essentially correct, but not complete
15:51:22 [IanYVR]
TBL: That's not a last call draft, that's a draft.
15:51:30 [IanYVR]
[TBL comment to RF]
15:52:49 [DanC_jam]
(where are we in the agenda?)
15:53:44 [IanYVR]
Tues morning: Arch Doc
15:55:33 [TBray]
q+
15:55:52 [TBray]
q+ Paul
15:56:13 [IanYVR]
TBL: (Re httpRange-14) I feel that if we don't address this, this will be like the effect of the XML Namespaces Rec ambiguity.
15:56:42 [DaveO]
q+
15:56:44 [DanC_jam]
ack danc'
15:56:47 [DanC_jam]
ack danc
15:56:47 [Zakim]
DanC_jam, you wanted to suggest that we *do* take advantage of Candidate Recommendation
15:57:10 [IanYVR]
DC: I think CR would be a good idea. The doc's intended to have an effect; we can test whether it has the intended effect.
15:57:13 [Chris]
Chris has joined #tagmem
15:57:21 [TimBL-YVR]
TimBL-YVR has joined #tagmem
15:57:22 [IanYVR]
PC: What's the success criterion?
15:58:09 [IanYVR]
DC: Yes, I think we can find groups to use the document.
15:58:23 [IanYVR]
TBL: XML Schema had a similar issue.
15:58:30 [Chris]
Chris has joined #tagmem
15:59:05 [IanYVR]
PC: The infoset spec from XML Core is an example of a spec that you don't implement; you reference normatively. The Core WG left CR when referred to normatively from other specs.
15:59:19 [IanYVR]
PC: Perhaps that's the best we can hope for.
15:59:23 [IanYVR]
ack TBray
15:59:45 [IanYVR]
TBray: I think we should go to last call sooner rather than later. I think a lot of what we've written hasn't been written down in one place before.
16:00:14 [IanYVR]
TBray: I also perceive that the areas where we lack consensus all involve a layer that is "above" where we are now.
16:00:29 [IanYVR]
TBray: These are additional constraints imposed on what we've said already. And layer cleanly.
16:00:52 [IanYVR]
TBray: While I accept that the document does not reflect a reality shared by some, I'm convinced that there's nothing in their that hinders them in their goals.
16:00:56 [TimBL-YVR]
q+
16:01:24 [Norm]
Norm has joined #tagmem
16:01:55 [IanYVR]
RF: Pay Hayes' comments were that RFC2396 covers an information space that is larger than that covered by the Arch Doc.
16:02:27 [TBray]
q+ Paul
16:03:53 [IanYVR]
RF: Pat is not "actually confused"; it's that the Web Arch document doesn't cover the entire space of the Web. He was saying that if you restrict your discussion to information resources, then the document makes sense. It also makes sense if you limit the scope to the information system that is the classic Web. But it doesn't if you include the infosystems that are the sem web or web services.
16:04:14 [IanYVR]
TBL: I believe that the document should not go to last call without this issue resolved.
16:04:16 [IanYVR]
ack Paul
16:04:40 [TimBL-YVR]
X-Archived-At: http://www.w3.org/mid/p06001215bb39faa42145@%5B10.0.100.23%5D
16:04:48 [TimBL-YVR]
Pat's message
16:05:07 [IanYVR]
PC Summarizing his interpretation: There's a thread on www-tag that TBL thinks needs to be resolved before we go to last call. Do you think that thread is separable from httpRange-14?
16:05:09 [IanYVR]
TBL: No.
16:05:42 [IanYVR]
TBL: I think the change to the document is fairly easy: introduce "information resource" where appropriate.
16:08:07 [IanYVR]
TBL: I don't know what the solution to the issue is. Perhaps we could resolve Pat's issue without mentioning HTTP. I don't know what the form the result would take.
16:08:11 [TBray]
q+
16:08:28 [IanYVR]
DO: I'm disappointed that this is coming up.
16:09:08 [IanYVR]
DO: We told AC we were going to last call, agreed this would not be on the agenda, and now there's a sort of veto.
16:09:16 [Stuart]
ack DO
16:09:21 [DaveO]
q-
16:09:22 [Stuart]
ack DaveO
16:09:28 [DanC_jam]
ack timbl
16:09:31 [TimBL-YVR]
TBL: However, the issue is SO close to hhtp-range-14 that we couldn't discuss one wiithoyt being allowed to discuss the other.
16:09:32 [IanYVR]
TBL: We could apologize up front that we use the term in two different ways. I might be able to live with last call if there's a red flag at the front of the document.
16:09:37 [Stuart]
ack TBray
16:10:24 [IanYVR]
TBray: I think that Pat Hayes' comment is wrong. I can produce counter-examples. I think his assertion that we are using the term "resource" in two different ways is wrong. I think the document is consistent.
16:11:46 [IanYVR]
ack DanC
16:11:46 [Zakim]
DanC_jam, you wanted to say I disagree with PatH as well; the webarch doc is consistent; but I think it would be cost effective to try the 'information resource' edit; not that
16:11:50 [Zakim]
... costly and could satisfy a lot more readers
16:12:06 [IanYVR]
DC: I disagree with Pat as well. I still think it would be cost-effective to talk about both classes of resources. Lots of people have that angst and that's our audience.
16:12:27 [Chris]
is that just renaming one use, or both uses?
16:12:32 [IanYVR]
q?
16:13:01 [IanYVR]
[Break]
16:20:17 [Norm]
Norm has joined #tagmem
16:50:15 [IanYVR]
[Resume]
16:52:12 [IanYVR]
TBray: I've seen no evidence to convince me that if we proceed with this draft, we are cutting off options.
16:52:44 [IanYVR]
TBray: We don't say much about "what a resource is"; we impose no constraints.
16:52:47 [Norm]
Norm has joined #tagmem
16:52:58 [IanYVR]
TBray: People point out that in the real world there are constraints.
16:53:10 [IanYVR]
TBray: We don't say that and I think that we're right not to make that distinction.
16:53:26 [IanYVR]
TBray: There are a number of taxonomies we could choose for categorizing resources.
16:53:47 [IanYVR]
TBray: I can give you examples of things that are resources but you'd have to stretch to think that they're information resources.
16:54:11 [IanYVR]
TBray: There are other taxonomies that are at least as interesting: class of resources published by hostile govts. for example.
16:54:25 [DaveO]
DaveO has joined #tagmem
16:54:26 [IanYVR]
TBray: I agree that we need a better way to talk about taxonomies of URIs.
16:54:31 [DaveO]
q?
16:54:44 [IanYVR]
TBray: Our formalism is well defined: URI, resource, representation.
16:54:50 [DaveO]
q+
16:55:10 [IanYVR]
TBray: The Web today doesn't have a way to talk about whether something is an information resource, and the software all works fine.
16:55:36 [IanYVR]
TBray: I think that the document is well-enough along, passes the minimal progress necessary to declare victory.
16:55:52 [IanYVR]
TBray: We can't ignore the angst; we need to say something about it, but we don't need to make a big change.
16:56:03 [IanYVR]
ack DaveO
16:56:31 [IanYVR]
DO: I think most of the TAG feels we don't need to solve httpRange-14 before going to last call. Clearly TBL does.
16:57:13 [TBray]
nope
16:57:25 [TBray]
q?
16:57:43 [IanYVR]
[Process discussion]
17:00:29 [IanYVR]
DO: I have concerns about the process. What does my vote mean? TBL has the last word anyway.
17:00:35 [IanYVR]
DC: Yes, and you signed up for the group knowing htat.
17:00:49 [IanYVR]
TBL: I am definitely uncomfortable when my technical role and my process role overlap.
17:01:04 [IanYVR]
DO: We are trying hard not to put TBL in that position.
17:01:08 [Stuart]
q+
17:01:13 [TBray]
q+ Stuart
17:01:29 [TBray]
q+ Stuart
17:01:33 [IanYVR]
TBL: I have avoided talking about an issue that I think is fundamental for the last year. I've not acted in my role as Director as I'd like the group to reach consensus.
17:01:42 [IanYVR]
TBL: I'm not sure that ignoring the issue is the solution.
17:01:44 [IanYVR]
ack Stuart
17:02:01 [IanYVR]
SW: I note that httpRange-14 is open (from Feb 2003) even if not on this agenda.
17:02:42 [DaveO]
I also said that we just may have to vote and then live with a Director prohibiting Last Call publication, if he chooses to exercise that authority.
17:03:01 [IanYVR]
q?
17:03:43 [IanYVR]
PC: Director doesn't gate advancement to Last Call.
17:06:08 [IanYVR]
Straw poll: Does TAG wish to advance arch doc to last call substantially as is (with some editorial changes).
17:08:15 [IanYVR]
DC: I'm not satisfied with how issue 20 is handled in 16 July draft
17:08:53 [IanYVR]
IJ: See "User agents should detect such inconsistencies but should not resolve them without involving the user (e.g., by securing permission or at least providing notification). User agents must not silently ignore authoritative server metadata."
17:09:02 [IanYVR]
DC: That's not enough about error-handling.
17:09:39 [IanYVR]
DC: Before reviewing the doc in substance, I'm not prepared to say "go forward"
17:10:51 [IanYVR]
Straw poll: 5 move forward, 1+.5+.5 against, 1 abstain
17:12:22 [Stuart]
)q?
17:12:24 [DanC_jam]
DanC: I want the arch doc to say "silent recovery from errors considered harmful" and say that louder than "data format specs should say what to do in the presence of errors"
17:12:34 [Stuart]
q?
17:13:54 [IanYVR]
RF: It's hard to write down principles of things that have not been deployed.
17:14:30 [IanYVR]
Review of http://www.w3.org/2001/tag/2003/webarch-20030716 [16 July draft]
17:15:08 [IanYVR]
1. Introduction
17:15:38 [IanYVR]
DC: Lots of terms get bolded. Please bold "Web".
17:15:48 [IanYVR]
DC: What are we doing with Editor's notes?
17:15:57 [IanYVR]
"Editor's note: Todo: Introduce notions of client and server. Relation of client to agent and user agent. Relation of server to resource owner."
17:16:05 [IanYVR]
DC: I don't think that that's critical.
17:16:13 [IanYVR]
TBray: Seems appropriate for section 4 when it arrives.
17:16:15 [IanYVR]
DC: I like the intor.
17:16:17 [IanYVR]
TBray: Me too.
17:16:43 [IanYVR]
1.1. About this Document
17:17:23 [IanYVR]
RF: I don't understand why there's a 1.1 and 1.1.1
17:18:07 [IanYVR]
Idea: create 1.1.x on intended audience or drop 1.1.1. subheading.
17:18:43 [Chris]
q+ to worry about "3. The representation consists those bits that would not change regardless of the transfer protocol used to exchange them.
17:18:43 [Chris]
"
17:18:46 [IanYVR]
IJ: I will try to integrate scenario more into section 2.
17:19:17 [IanYVR]
TBray: s/The TAG/This document is intended to inform...
17:19:32 [IanYVR]
(same for second "TAG" instance later in third para of 1.1.1)
17:19:38 [IanYVR]
DC: Paste some of that into status section.
17:19:49 [IanYVR]
2. Identification and Resources
17:19:51 [Chris]
q+ to note objection on record to "User agents must not silently ignore authoritative server metadata.
17:19:51 [Chris]
"
17:20:21 [IanYVR]
TBray: Need to reword Principle: "Use URIs: All important resources SHOULD be identified by a URI."
17:20:38 [IanYVR]
DC: The doc doesn't say "if it doesn't have a URI, that doesn't mean it's not a resource."
17:20:58 [Chris]
q+ to request clarification on "3.2 and semantics"
17:21:32 [IanYVR]
RF: I have a rewrite of paragraph "Although there's not precise..."
17:23:13 [IanYVR]
RF: Don't mix up "identity" and "identify". Something can have identity (or many identities). There are means of identification (N-to-1) to those things.
17:23:34 [IanYVR]
TBray: I would be comfortable saying "URIs should be assigned for all important resources."
17:23:53 [Chris]
q+ to agree with dan about "Specifications of data formats SHOULD be clear about behavior in the presence of errors. It is reasonable to specify that errors should be worked around, or should result in the termination of a transaction or session. It is not acceptable for the behavior in the face of errors to be left unspecified."
17:23:53 [IanYVR]
[Discussion of identify/denote/name]
17:24:13 [IanYVR]
TBL: Not all URIs are necessarily assigned.
17:24:16 [IanYVR]
(e.g., hashes)
17:24:23 [IanYVR]
TBL: Only in delegated spaces.
17:24:27 [IanYVR]
RF: That's still assignment.
17:24:45 [IanYVR]
TBray: Right, at the end of the day you end up with a string that has been assigned to some resource.
17:25:15 [IanYVR]
DC: I support TB proposed wording changed.
17:25:28 [IanYVR]
TBray: The reason I'm proposing this is to stay away from the word "identity".
17:25:36 [Norm]
Norm has joined #tagmem
17:26:04 [IanYVR]
DC: "Assign" is useful. The question is WHO should do something. I think therefore that "assign" is a step in the right direction.
17:26:36 [IanYVR]
DC: The idea is that if everybody shares, we all win.
17:26:42 [Stuart]
q?
17:27:16 [IanYVR]
TBL: It would help a lot if we say "Identifier" here is used in the sense of "naming".
17:27:32 [IanYVR]
TBL: The difference is that Tim Bray is named by "Tim Bray", though he can also be identified by his flashy shirt.
17:28:37 [IanYVR]
TBray: I would be comfortable saying "using id in the sense of name". I am more worried about "denote".
17:28:39 [IanYVR]
DC: I concur.
17:28:50 [IanYVR]
DC: I think "name" helps and "denote" doesn't (without lots of explanation).
17:29:02 [IanYVR]
DC: Actually, maybe "denote" would be incorrect.
17:29:37 [IanYVR]
[We read a paragraph that RF has written on this section]
17:30:57 [IanYVR]
PC: I am wondering whether we might say something nearer to the top about "stable" URIs.
17:32:26 [IanYVR]
PC: Feature of "stability" is also an aspect of importance.
17:32:34 [Chris]
it all hinges on an appropriate definition of 'consistency'
17:33:12 [IanYVR]
TBL: I'm not happy with RF's text.
17:33:36 [TimBL-YVR]
s/produce or consume/convey/
17:34:45 [IanYVR]
TBL: RF's text doesn't address sem web resources.
17:34:47 [TBray]
q+
17:35:11 [DanC_jam]
ack chris
17:35:11 [Zakim]
Chris, you wanted to worry about "3. The representation consists those bits that would not change regardless of the transfer protocol used to exchange them. and to note objection
17:35:14 [Zakim]
... on record to "User agents must not silently ignore authoritative server metadata. and to request clarification on "3.2 and semantics" and to agree with dan about
17:35:17 [Zakim]
... "Specifications of data formats SHOULD be clear about behavior in the presence of errors. It is reasonable to specify that errors should be worked around, or should result in
17:35:21 [Zakim]
... the termination of a transaction or session. It is not acceptable for the behavior in the face of errors to be left unspecified."
17:35:40 [IanYVR]
TBray: General remark on the document - People are going to take this document seriously. There will be lots of debates.
17:35:54 [IanYVR]
TBray: One of the ways we should be careful is to take out sentences that don't need to be here.
17:36:03 [Chris]
rrsagent, pointer?
17:36:03 [RRSAgent]
See http://www.w3.org/2003/07/22-tagmem-irc#T17-36-03
17:36:03 [TimBL-YVR]
q+
17:36:12 [IanYVR]
TBray: Every sentence that is not contentful should be removed.
17:36:47 [IanYVR]
TBL: I feel that the namespaces spec would have been improved on if some of those sentences had not been removed. I don't want us to follow that path.
17:37:10 [IanYVR]
q+ to talk about "on the Web" in RF's text.
17:37:32 [IanYVR]
RF: Delete "transclude all or part of it into another resource." You can do transclusion without a URI.
17:37:47 [IanYVR]
RF: Transclusion is not a rationale for many people.
17:37:51 [IanYVR]
DC: I disagree.
17:38:00 [IanYVR]
TBray: Purists will debate our use here.
17:38:13 [IanYVR]
RF: Say instead "include by reference."
17:38:15 [IanYVR]
DC: Yes.
17:38:28 [IanYVR]
RF: Delete last para of 2 (before 2.1)
17:39:58 [IanYVR]
TBL: The second paragraph of 2 is where you would put in the distinction about an information resource.
17:40:49 [IanYVR]
TBL: "A resource can be anything. Certain resources convey information when a resource has a link to another one."
17:40:53 [IanYVR]
q?
17:41:12 [IanYVR]
TBray: Would it meet TBL's needs to ack the class of information resources?
17:42:29 [IanYVR]
TBray: I suggest that we say that the universe of resources has a subset which we will call "information resources" that convey information. And stop there. We ack the distinction but don't put all HTTP URIs on one side of the border or the other.
17:42:36 [IanYVR]
CL: Add "electronic"?
17:42:44 [IanYVR]
TBL: No, could transfer via light, for example.
17:43:03 [Chris]
not about transfer, about category of information
17:43:07 [Chris]
but okay
17:43:33 [IanYVR]
IJ: About "on the Web"
17:43:47 [IanYVR]
TBray: I think "information resource" is isomorphic to DO's concept of "on the Web"
17:44:43 [IanYVR]
[Question of whether "on the Web" means "really does have a representation that is available"
17:45:09 [IanYVR]
TBL: From the semantic Web point of view, things are on the semantic Web from the moment you use the URI.
17:45:23 [IanYVR]
TBL: But in the common parlance, I think "it really does work" for information objects.
17:45:34 [IanYVR]
CL: In the common parlance, electronic is also understood...
17:45:48 [Chris]
the common parlance thus applies excluusively to electronic information objects
17:46:49 [IanYVR]
DO: I want "information resource" connected to "on the Web" in the document.
17:46:56 [TimBL-YVR]
URIs identify resources. A resource can be be anything. Certain resources are information resources, which convey information. These are termed information resources. Much of this document discusses information resources, often using the term resource.
17:47:33 [DanC_jam]
Bray: I like that parap
17:48:07 [DanC_jam]
DanC: it doesn't discuss "on the web". hmm...
17:48:10 [TimBL-YVR]
An information resource is on the Web when it can be accessed in practice.
17:48:13 [Chris]
last sentence, change to "Much of this document, while discussing resources in general, applies primarily or most obviously toinformation resources"
17:48:27 [TBray]
+1 to Chris
17:48:34 [Chris]
changes from an apology to an explanation
17:49:02 [IanYVR]
IJ: I can work with "on the Web" as a parenthetical remark tieing into other terms, but I don't think it needs to identify a formal part of the architecture and I don't imagine it being used later in the document.
17:49:22 [TimBL-YVR]
q+
17:49:24 [IanYVR]
DO: I think the definition should stay away from actual availability.
17:49:38 [Chris]
ian, wsa does indeed want to use it as a defined term, I understand
17:49:51 [IanYVR]
DO: Fine by me to say that there's a general expectation that a representatoin will be available.
17:50:02 [DaveO]
Indeed, SOAP 1.2 does use the term "on the web".
17:51:28 [Roy]
I don't think that there is an information resource and non-information resource. I think that some resources are accessible on the Web information system and others are not (or are only indirectly accessible). That is because anything that has state is an information-bearing resource, but you may not have access to that information.
17:52:27 [DanC_jam]
ack danc
17:52:27 [Zakim]
DanC_jam, you wanted to ask for the figure to go in section 1 or 2; it has the word "identifies"
17:52:28 [IanYVR]
q- IanYVR
17:52:54 [IanYVR]
DC: The word "identify" is used in the illustration I'd like to see in section 1 or 2. I'd like the label "identifies" in the figure.
17:53:04 [IanYVR]
RF: That is Pat Hayes' objection. You can argue it with him.
17:53:09 [IanYVR]
Review of diagram
17:53:22 [IanYVR]
from SW
17:54:16 [Chris]
http://lists.w3.org/Archives/Member/tag/2003Jul/0065.html
17:54:30 [IanYVR]
PC: What does "is a" mean.
17:54:37 [IanYVR]
DC: I believe it's clear enough.
17:54:47 [IanYVR]
TB, RF: Diagram doesn't add much.
17:55:33 [Chris]
actually,
17:55:36 [Chris]
http://lists.w3.org/Archives/Member/tag/2003Jul/att-0065/arch-nordf.svgz
17:55:44 [IanYVR]
TBray: Change camel case to English
17:55:45 [TimBL-YVR]
http://www.w3.org/2001/tag/webarch/tim.html
17:55:45 [Chris]
no good reason that is not public
17:55:46 [IanYVR]
[Support for that]
17:57:46 [IanYVR]
IJ: I would like to simplify diagram by removing dotted arrows
17:58:35 [IanYVR]
DC: It's critical that there be three things in the diagram. A lot of people miss that point.
18:00:20 [IanYVR]
Action CL: Redraw diagram with (1) English words (2) no more isa arrows; just label objects
18:01:23 [Chris]
ok since we just redrew it on the whiteboard, I won't send the old one to the public list but instead, the simplified new one
18:03:00 [DanC_jam]
Ian: yes, I intend to make "on the web" a term
18:03:08 [IanYVR]
TBray: Please lose "exponentially" in para 2.
18:03:23 [IanYVR]
DC: The point is that it's non-linearly.
18:03:30 [IanYVR]
TBL: use "dramatically"
18:03:57 [IanYVR]
DC: There's a lot of data to back up "exponential"
18:04:20 [IanYVR]
[No change]
18:04:26 [TimBL-YVR]
http://www.w3.org/History/1994-plot/slide.gif
18:04:31 [IanYVR]
[i.e., leave "exponential"]
18:05:04 [IanYVR]
2.1. Comparing Identifiers
18:05:19 [IanYVR]
RF: I think this isn't true: "An important aspect of communication is to be able to establish when two parties are talking about the same thing."
18:05:43 [IanYVR]
RF: It's an important aspect of someone else observing that they are talking about the same thing.
18:06:09 [TBray]
http://lists.w3.org/Archives/Public/www-tag/2003Jul/0201.html
18:06:37 [TBray]
2.1 Awkward start. Communication between parties is facilitated by the ability to establish when they are talking about the same thing. Then lose the second sentence.
18:07:16 [IanYVR]
TBL: Parties don't identify. They talk about or refer to. They don't identify.
18:07:43 [Chris]
+1 to timbl because context of use is important
18:08:38 [IanYVR]
Delete "In the context of the Web, this means when two parties identify the same resource."
18:08:49 [IanYVR]
TBL: Say "two parties are referring to the same resource" in following sentence.
18:08:58 [IanYVR]
DC: "Most straightforward' instead of "most common"
18:09:07 [IanYVR]
RF: Delete "Depending on the application, an agent may invest more processing effort to reduce the likelihood of a false negative (i.e., two URIs identify the same resource, but that was not detected).
18:09:07 [IanYVR]
"
18:09:14 [IanYVR]
RF: It's covered better in the URI spec.
18:09:24 [IanYVR]
TBray: Anybody who cares about this really needs to read [URI]
18:09:28 [IanYVR]
DC: I'm happy to delete that sentence.
18:09:32 [DanC_jam]
pls change "The most common" to "The most straightforward"
18:10:28 [IanYVR]
TBL: I think that the last sentence is useful since it lets people know that there is a risk of false negatives.
18:10:48 [IanYVR]
TBray: Yes, it's worthwhile saying that false negs can occur; for details look at [URI]
18:12:30 [IanYVR]
CL: Some apps are more sensitive to false positives, some more sensitive to false negs; choose wisely.
18:14:29 [IanYVR]
Action IJ: Fidget with this text.
18:14:49 [IanYVR]
Editor's note: Dan Connolly has suggested the term "coreference" instead of "equivalence" to communicate that two URIs are referring to the same resource.
18:14:59 [IanYVR]
DC: I can live without that change.
18:15:54 [TimBL-YVR]
"coreference" isin the same class as "denote" - we had decided not to use technical terms.
18:17:05 [IanYVR]
2.1. Comparing Identifiers
18:17:10 [IanYVR]
TBray: There are two side trips into URI opacity
18:17:36 [IanYVR]
TBray: I think that we need to discuss separately (1) comparing and (2) looking inside
18:17:59 [IanYVR]
NW: "In general, determine the meaning of a resource by inspection of a URI that identifies it."
18:18:13 [IanYVR]
NW: I'll provide words...
18:19:11 [IanYVR]
CL: "Although that it's tempting to infer this by looking at the URI that it is about..."
18:19:33 [IanYVR]
TBL: "...not licensed by the specs..."
18:19:50 [TimBL-YVR]
http://www.w3.org/2001/tag/webarch/tim.html <- updated
18:20:55 [IanYVR]
IJ: I'll try to create a section on opacity out of some text in 2.1
18:21:41 [IanYVR]
[Agenda comment: Substantial sentiment to continue walking through arch doc until we get done]
18:22:00 [DanC_jam]
[it seemed sufficient sentiment to consider it RESOLVED to me]
18:22:12 [IanYVR]
RF: Don't use the term "spelling" URIs.
18:22:46 [IanYVR]
DC: The point is that the string has to have the same characters.
18:23:49 [IanYVR]
RF: Change good practice title to "Consistent spelling or URIs"
18:23:57 [IanYVR]
IJ: What about lexical?
18:24:10 [IanYVR]
DC: Same string of characters.
18:24:25 [IanYVR]
DC: The agent should use the same string of characters as originally provided.
18:24:37 [IanYVR]
2.2. URI Schemes
18:24:59 [DanC_jam]
ACTION IJ: re-word "spelling" box
18:25:18 [IanYVR]
TBray: Why did "scheme" get changed to "scheme name"?
18:25:41 [IanYVR]
RF: If you're talking about the string before the colon, its the scheme name.
18:26:04 [IanYVR]
TBray: The *scheme* corresponds to a specification.
18:26:11 [IanYVR]
TBL: "There are other *schemes*..."
18:26:33 [IanYVR]
Action IJ: Prune instances of "scheme name" except for string component before ":".
18:27:03 [IanYVR]
RF: I use "scheme component" instead of "scheme name" for slot before ":"
18:27:04 [DanC_jam]
perhaps change "Each URI begins with a URI scheme name" to "Each URI follows a URI scheme" or ... hmm...
18:27:08 [TimBL-YVR]
q+
18:27:32 [IanYVR]
CL: s/to classify/to refer to/
18:27:39 [TimBL-YVR]
<defn>URI Scheme</defn> to be higher up in the para.
18:28:16 [IanYVR]
RF: Scheme names are always used in lowercase: "http URI"
18:28:27 [IanYVR]
TBL: I disagree; we're talking about the protocol HTTP
18:30:33 [IanYVR]
Resolved: Change "HTTP URI" to "http URI"
18:31:01 [IanYVR]
SW: s/identify identify/identify
18:31:21 [IanYVR]
SW: The scheme definitions use the verb "designate".
18:31:43 [IanYVR]
SW: If we use a different term than the spec we are referring to, that's problematic.
18:31:53 [IanYVR]
DC: I think we have a good reason to use a different term.
18:33:21 [IanYVR]
Resolved: Add footnote that the other specs use the term "designate". We take "identify" and "designate" to mean the same thing.
18:33:47 [IanYVR]
[Lunch]
18:36:33 [DanC-AIM]
byebye
18:36:54 [Norm]
Norm has joined #tagmem
18:46:55 [Norm]
Norm has joined #tagmem
18:58:04 [Ralph]
Ralph has joined #tagmem
18:58:35 [Norm]
Norm has joined #tagmem
18:59:33 [Zakim]
rebooting for service pack installation
19:26:24 [ndw]
ndw has joined #tagmem
19:26:34 [DanCon]
DanCon has joined #tagmem
19:26:54 [skw]
skw has joined #tagmem
19:30:04 [Stuart]
Stuart has joined #tagmem
19:43:33 [Ian]
Ian has joined #tagmem
19:56:13 [ndw]
ndw has joined #tagmem
19:59:38 [Ian]
[Resume]
20:00:15 [Ian]
TBL: There was discussion at lunch about including more best practices.
20:01:31 [DanCon]
TBL: how about "don't use the same URI for something that's an information resource and something that's not"
20:01:37 [DanCon]
TBL: e.g. dublin core title
20:02:05 [DanCon]
(Roy also sent a problem report w.r.t. XML encryption algorithm identifiers, suggesting they should *not* contain #s. have you seen that, timbl?)
20:02:10 [Ian]
[Continuing on 2.2]
20:03:14 [Ian]
RF: "Several URI schemes incorporate identification mechanisms that pre-date the Web into this syntax:"
20:03:47 [Ian]
RF: The examples are URIs; the identification mechanism is not sufficiently targeted in that sentence to distinguish talking about the URI or the information system.
20:04:04 [Ian]
RF: I would make one big list instead of two lists.
20:04:44 [Ian]
RF: change to "incorporate information systems that predate the Web into the URI syntax..."
20:04:45 [Ian]
[Yes]
20:05:17 [Ian]
TB: "We note in passing..."
20:05:23 [Ian]
TB: Get rid of "Note in passing"
20:05:45 [Ian]
SW: IRIs are indeed proving expensive.
20:06:36 [Ian]
DC: I think the sentence is insufficiently motivated, but I can't think of anything better.
20:07:53 [Ian]
TB: I propose to delete "We note in passing that even more expensive than introducing a new URI scheme is introducing a new identification mechanism for the Web; this is considered prohibitively expensive."
20:08:47 [Ian]
[DIscussion about whether IRIs are new identification mechanism.]
20:09:38 [Ian]
TBL: s/We note in passing/Of course,/
20:09:55 [DaveO]
DaveO has joined #tagmem
20:10:06 [Ian]
TB: If we are going to make a manifesto, put it higher in the document.
20:10:45 [Ian]
Resolved: Delete "We note in passing that even more expensive than introducing a new URI scheme is introducing a new identification mechanism for the Web; this is considered prohibitively expensive." since network effect covered above.
20:11:11 [Ian]
IJ: I'll delete "When finding available based on Tim Bray's discussion of this topic, link from here.
20:11:11 [Ian]
"
20:12:10 [Ian]
RF: On "If the motivation behind registering ..."
20:12:52 [Ian]
RF: There hasn't been any demonstration that there's higher cost to registering URI scheme to registering content type.
20:14:16 [Ian]
RF: Registration process same for URI schemes and MIME types in IETF space.
20:15:20 [Ian]
CL: It's worth saying to not register new schemes that aliases and existing scheme.
20:16:02 [Chris]
Chris has joined #tagmem
20:16:05 [Chris]
q+
20:16:13 [Ian]
IJ: I would move the first bullet to section on opacity.
20:16:19 [Chris]
q?
20:16:25 [Norm]
Norm has joined #tagmem
20:16:35 [Ian]
DC: There is a choice to be made about when to register a new mime type and when to register a URI scheme.
20:17:12 [Zakim]
Zakim has joined #tagmem
20:17:14 [Chris]
q+
20:18:06 [Ian]
DC: Proposed deleting from "If the motivation " through Editor's note.
20:19:02 [Chris]
ack chris
20:19:02 [Ian]
IJ: I intend to keep the first bullet but move it.
20:19:12 [Ian]
TBL: I'd like to keep the list and add:
20:19:29 [Ian]
1) Don't invent a new protocol when one exists that gets the job done. You'd have to replicate the caching structure,
20:19:40 [Ian]
and the social behavior.
20:20:35 [Ian]
2) Cost of reinventing something is that you often make the same mistakes.
20:21:00 [TBray]
TBray has joined #tagmem
20:21:06 [Ian]
RF: I agree with these points, but they belong in the section on protocols.
20:21:08 [Ian]
TBray: I agree.
20:21:26 [DanCon]
(I'm scanning the issues list... tim's comments about re-inventing HTTP are issue HTTPSubstrate-16; what's the status of that issue?)
20:21:51 [Ian]
TBL: Don't just remove text, leave a cross ref if you move it.
20:22:01 [DanCon]
(is issue 16 on our list of issues we intend to resolve for this last call?)
20:22:28 [Ian]
RF: Once you have a new protocol, you may want to say "you SHOULD have a new URI scheme for that protocol."
20:23:26 [Ian]
q+
20:24:03 [Ian]
q-
20:24:30 [Stuart]
q?
20:24:43 [Ian]
DC: There's a time and place for new uri schemes and new media types.
20:25:24 [DanCon]
itms was a time for a new media type, not for a new URI scheme. but I'm not sure how to generalize
20:25:43 [Ian]
TBL: Don't create a new URI scheme if the properties of the identifiers and their relation to resources are covered by an existing scheme.
20:27:14 [timbl]
timbl has joined #tagmem
20:27:23 [Ian]
DC: I can tell when it's done wrong, but not sure I can write done the right thing.
20:27:31 [Ian]
PC: Even writing down the wrong thing is helpful.
20:27:44 [Ian]
DC: That's IJ's finding (from TB's blog)
20:27:53 [timbl]
The properties of the space addressed (the set of things identifiable and their relationship with the identifers) is essentially the same as any existing space, that space should be used.
20:28:11 [timbl]
s/^/If/
20:29:13 [Ian]
TB, DC: Delete first bullet "The more resource metadata is included in a URI, the more fragile the URI becomes (e.g., sensitive to changes in representation). Designers should choose URI schemes that allow them to keep their options open."
20:29:30 [Zakim]
Zakim has joined #tagmem
20:30:40 [Ian]
Resolved: Delete "Reasons for this include" through bulleted list.
20:30:50 [Ian]
2.3. URI Authority
20:30:53 [Ralph]
Ralph has left #tagmem
20:32:13 [Ian]
DC: I would have expected third paragraph in section 3.
20:32:36 [Roy]
Roy has joined #tagmem
20:32:46 [timbl]
q+
20:35:07 [timbl]
The owner of a URI defines iwhat it identifies. The web protocols allow the owner to run and control a server which provides representation, and so when such a representation has been retreived it is reasonable to take it as authoritative.
20:36:24 [Stuart]
q?
20:36:31 [Stuart]
ack timbl
20:36:36 [Ian]
TBL: There is a place here to say that, because the protocols allow the URI owner to control the server, since you have protocols, it's reasonable to hold the resource owner accountable for the representations.
20:36:59 [Ian]
TBray: I note move from "authority" to "responsibility"
20:37:21 [DanCon]
I could live without this section.
20:38:32 [Ian]
IJ: Point was to introduce authority in assignment of URIs. Later authority of producing representations.
20:39:54 [Ian]
Resolved: Delete 2.3, moving paragraphs 3 and 4 to section 3 of the document.
20:40:25 [Ian]
PC: Ensure that unused refs are deleted.
20:41:02 [Ian]
2.4. Fragment Identifiers
20:41:47 [Ian]
TBL: I think in the second paragraph that "reference to" and "with respect to" are insufficiently clear.
20:41:53 [Ian]
[We note that that text is from RFC2396bis]
20:42:08 [Ian]
TBray: I think that "with respect to that resource" is incorrect.
20:42:34 [Ian]
TBray: "Additional information that is interpreted in the context of that representation."
20:43:19 [Ian]
RF: It's with respect to the *Resource*, across all representations.
20:44:10 [TBray]
q+
20:44:15 [Ian]
Does "foo#author" mean that "author" has to mean that this is the author of the primary resource? One could read it that way.
20:44:36 [Ian]
DC: I agree that "named in" works better.
20:45:53 [Ian]
TBray: So we are asserting that the frag id is interpreted w.r.t. the resource.
20:46:06 [Ian]
DC: We are observing that, yet. There are bugs and weirdnesses out there, but they are wrong.
20:46:48 [Ian]
TBL: If you dereference a URI and get a representation back, and you know the media type, and you know the frag id semantics, then you know what is identified by the frag id.
20:47:12 [Ian]
TBL: That doesn't mean that the frag id doesn't have meaning if you don't dereference the URI.
20:48:05 [Ian]
RF: change "that is merely named with respect to the primary resource." to "named by the primary reosurce."
20:48:31 [Norm]
The fragment identifier component of a URI allows indirect
20:48:31 [Norm]
identification of a secondary resource, by reference to a primary
20:48:31 [Norm]
resource and additional identifying information that is named by
20:48:31 [Norm]
that resource. The identified secondary resource may be
20:48:31 [Norm]
some portion or subset of the primary resource, some view on
20:48:33 [Norm]
representations of the primary resource, or some other resource that
20:48:35 [Norm]
is merely named by the primary resource.
20:48:49 [Chris]
rf: delete next paragraph
20:49:08 [Chris]
'Although the generic URI syntax allows ...'
20:49:29 [Chris]
nw: see above, did we agree to this
20:49:36 [Chris]
tbl: no not really
20:49:44 [Norm]
The fragment identifier component of a URI allows indirect identification of a secondary resource by reference to a primary resource and additional identifying information that is named in that resource. The identified secondary resource may be some portion or subset of the primary resource, some view on representations of the primary resource, or some other resource that is merely named by the primary resource.
20:51:42 [Norm]
The fragment identifier component of a URI allows indirect identification of a secondary resource by reference to a primary resource and additional identifying information. The identified secondary resource may be some portion or subset of the primary resource, some view on representations of the primary resource, or some other resource.
20:51:47 [timbl]
When an information resource has a URI and has a representation; and in the language of that representation a given string identifies a second resource, then the concatenation of the URI, a hash mark and the string form a URI for that second resource.
20:51:55 [DanCon]
hmm... I wonder if we came up with any good text when we worked in the wiki http://esw.w3.org/topic/AsUsedIn
20:52:03 [Chris]
it needs to tie it back to the resource fetched
20:52:39 [Chris]
lets avoid 'concatenation'
20:52:46 [Norm]
yes, please!
20:53:44 [DanCon]
why avoid 'concatenation'? that's what one does with #, no?
20:54:28 [Chris]
actually no, you split it off, stuff it in your back pocket, and then use it in isolation on what you got back
20:55:49 [DanCon]
hmm... ok, concat/split, same difference
20:56:06 [Chris]
no, pretty much opposites
20:56:51 [DanCon]
i.e. same situation, 2 different ways to describe it. if long=concat(short1, short2), then short1=split(short2 from long)
20:59:18 [Ian]
[TBL draws diagram on board showing splitting URI into frag id and URI-with-no-frag-id.]
20:59:59 [Ian]
IJ: It occurs to me we ought to re-use the initial diagram several times, successively elaborating it. E.g., when we talk about what a representation is, show the "REpresentation" piece as including metadata and data.
21:00:32 [Ian]
URI-with-hash IDENTIFIES Resource2
21:00:39 [Ian]
URI-with-no-hash IDENTIFIES Resource1
21:05:09 [Ian]
NW: I want to confirm that "#foo" means the same thing in all representations and if it doesn't it's a bug.
21:05:14 [Ian]
DC: Yes, I agree.
21:07:51 [Ian]
TBL: Not exactly. It can be reasonable to give back to types of things depending on the format returned (e.g., bank statement or HTML document that's kind of equivalent).
21:08:00 [DanCon]
(this is an issue on our list too...)
21:08:09 [Ian]
TBray: But they are functionally equivalent w.r.t. the user.
21:08:56 [DaveO]
Dan, you mean frag-id issue #28?
21:08:58 [Ian]
NW: Is it architecturally unsound to serve a format with content negotiation that does not define frag id semantics (e.g., serve HTML and PDF).
21:09:11 [Ian]
?
21:09:30 [Ian]
TBL: Browsers should say "There's no frag id".
21:09:41 [Ian]
DC: This is a silent recovery from error today.
21:10:30 [Ian]
CL: Are we saying it's an error to serve foo#bar if one representation doesn't define frag id semantics?
21:10:44 [Ian]
TBray: Not a server problem, but an authoring problem.
21:11:11 [Chris]
conneg and fragments considered incompatible
21:11:16 [timbl]
When an information resource has a URI and has a representation; and in the language of that representation a given string identifies a second resource, then the concatenation of the URI, a hash mark and the string forms a URI for that second resource. The MIME type registration defines this syntax and semantics of such a string.
21:11:30 [Ian]
See 2.4.1 for this discussion...
21:12:28 [Ian]
TBray: TBL means that the format spec defines the semantics of what the frag id is used for.
21:12:42 [DaveO]
q+
21:12:56 [Ian]
DC: I think it's easier to talk about splitting a URI rather than concatenating two parts.
21:13:11 [TBray]
ack TBray
21:14:44 [Ian]
TBray: Superfluous to say "info resource" since that's the kind that has representations.
21:15:11 [Stuart]
ack Dave0
21:15:16 [Chris]
so (to clarify) items 7 .. 11 on the agenda are hereby dropped
21:15:45 [TBray]
When a resource has a representation...
21:15:57 [timbl]
When a resource has a URI and has a representation; and in the language of that representation (using a syntax and semantics defined by the MIME type specification) a given string identifies a second resource, then the concatenation of the URI, a hash mark and the string forms a URI for that second resource.
21:16:00 [DanCon]
SIGH.
21:16:03 [Ian]
DC: I thought we were going to use the term information resource that we introduced earlier.
21:17:37 [Ian]
RF: I think that the existing text in RFC2396 is superior to TBL's proposal.
21:17:53 [Ian]
DC: I agree that the second para is better.
21:18:03 [Ian]
(ie.. existing text in arch doc)
21:18:32 [Ian]
RF: I think it's important to be able to define a resource with a URI that includes a frag id without having to get back a representation.
21:18:37 [Chris]
q+ to tak about delegated authority and fragments
21:18:55 [DaveO]
q-
21:19:30 [Norm]
Norm has joined #tagmem
21:20:25 [Norm]
How is this:
21:20:35 [Norm]
The fragment identifier component of a URI allows indirect identification of a secondary resource by reference to a primary resource and additional identifying information. The identified secondary resource may be some portion or subset of the primary resource, some view on representations of the primary resource, or some other resource.
21:20:44 [Norm]
The URI that identifies the secondary resource consists of the URI of the primary resource with the additional identifying information as a fragment identifer.
21:21:10 [Ian]
[Discussion of "selecive with respect to that resource"]
21:22:39 [Stuart]
q+
21:22:56 [Ian]
RF: HOw about "that is defined by that resource" instead.
21:23:06 [Ian]
RF: The MIME type is not significant here.
21:23:42 [Ian]
DC: I think RF's current text is good, and we could also include TBL's paragraph
21:24:28 [Ian]
TBray: Can we lose the word "merely"?
21:25:44 [Ian]
DC: I am ok with Norm text, but on condition that it go into 2396bis.
21:26:04 [Stuart]
q-
21:26:05 [Ian]
TBray: I think NW's second .proposal is better than TBL's:
21:26:18 [Chris]
q?
21:26:51 [DanCon]
ack chris
21:26:51 [Zakim]
Chris, you wanted to tak about delegated authority and fragments
21:27:00 [timbl]
q+ to bzzzzzzzzzzzzzzzt vague alarm
21:27:02 [Norm]
Norm has joined #tagmem
21:27:08 [Ian]
Ian has joined #tagmem
21:27:15 [Norm]
q?
21:28:31 [Ian]
CL: You don't get to fiddle around with URIs. You do, however, get to fiddle with the fragment.
21:28:32 [DanCon]
hmm... I hear a point that chris is making... but I'm not sure how to put it into an economical number of words
21:28:48 [DaveO]
Norm, I don't understand your earlier question about #foo meaning the same thing. If WSDL defines #foo to mean an abstract component *thing*, and SVG defines #foo to mean an xml element with name foo, then they don't have the same meaning.
21:29:09 [Ian]
I also think that xpointer lets you create anchors outside the original document.
21:29:43 [Ian]
So person A can create anchor in person B's representation
21:29:44 [DanCon]
so DaveO, don't make SVG and WSDL representations that use 'foo' available for the same resources
21:30:07 [Stuart]
q?
21:30:18 [DanCon]
ack timbl
21:30:18 [Zakim]
timbl, you wanted to bzzzzzzzzzzzzzzzt vague alarm
21:30:35 [Chris]
ack chris
21:30:44 [Ian]
TBL: I find NW's alternative is still vague.
21:30:55 [Ian]
TBL: If you include my paragraph after it, I will be happy.
21:31:12 [Roy]
This is what the URI spec *also* says:
21:31:21 [Chris]
dave - svg defines barename #foo to mean the xml thing because its a +xml media type
21:31:22 [Ian]
TBL: In particular, it's important to see how URIs are the same; and how to proceed with frag id.
21:31:25 [DanCon]
(stuart/ian, did we agree to include the figure from the whiteboard?)
21:31:38 [Ian]
Chris has action to do image revision.
21:31:44 [Ian]
I'd like CL to do a version of what's on board, too
21:31:46 [Chris]
dan - I believe we did and i will draw that one, too
21:31:57 [DanCon]
thx, chris
21:32:01 [Ian]
thx chris
21:32:12 [Ian]
Proposed: Include TBL para after existing para from 2396.
21:32:33 [Ian]
TBray: I prefer NW's text to that in 2396
21:32:39 [Ian]
TBray: I accept DC's caveat.
21:33:39 [Ian]
Resolved: Accept NW's second proposed text and TBL's text.
21:34:03 [Ian]
[Break]
21:34:52 [Norm]
Norm has joined #tagmem
21:38:45 [timbl]
http://www.w3.org/2001/tag/webarch/tim.html
22:00:42 [Ian]
</break>
22:00:49 [timbl]
Wheas human communication tolerates such anbiguity, machine processing does not.
22:02:01 [Ian]
[Discussion of whether Director should say ok to advance of a spec to PR (or PER) if mime type not registered.]
22:03:16 [Ian]
How to Register a Media Type with IANA (for the IETF tree)
22:03:22 [Ian]
http://www.w3.org/2002/06/registering-mediatype
22:03:25 [Ian]
Does this need updating?
22:05:01 [Ian]
----
22:05:32 [Chris]
minimally yes as it speaks of the ietf tree, should be standards tree
22:05:50 [Chris]
danc mentioned email, no ID required
22:06:17 [timbl]
Suggested text for 2.6: Whereas human communication tolerates such ambiguity, machine processing does not. Strictly, the above URI as identifies the information resource, some hypertext document. RDF applications which use it for describing properties of that page are in order; those who use its URL to directly assert properties of the whale are using it inconsistently.
22:08:31 [DanCon]
pointer to what we're looking at for the minutes? with $Date$?
22:09:23 [Ian]
Discussion of "Although the generic URI syntax allows any URI to end with a fragment identifier, some URI schemes do not specify the use of fragment identifiers. For instance, fragment identifier usage is not specified for MAILTO URIs."
22:09:34 [Norm]
Norm has joined #tagmem
22:09:39 [Ian]
RF: This is orthogonal to the URI scheme.
22:09:50 [Ian]
TBray: It's not the scheme, it's the data formats.
22:11:39 [Ian]
Resolved delete "Although the generic URI syntax allows any URI to end with a fragment identifier, some URI schemes do not specify the use of fragment identifiers. For instance, fragment identifier usage is not specified for MAILTO URIs.
22:11:40 [Ian]
"
22:12:59 [Ian]
TBray: Please see if you can either delete 2.4.1 heading or find a second heading for 2.4
22:13:01 [Chris]
>>>>>>>>>> http://www.w3.org/2001/tag/webarch/#dereference-uri <<<<<<<<<<
22:13:39 [Ian]
NW: Change in 2.4.1 "Clients should not be expected to so something..." to "It is an error..."
22:15:36 [Ian]
TBray: "It is an error condition when you have a URI with a frag id and representations don't have consistent frag id semantics..."
22:15:52 [Ian]
RF: You need to be careful: The error is not creating the identifier.
22:16:12 [Ian]
RF: You may tolerate the error in some cases.
22:16:35 [Ian]
RF: Good practice note is wrong: "Authors SHOULD NOT use HTTP content negotiation for different media types that have incompatible fragment identifier semantics."
22:18:11 [Ian]
TBray: "In the case where you use coneg to serve multiple representations, and some of those representations have inconsistent frag id semantics, then you are creating an opportunity for this error to occur."
22:18:22 [DanCon]
yes, pls strike the good practice box and replace with words ala what Bray just said
22:19:14 [Chris]
or, clarify the good practice note ... but can live with tim brays text
22:19:18 [DanCon]
NW: yup
22:19:29 [Ian]
Proposed: Revise good practice note with spirit of what TB said.
22:19:54 [Ian]
TBL: I'm ok with TB's text.
22:20:04 [Ian]
Resolved: Revise good practice note with spirit of what TB said.
22:22:19 [DanCon]
misuse from 3.3: "The simplest way to achieve this is for the namespace name to be an HTTP URI which may be dereferenced to access this material."
22:22:59 [Ian]
[Discussion of "dereference" v. "retrieve"]
22:23:06 [Roy]
q+
22:23:09 [timbl]
q+ Roy
22:23:41 [DanCon]
I like 'access' and I can live with 'retrieve' and I'd like to avoid 'dereference' if we can.
22:24:20 [Ian]
DO: Please include examples in 2.5.
22:24:24 [Norm]
Norm has joined #tagmem
22:25:01 [Ian]
TBray: I like "access" as well.
22:25:42 [Chris]
dereference is used in 2.2. URI Schemes as well
22:25:53 [Chris]
Furthermore, the URI scheme specification specifies how an agent can dereference the URI.
22:25:59 [Chris]
+1 for access
22:26:01 [Ian]
TBray: I suggest deleting "Given a URI, a system may attempt to perform a variety of operations on the resource, as might be characterized by such words as "access", "update", "replace", or "find attributes". Available operations depend on the formats and protocols that make use of URIs. "
22:27:07 [timbl]
To derefernce a URI is access the resource which it identifies.
22:27:18 [Chris]
dereference is not retrieval
22:27:29 [timbl]
necessarily
22:29:09 [DanCon]
1. rename to accessing a resource
22:29:14 [Ian]
Proposed: Delete "Given a URI, a system may attempt to perform a variety of operations on the resource, as might be characterized by such words as "access", "update", "replace", or "find attributes". Available operations depend on the formats and protocols that make use of URIs. " and "Accessing a resource" and slightly rewriting third sentence
22:29:26 [DanCon]
2nded.
22:29:32 [TBray]
+1
22:29:36 [Chris]
+1
22:29:36 [Ian]
IJ: I don't agree.
22:30:36 [Ian]
IJ: +1
22:30:49 [Ian]
Resolved: Delete "Given a URI, a system may attempt to perform a variety of operations on the resource, as might be characterized by such words as "access", "update", "replace", or "find attributes". Available operations depend on the formats and protocols that make use of URIs. " and "Accessing a resource" and slightly rewriting third sentence
22:32:06 [Ian]
DC: In 2.8.4, I prefer "access' over "resolution"
22:33:20 [Ian]
TBL: I think we can delete "resolution" from the document.
22:33:31 [Ian]
TBL: Use "access" instead.
22:33:35 [Ian]
NW: Delete "finite" from 2.5
22:34:15 [Ian]
Resolved: Delete resolution from document (replace with access where necessary).
22:34:19 [DanCon]
if you're gonna strike finite, you might as well strike 'set'
22:35:06 [DanCon]
("Resolved" was a bit hasty there... stand by...)
22:35:13 [Ian]
"While accessing a resource..."
22:35:32 [Ian]
Resolved: Delete resolution from document (replace with access where necessary).
22:36:55 [Ian]
2.5.1. Retrieving a Representation
22:37:29 [Chris]
Some URI schemes (e.g., the URN scheme [RFC 2141]) do not define dereference mechanisms.
22:38:30 [Chris]
is it tru (yes apparently) and does it contribute anything useful
22:39:34 [Chris]
okay, chris lets it slide
22:39:52 [Ian]
2.5.1. Retrieving a Representation
22:40:03 [Ian]
TBray: Potentially misleading - " The representations communicate the state of the resource."
22:40:23 [Ian]
TBray: Representation doesn't need to represent ENTIRE state of resource.
22:41:04 [Ian]
TBL: "Some or all of the state of the resource...."
22:41:05 [DanCon]
ed note: "As stated above" as a consequence of decisions we made recently.
22:41:20 [Ian]
Resolved: "communicate some or all of the state of the resource."
22:41:28 [Chris]
"is used within an a element " is vague
22:41:47 [Ian]
SW: Change "which representations are used" to "which content types".
22:41:50 [Ian]
DC, TB: No.
22:42:17 [Ian]
TBray: A server can throw your PUT on the floor.l
22:42:22 [Chris]
suggest 'is the value of an href attribute in the xlink namespace on an a element
22:42:30 [Ian]
DO: This section is about retrieving a representation.
22:42:36 [Ian]
SW: Comment withdrawn.
22:42:41 [TBray]
note that the "As stated above" reference no longer works since we nuked that section
22:42:44 [Chris]
q+ to say just that
22:42:48 [Chris]
q?
22:42:57 [Ian]
RF: This good practice note is out of place: "Owners of important resources SHOULD make available representations that describe those resources."
22:43:20 [timbl]
Note now dead link on "authority responsible for a URI"
22:43:48 [timbl]
s/that describe those/of those/
22:43:50 [Ian]
Change to "Resource representations: Owners of important resources SHOULD make available representations of those resource."?
22:43:59 [Stuart]
q?
22:44:07 [Chris]
q+ to say that "the SVG specification suggests " is weak, too
22:44:11 [Ian]
RF: I think that moves away from original intent: I think it was that owners should provide metadata.
22:44:18 [timbl]
q+ s/that describe those/of those/
22:44:23 [Ian]
DC: No, it was about not filling the Web with 404s.
22:44:24 [timbl]
q+ to say s/that describe those/of those/
22:44:40 [Ian]
DC: Drill in this good practice Note by giving a 404 example.
22:44:46 [Ian]
DC: And show that that sucks.
22:44:48 [Chris]
ack chris
22:44:48 [Zakim]
Chris, you wanted to say just that and to say that "the SVG specification suggests " is weak, too
22:44:52 [DaveO]
q+
22:45:02 [Stuart]
ack Roy
22:45:11 [DaveO]
q-
22:45:27 [DaveO]
q+ to mention representations retrieved by other methods than GET
22:45:37 [DanCon]
logger, pointer?
22:45:53 [DanCon]
RRSAgent, pointer?
22:45:53 [RRSAgent]
See http://www.w3.org/2003/07/22-tagmem-irc#T22-45-53
22:46:07 [Norm]
Norm has joined #tagmem
22:46:25 [DanCon]
22:42:22 [Chris]
22:46:25 [DanCon]
suggest 'is the value of an href attribute in the xlink namespace on an a element
22:46:54 [Ian]
IJ: Nowhere does the SVG spec say "GET".
22:46:58 [Chris]
http://www.w3.org/TR/SVG11/linking.html#Links
22:47:12 [Chris]
SVG provides an 'a' element, analogous to HTML's 'a' element, to indicate links (also known as hyperlinks or Web links). SVG uses XLink ([XLink]) for all link definitions.
22:48:50 [timbl]
q+
22:50:26 [Chris]
its the xlink href in the context of the a element and the other attributes on the a element that imply
22:51:06 [Norm]
Norm has joined #tagmem
22:51:46 [timbl]
ack tim
22:51:46 [Zakim]
timbl, you wanted to say s/that describe those/of those/ and to
22:52:36 [Chris]
xlink:show = 'new | replace'
22:52:36 [Chris]
Indicates whether, upon activation of the link, traversing to the ending resource should load it in a new window, frame, pane, or other relevant presentation context or load it in the same window, frame, pane, or other relevant presentation context in which the starting resource was loaded.
22:52:43 [DaveO]
ack daveo
22:52:43 [Zakim]
DaveO, you wanted to mention representations retrieved by other methods than GET
22:53:17 [Chris]
ACTION Chris tighten this language for SVG 1.2
22:53:27 [Ian]
DO: What do we say about POST - result of POST operation is a representation (or some data).
22:53:36 [Ian]
TBL: That's not a representation of any resource.
22:53:47 [Ian]
DO: Yes, it is, I can give it a content location.
22:54:17 [Ian]
TBray: Question, e.g., of, after an update, getting a mere 200 or getting updated text (i.e., representation).
22:54:21 [Chris]
"By activating these links (by clicking with the mouse, through keyboard input, and voice commands), users may visit these resources." is vague and wooly
22:54:27 [Ian]
[Discussion of HTML forms]
22:54:57 [Ian]
DC: I disagree that what is POSTed is a representation of the resource.
22:54:59 [Chris]
prefer sections 1 and 2 bring in the other context (element name, attributes)
22:55:08 [Ian]
(yes)
22:55:21 [Chris]
ie is not just the occurence of a bare URI on some random element that makes it be a hyperlink
22:55:41 [Ian]
[Agreement on "form data"]
22:55:51 [Norm]
Norm has joined #tagmem
22:55:53 [Norm]
q?
22:55:53 [Ian]
DO: I send form data to the server. Is what I get back a representation?
22:56:00 [Chris]
ACTION Ian, Chris discuss and propose improved wording
22:56:21 [Ian]
DC: No, it's not a representation.
22:56:35 [Ian]
RF: It is a representation.
22:56:45 [Ian]
RF: It's a representation of the response that you get back.
22:56:55 [Ian]
DC: It's not a representation of any thing the common specs give a name to.
22:57:21 [TBray]
q+
22:58:20 [TBray]
q-
22:58:21 [DaveO]
I want to make sure that we say that POST results are NOT retrieval operations.
22:58:29 [Chris]
q+ to say I believe we already agreed to this - that access is not trhe same ars retrieval
22:58:38 [Chris]
post result is not a retieval action
22:58:43 [Ian]
RF: An HTTP POST is not a retrieval action.
22:59:12 [Stuart]
ack Chris
22:59:12 [Zakim]
Chris, you wanted to say I believe we already agreed to this - that access is not trhe same ars retrieval
22:59:28 [Ian]
q+ to ask what changes are being suggested in 2.5.1
22:59:46 [timbl]
An HTTP POST is not a retreival action. Any resulting response is NOT a representation of the URI posted to.
23:00:58 [Stuart]
if the resullt includes a Location header, is the result a representation of the resource referenced by the location header?
23:01:01 [DanCon]
yes, let's use POST as an example to distinguish access from retrieval
23:03:12 [Ian]
Action IJ: Include POST (and other methods) as examples of deref methods at beginning of 2.5
23:03:35 [DaveO]
stuart, I don't think a POST that "happens" to contain a Location is a "retrieval". It's a deref, that could be followed by a retrieval on the Location URI.
23:03:37 [Chris]
in other words, make a positive statement that non-retrieval access is both possible and good if appropriate
23:03:48 [Chris]
some non-HTTP examples would be good, too
23:03:49 [Ian]
Delete editor's note in 2.5.1 since "on the web" handled earlier per today's discussion.
23:03:53 [Ian]
2.5.2. Safe Interaction
23:04:07 [Ian]
[Minor editorial only]
23:04:11 [Ian]
2.6. URI Persistence
23:05:07 [Ian]
Resolved: Delete "draft" before "TAG findings" globally.
23:05:59 [Ian]
DC: "Similarly, one should not use the same URI to refer to a person and to that person's mailbox."
23:06:16 [Ian]
DC: If you ask Mark Baker are you your mailbox, he'd say yes.
23:06:54 [Ian]
"Whereas human communication tolerates such ambiguity, machine processing does not. Strictly, the above URI as identifies the information resource, some hypertext document. RDF applications which use it for describing properties of that page are in order; those who use its URL to directly assert properties of the whale are using it inconsistently."
23:07:09 [Ian]
[Text provided by TBL]
23:07:47 [Ian]
TBL: s/URI persistence also/It is an error for a URI to identify two different things.
23:07:48 [Ian]
DC: No.
23:08:15 [Ian]
TBray: What about retitling section "Maximizing the usefulness of URIs"
23:08:18 [Chris]
2.6. URI Persistence > new title
23:08:30 [Chris]
sunsections persestence, ambiguity, reliability
23:08:37 [Ian]
"URI Persistence and Ambiguity"
23:09:02 [Ian]
RF: Are all uses of URIs for the sake of identification?
23:09:03 [Ian]
TBL: Yes.
23:09:15 [Ian]
RF: Identification of what?
23:09:34 [Ian]
RF: What about using a URI in a sentence as an indirect identifier: "I wonder whose home page is http://www.example.com/"
23:09:52 [Ian]
TBL: The URI refers to the home page...
23:11:11 [Ian]
TBL: I have a problem with sentence starting "For instance...."
23:11:43 [Stuart]
see http://lists.w3.org/Archives/Public/www-tag/2003Jul/0102.html
23:12:02 [Ian]
DC: "Whoever publishes the URI should be clear about whether it identifies the book, the whale, etc."
23:12:24 [Ian]
TBL: I don't like that in this case.
23:12:31 [Ian]
TBL: I don't want them to say it's a whale.
23:14:31 [DanCon]
DC: whale? yeah... take out the whale.
23:14:36 [TBray]
q+
23:14:40 [Ian]
q-
23:15:05 [Ian]
TBray: In TBL's proposed paragraph, I disagree with a lot and don't understand some points.
23:15:15 [Chris]
proposed addition makes invalid assertions. Some machines tolerate ambiguity very well
23:15:26 [Ian]
TBray: I don't agree with a straight assertion that machines don't tolerate ambiguity.
23:15:49 [Norm]
q+
23:16:02 [Chris]
q?
23:16:49 [Stuart]
ack TBray
23:16:55 [Stuart]
ack Norm
23:17:14 [Ian]
NW: People will make conflicting assertions. The system will have to deal with this.
23:17:24 [Ian]
NW: I'm satisfied with existing text.
23:18:40 [Ian]
TBL: I think our concern is not the ambiguity of "Moby Dick" it's the inconsistent uses of the URI.
23:18:47 [DanCon]
I'm not too happy with the moby paragraph.
23:18:54 [Ian]
TBray: When you mint a URI you need to be clear about what it identifies.
23:18:59 [Ian]
TBray: Remove the quotes...
23:19:21 [Norm]
q+
23:19:46 [Ian]
DC: I'd like a positive statement about what to do.
23:19:50 [DanCon]
and strike whale
23:19:57 [Stuart]
q+ Ian
23:20:00 [timbl]
q+ to say that anything which goes in this document should be consisetnt with HTTP resources being information resources
23:20:05 [Norm]
I don't see any reason to strike whale
23:20:09 [DanCon]
ack tim
23:20:09 [Zakim]
timbl, you wanted to say that anything which goes in this document should be consisetnt with HTTP resources being information resources
23:20:43 [Ian]
TBL: I don't want to say that the URI designates whatever the URI owner wants.
23:21:02 [DanCon]
tim's correct that this para, as written, takes a position on httpRange-14.
23:21:10 [DanCon]
ack norm
23:21:33 [Ian]
NW: Could I not write an RDF assertion that says that this URI identifies the while, then another assertion that conflicts with that?
23:21:35 [Ian]
TBL: Yes.
23:21:48 [Ian]
NW: Why is this special case so important?
23:22:10 [Ian]
TBL: Important axiom for version 2 of the arch doc - referent of an HTTP resource without a hash is an information resource.
23:23:58 [Stuart]
q+ Paul
23:24:10 [Ian]
NW: RF's the standards that we write for the sake of identification is orthogonal to the systems that make use of them.
23:24:13 [DanCon]
ack ian
23:24:20 [timbl]
Tim;'s comments was not abouyt th doc, about dan's proposal
23:25:25 [Roy]
q+
23:25:36 [Roy]
ack Roy
23:26:24 [Ian]
PC: May need, for forward compatibility, to ensure that something is an error in V1 though might be more meaningful in V2 of arch doc.
23:26:28 [Norm]
And it's too late already. The cat is out of the bag.
23:26:32 [Ian]
PC: Need to include a warning at least to users.
23:26:43 [Stuart]
q?
23:26:46 [DanCon]
hmm... a health-warning about httpRange-14 is an interesting idea.
23:26:48 [Stuart]
ack Paul
23:27:14 [Ian]
PC: Do we put something in arch doc v1 that is warning that we say "Don't do this; we think that there are arch reasons to use this form for explicit meaning and we haven't yet defined that."
23:27:38 [Ian]
RF: You can replace the URI with a URN...
23:27:45 [Ian]
DC: Or put a hash and frag id it.
23:27:50 [Ian]
s/it/in it/
23:28:53 [Stuart]
q?
23:28:54 [Ian]
DC: If you ask most people if something is a whale, and people can put it in their browser, they're likely to say "Nope, that's not a whale."
23:28:58 [Stuart]
ack DanCon
23:28:58 [Zakim]
DanCon, you wanted to note that timbl's axiom may be more widely accepted than norm suggested
23:29:20 [Ian]
NW: That argument suggests that if there's a hash mark at the end of a URI and it takes them to the middle of a document, then it's not a whale either.
23:29:29 [Ian]
TBL: If it's a hypertext document, it's never a whale.
23:29:52 [Ian]
NW: So I can't serve up with coneg a hypertext doc that describes an RDF vocab and the RDF vocab.
23:29:54 [Ian]
DC: Right.
23:30:01 [Ian]
DC: That seems problematic; and we discussed that earlier.
23:30:18 [DanCon]
... in the case of WSDL and HTML
23:30:28 [Ian]
q+ TB
23:30:29 [Ian]
ack TB
23:30:50 [Ian]
TBray: I would be ok with taking "whale" out of the sentence. I'm still not convinced of TBL's axiom.
23:31:13 [DaveO]
Dan's right, same thing with namespacename#WSDLFrag-ID and the collision between RDDL vs WSDL representations at the namespace URI.
23:31:24 [Ian]
RF: Just change the scheme name...
23:31:41 [DanCon]
... too foo: ... something unregistered
23:31:46 [Ian]
TBray: What about "Melville#moby"
23:33:11 [Ian]
Action TBL: Propose a replacement to "URI persistence ...person's mailbox".
23:33:37 [Ian]
---
23:35:22 [Ian]
[TAG accepts risk that continuing walkthrough puts other agenda items at risk.]
23:36:18 [Chris]
q+ to mention 2.7
23:36:21 [Ian]
2.7. Access Control
23:36:35 [Chris]
http://www.heise.de/newsticker/data/tig-18.07.03-000/
23:36:48 [Chris]
http://juris.bundesgerichtshof.de/cgi-bin/rechtsprechung/document.py?Gericht=bgh&Sort=3&Datum=2003&Art=pm&client=3&Blank=1&nr=26553&id=1058517255.04
23:37:39 [Ian]
[German govt ruling in favor of permissability of deep linking]
23:38:00 [Ian]
CL: TAG could update its finding to include a link to this.
23:38:27 [TBray]
Typo: two quotes before the word Deep ("')
23:38:28 [Ian]
Action IJ: Update Deep linking finding (new revision) with reference to this decision.
23:38:53 [Ian]
2.8. Future Directions for Identifiers
23:39:02 [DanCon]
ed: 2.8 has no text before 2.8.1
23:39:15 [Ian]
2.8.2. Determination that two URIs identify the same resource
23:39:25 [Ian]
TBray: Pay Hayes says we're wrong on this.
23:39:28 [Chris]
2.8.1 no-one had any objections to the text
23:39:28 [Ian]
DC: I disagree with him.
23:39:59 [Ian]
2.8.3. Consistency of fragment identifier semantics among different media types
23:41:01 [Chris]
2.8.3 first para on automagic fragment conversion is hazy and likely not possible in general
23:41:07 [Chris]
suggest dropping it
23:41:13 [Ian]
TBL: There was discussion in HTTP community about putting frag id in headers.
23:41:28 [Ian]
Resolved: Delete "There has been some discussion but no agreement that new access protocols should provide a means to convert fragment identifiers according to media type."
23:41:50 [Chris]
2.8.3 in entirity hits the dust
23:41:52 [Ian]
Delete 2.8.3, distributing refs to issues elsewhere.
23:42:00 [Ian]
Action DC:
23:42:08 [Ian]
Include pointers in 2.8.5 to such systems.
23:42:09 [Chris]
2.8.5 needs more clarity and pointers
23:42:13 [Ian]
(e.g., freenet)
23:42:50 [Roy]
Roy has left #tagmem
23:43:15 [Ian]
Action IJ: Add text to 2.8 before 2.8.1 giving context (e.g., work going on in community, no guarantee that TAG will do this work)
23:43:54 [Ian]
TBray: This is a survey of the landscape; not a commitment to actions.
23:44:04 [Ian]
PC: And do this in 2, 3, 4.
23:45:18 [Ian]
SW: Meeting resumes at 8:30 tomorrow. Door open at 8am
23:45:21 [Ian]
ADJOURNED
23:45:24 [Ian]
RRSAgent, stop