IRC log of tagmem on 2003-07-23

Timestamps are in UTC.

15:35:30 [Zakim]
Zakim has joined #tagmem
15:35:30 [Norm]
Norm has joined #tagmem
15:36:49 [DaveO]
DaveO has joined #tagmem
15:37:14 [Norm]
Nope
15:37:17 [DaveO]
nope
15:38:17 [timbl]
timbl has joined #tagmem
15:38:31 [IanYVR]
Roll call: NW, TBL, TB, RF, DO, DC, PC, SW, IJ
15:39:32 [DanCon]
DanCon has joined #tagmem
15:40:08 [DanCon]
DanCon has joined #tagmem
15:44:15 [IanYVR]
[Looking at TBL's action item from yesterday; a rewrite]
15:44:32 [IanYVR]
http://www.w3.org/2001/tag/webarch/tim
15:44:49 [IanYVR]
section 2.6
15:47:04 [IanYVR]
I think that we need to make "URI Ambiguity is the use of the same URI to refer to more than one distinct thing. It should be avoided." a point if it's to be included.
15:47:49 [IanYVR]
q?
15:48:11 [TBray]
TBray has joined #tagmem
15:50:38 [TBray]
q+
15:52:38 [IanYVR]
Action TBL: Continue to revise section 2.6 in http://www.w3.org/2001/tag/webarch/tim
15:53:04 [Roy]
Roy has joined #tagmem
15:53:36 [Chris]
Chris has joined #tagmem
15:53:47 [IanYVR]
http://www.w3.org/2001/tag/webarch/#representations
15:53:51 [IanYVR]
3. Representations
15:54:50 [TBray]
ack TBray
15:55:05 [Chris]
q+ to quibble slightly about point 5 in 3.0
15:55:06 [IanYVR]
RF: Delete "(see the section on interactions for information about message protocols)" since not there yet...
15:55:29 [Stuart]
q+
15:55:56 [Chris]
q+ 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
15:56:17 [IanYVR]
DO: I would like us to clarify relationship between messages and representations and how agents use them.
15:56:30 [Chris]
q+ on record to "User agents must not silently ignore authoritative server metadata. and to request clarification on "3.2 and semantics"
15:56:49 [Chris]
q+ to note a dissent on record to "User agents must not silently ignore authoritative server metadata. and to request clarification on "3.2 and semantics"
15:58:45 [IanYVR]
TBray: Please write a story showing relationship between messages and representatoins.
16:00:52 [IanYVR]
[Discussion of messages and their relation to section 3]
16:01:30 [TBray]
q+
16:02:26 [Stuart]
q-
16:02:55 [DaveO]
q+
16:03:17 [DanCon]
(Dave, did you say section 3 as written mixes up representations and messages? where?)
16:03:42 [Chris]
(message bodies and their relation to representations)
16:03:47 [DanCon]
that=??
16:04:01 [Chris]
(especially as we have representations = bits + metadata)
16:04:04 [Roy]
q+
16:04:05 [Chris]
ack chris
16:04:05 [Zakim]
Chris, you wanted to quibble slightly about point 5 in 3.0 and to worry about "3. The representation consists those bits that would not change regardless of the transfer protocol
16:04:08 [Zakim]
... used to exchange them. and to note objection and to note a dissent on record to "User agents must not silently ignore authoritative server metadata. and to request
16:04:10 [Zakim]
... clarification on "3.2 and semantics"
16:04:22 [DanCon]
ack tbray
16:04:33 [DanCon]
q+chris
16:04:40 [timbl]
We need to be clear on the relationship between messages and representatoins now, even though we will do messages in section 4.
16:04:43 [DaveO]
Dan, I sent in email on describing the relationship between messages and representations a while ago..
16:05:17 [IanYVR]
TBray: I think it's a good idea to continue the story with a GET lookup (a msg), you get a response, you do a POST (with data that is not a representation of the URI you posted to).
16:05:25 [DanCon]
does it say which text in section 3 mixes up the concepts, daveo?
16:05:51 [IanYVR]
TBray: I volunteer to write the story.
16:05:55 [IanYVR]
IJ: I think belongs in section 4
16:06:02 [IanYVR]
(too detailed if up front)
16:06:08 [Stuart]
ack DaveO
16:06:28 [IanYVR]
DO: In section 3, we want to talk about formats, but we use messages to do stuff. There is more in the message than just representations.
16:07:15 [DanCon]
ack roy
16:07:17 [TBray]
TBray has left #tagmem
16:07:21 [IanYVR]
DO: Perhaps we have the order of 3 and 4 wrong.
16:07:23 [IanYVR]
RF: I agree.
16:07:23 [Stuart]
ack Roy
16:07:28 [DanCon]
ack danc
16:07:28 [Zakim]
DanCon, you wanted to suggest removing discussion of messages from section 3 on Representations; if we need to elaborate the stub in section 4 to make things clear, so be it
16:07:29 [timbl]
+1
16:07:46 [IanYVR]
DC: I suggest moving stuff on msgs out of 3 to section 4.
16:07:50 [timbl]
to switching 3 and 4
16:07:59 [TBray]
TBray has joined #tagmem
16:08:04 [Chris]
+1
16:08:58 [IanYVR]
Action DO: Continue Oaxaca story for beginning of section on messages, showing GET (with details) and POST (with details).
16:09:12 [IanYVR]
Resolved: Swap sections 3 and 4.
16:09:29 [IanYVR]
SW: "A representation is data that represents or describes the state of a resource."
16:09:41 [DanCon]
+1
16:09:43 [IanYVR]
SW: Are "respresents" and "describes" synonymous? If not pick one.
16:10:09 [timbl]
No
16:10:53 [ndw]
introduces ambiguity and should be avoided.
16:10:53 [ndw]
For example, suppose one part of an enterprise collects information
16:10:53 [ndw]
about web pages including who created them and when. It is natural to
16:10:53 [ndw]
identify the web pages with their URI. Suppose further that another
16:10:54 [ndw]
part of the enterprise collects information about companies, including
16:10:58 [IanYVR]
IJ: "The representation of the state of a resource consists of ...."
16:10:58 [ndw]
who created them and when. If the same URIs are used to identify the
16:11:00 [ndw]
companies, ambiguity is introduced. A system that attempts to merge
16:11:02 [ndw]
these two distinct data sets is likely to encounter problems
16:11:04 [ndw]
distinguishing between the creators and creation times of the
16:11:06 [ndw]
companies and the web pages.
16:11:08 [ndw]
One way to compensate for this ambiguity is with indirect
16:11:10 [ndw]
identification. Rather than identifying companies, for example, by the
16:11:10 [DanCon]
IJ: we already got rid of "describes a resource" earlier
16:11:14 [ndw]
URIs of their home pages, identify them indirectly. Example
16:11:17 [ndw]
Corporation is not http://www.example.com/, it is the company with the
16:11:18 [ndw]
home page http://www.example.com/.
16:11:19 [Chris]
this is a multipart q
16:11:21 [IanYVR]
[There is support for IJ's reproposed first sentence"
16:11:22 [ndw]
oops
16:11:22 [IanYVR]
]]
16:11:41 [DaveO]
Dan, my comments were at http://lists.w3.org/Archives/Public/www-tag/2003Jul/0069.html
16:11:57 [Chris]
The representation consists those bits that would not change regardless of the transfer protocol used to exchange them
16:12:15 [DanCon]
presto, they still are, dave. :)
16:12:23 [IanYVR]
CL: "The representation consists those bits that would not change regardless of the transfer protocol used to exchange them."
16:12:43 [IanYVR]
RF: The information doesn't change.
16:13:05 [IanYVR]
RF: On the wire is a message. The representation is within the message body.
16:13:08 [DaveO]
q+
16:14:27 [DanCon]
I don't see how past tense helps.
16:14:38 [IanYVR]
TBray: Representation data/metadata is independent of the protocol that was used to exchange it.
16:14:58 [Chris]
+1 for tbray wording
16:14:59 [IanYVR]
DO: Difference between abstract state of representation and actual bits needs to be clarified.
16:15:05 [TBray]
q+
16:15:20 [IanYVR]
RF: You're mixing two different things. The representation IS the bits.
16:15:31 [Stuart]
ack Dave0
16:15:43 [TBray]
ach DaveO
16:15:45 [TBray]
ack daveO
16:16:06 [IanYVR]
TBray: The representation is a bag of bits.
16:16:18 [IanYVR]
TBray: The bag of bits that gets sent is the same that gets sent whatever the protocol.
16:16:21 [Chris]
q+ When Dan made the request. Since the weather in Oaxaca changes, Dan should expect that representations will change over time.
16:16:44 [IanYVR]
TBL: Please state this positively instead of negatively.
16:17:24 [IanYVR]
IJ: I don't think "past tense" helps.
16:17:43 [timbl]
Negative: The representation consists those bits that would not change regardless of the transfer protocol used to exchange them.
16:20:14 [Chris]
ACTION chris ensure that SVG is clear on CE vsCTE
16:20:19 [Chris]
ack chris
16:21:11 [DanCon]
ack dan
16:21:11 [Zakim]
DanCon, you wanted to suggest removing stuff about messages from sectino 3 and to suggest spelling out the gzip case, but in section 4
16:21:16 [IanYVR]
"Representation data/metadata is independent of the protocol used to exchange it (e.g., of gzip)"
16:21:54 [timbl]
q+ he representation contains information about the content, and the interpretation of the concept. (Representations can be included in messages [seee section 4
16:21:59 [TBray]
q+ timbl
16:22:07 [IanYVR]
DC: Move "When agents....to exchange them."
16:22:14 [DanCon]
ack tbray
16:22:18 [timbl]
q+ to The representation contains information about the content, and the interpretation of the concept. (Representations can be included in messages [seee section 4
16:22:55 [IanYVR]
TBray: Show point about representation bits being independent of messages using gzip example.
16:22:55 [Chris]
q+ to request back ref from point 5 to consistency
16:22:58 [DanCon]
+1 to what tbray said
16:23:07 [Stuart]
ack timbl
16:23:07 [Zakim]
timbl, you wanted to The representation contains information about the content, and the interpretation of the concept. (Representations can be included in messages [seee section 4
16:23:19 [timbl]
] but in that case the repreentation does not consisred to include the message)
16:23:29 [IanYVR]
TBL: Don't define representation in terms of substracting from one particular use.
16:23:33 [IanYVR]
(namely messages)
16:24:38 [IanYVR]
SW: Change "bag of bits" to something else.
16:24:55 [IanYVR]
TBL: "Sequence of octets"
16:25:35 [timbl]
q+
16:26:24 [IanYVR]
TBL: In short, get rid of "The representation consists those bits that would not change regardless of the transfer protocol used to exchange them." since this defines in terms of subtraction.
16:26:26 [TBray]
q+
16:27:23 [IanYVR]
[Discussion about layering]
16:29:44 [IanYVR]
TBray: At this level we make clear that representation is a sequence of octects.
16:30:12 [IanYVR]
CL: Please make clear when you change abstraction layer from sequence of octets to higher up.
16:30:37 [Chris]
ok, happy once we agree to clearly signal any layer changes in course of section 3
16:32:21 [TBray]
Say it now and say it loud, I'm a PEDANT and I'm proud!
16:32:58 [IanYVR]
TBL: What am I looking at when I do view source of an email message?
16:33:04 [IanYVR]
RF: You're looking at the message source.
16:33:39 [Chris]
timbl reads out a sequence of characters
16:34:22 [IanYVR]
RF: I think it's worth making distinction between msg metadata and representation data.
16:35:15 [IanYVR]
Three terms: msg metadata, representation metadata, representation data.
16:37:20 [Chris]
q?
16:38:12 [IanYVR]
DO: I am bothered by definition of "representation" including metadata about the data.
16:39:06 [IanYVR]
TBL: Formally, the JPEG bits, you can't use unless you have wrapper as well.
16:39:18 [IanYVR]
s/wrapper/metadata
16:40:52 [DanCon]
RF: Does the meaning of a message change if you change just the media type? yes.
16:41:10 [DanCon]
... hence media type is part of representation
16:41:20 [IanYVR]
CL: Point 5 of numbered list: "When Dan made the request. Since the weather in Oaxaca changes, Dan should expect that representations will change over time."
16:41:37 [DaveO]
We should give that same example/analogy in our document
16:41:37 [DanCon]
Bray: I'll try to make that point about why media type is part of representation in the story... jpeg of sky...
16:41:41 [IanYVR]
CL: Link back to section on consistency of representatoins from bullet 5.
16:41:49 [DaveO]
thanks tim..
16:42:18 [IanYVR]
3.1. Authoritative representation metadata
16:42:32 [Roy]
q+
16:42:54 [IanYVR]
CL: Please also point out at end of 3.1 that servers should not make up metadata when they are not sure.
16:43:38 [IanYVR]
CL: I'd like to elevant "inconsistency". Say that IT IS BAD. There are interoperability (serious) issues.
16:43:53 [Roy]
ack Chris
16:43:53 [Zakim]
Chris, you wanted to request back ref from point 5 to consistency
16:44:10 [Chris]
maybe 'don't cause errors silently' as well ;-)
16:45:04 [IanYVR]
IJ: Where do we say "Don't recover from errors silently." ?
16:45:10 [IanYVR]
DC: When you are designing anything....
16:45:27 [IanYVR]
TBray: I think it's appropriate to say in detail in each section.
16:46:28 [IanYVR]
q?
16:46:48 [IanYVR]
Tim Bray, could you include the point about not recovering from error silently in your story?
16:46:53 [Chris]
q+ to discuss in 3.2 "There SHOULD be a normative specification which is a stable and widely available Web resource. "
16:46:57 [DanCon]
Bray: say "silent recovery from errors considered harmful" as many times as it comes up in the document.
16:46:58 [DanCon]
DC: ok.
16:47:03 [TBray]
no, probably not
16:47:23 [IanYVR]
TBL: In "there may be inconsistencies", don't use "may" since it seems to allow it.
16:47:39 [TBray]
q-
16:47:54 [Stuart]
ack timbl
16:48:02 [Stuart]
ack Roy
16:48:14 [IanYVR]
RF: In 3.1, "As discussed above, the owner of a resource "... this is referring to authority, which we removed yesterday.
16:48:37 [IanYVR]
TBray: Just delete "As discussed above".
16:48:58 [IanYVR]
RF: In first bullet of 3.1, delete "Unicode" and "(XML Document)"
16:49:11 [IanYVR]
RF: Both bullet points in 3.1 should refer to representations, not message bodies.
16:49:13 [DanCon]
I wonder if "encoding" is sorta backwards; one encodes a sequence of characters into the sequence of bytes.
16:51:07 [TBray]
q+
16:52:17 [IanYVR]
TBray: "The actual encoding of the representation data is inconsistent with the character encoding of the representation metadata."
16:52:30 [Chris]
no
16:52:38 [IanYVR]
TBray: "The actual character encoding of the representation data is inconsistent with the character encoding specified by the representation metadata."
16:52:49 [TBray]
The actual character encoding of the representation is inconsistent with the charset parameter in the message headers.
16:52:49 [Chris]
no 2
16:52:58 [Chris]
yes to tim bray
16:53:33 [Chris]
except for message
16:53:59 [IanYVR]
The actual character encoding of the representation is inconsistent with the charset parameter [in the representation metadata].
16:54:02 [Chris]
in the representation metadata
16:54:05 [timbl]
q+ to point out "format" is used here in the sense of "MIME Type".
16:54:45 [DanCon]
hmm... "Representations and Formats" would be a better section title, for me.
16:55:19 [IanYVR]
q+
16:55:22 [IanYVR]
q-
16:55:25 [TBray]
q-
16:55:44 [TBray]
q+
16:56:17 [DanCon]
ack timbl
16:56:17 [Zakim]
timbl, you wanted to point out "format" is used here in the sense of "MIME Type".
16:56:29 [IanYVR]
TBray: "Format" is used in the sense of MIME type.
16:56:32 [Chris]
ok so we need to edit this sentence in 3.0
16:56:38 [Chris]
"The Internet Media Type is the key to the correct interpretation of a resource representation, and governs the handling of fragment identifiers. "
16:57:21 [Chris]
timbl, that sentence is where your clarification should go, i believe
16:57:22 [DanCon]
RF: "Content-Type" is a header field. always. "media type" is the value inside the content type header
16:57:49 [DanCon]
RF: 'mime type' is passe. 'media type' is the modern thing
16:58:00 [timbl]
Chris, that sentence doe snot mention the workd "format".
16:58:02 [Chris]
format is defined in the content type
16:58:03 [DanCon]
Bray: we should point that terminology out
16:58:05 [IanYVR]
TBray: Include a footnote with example, to clarify content type, media type
16:58:11 [DanCon]
IJ: yeah... a footnote or some such
16:58:11 [IanYVR]
(and mime type)
16:58:25 [DanCon]
ack ian
16:58:33 [Chris]
timbl, from the context, that is where you should add it
16:58:58 [DanCon]
Ian: should we use format in some meaning distinct from internet media type?
16:58:58 [Roy]
q+, comments on section 3.2
16:58:59 [IanYVR]
TBL: I'd like you to tie "format" and "media type" irrevocably together in the document.
16:59:19 [DanCon]
TimBL: no, please connect 'format' with 'internet media type' firmly
16:59:50 [IanYVR]
TBL: "Is the key to" is a fudge phrase.
17:00:01 [Stuart]
q?
17:00:38 [IanYVR]
IJ: I think "format specification" is useful.
17:00:40 [TBray]
q-
17:00:53 [DanCon]
TimBL: let's keep 'format'
17:01:18 [Roy]
ack Chris
17:01:18 [Zakim]
Chris, you wanted to discuss in 3.2 "There SHOULD be a normative specification which is a stable and widely available Web resource. "
17:03:13 [DanCon]
Chris: let's either change to MAY or give some exceptions
17:04:32 [Stuart]
q?
17:05:28 [Stuart]
ack DanCon
17:05:31 [IanYVR]
q+
17:05:41 [Stuart]
ack Roy
17:05:41 [Zakim]
Roy, you wanted to make comments on section 3.2
17:05:49 [IanYVR]
RF: Last three bullets have nothing to do with interoperability.
17:05:58 [IanYVR]
RF: Put them somewhere else.
17:06:09 [IanYVR]
TBray: I think bullet 5 could stay there.
17:06:24 [IanYVR]
RF: I just think we have other places to say these last three things.
17:06:39 [IanYVR]
TBray: I suggest moving bullet 4 to linking.
17:07:13 [IanYVR]
TBray: Move bullet 5 to section 2.
17:07:27 [Chris]
move to 3.2.1
17:07:40 [IanYVR]
TBray: Move 5 and 6 to linking section below.
17:07:40 [DaveO]
q+ to mention his comments on extensibility and versioning for shoulds of format specifications.
17:07:49 [Stuart]
q?
17:07:52 [IanYVR]
TBray: In 3.2.4
17:08:03 [IanYVR]
TBray: Maybe not bullet 6...
17:08:15 [DanCon]
ack ian
17:08:15 [Stuart]
ack Ian
17:08:18 [timbl]
q+ To edit teh qnames line
17:08:56 [IanYVR]
IJ: Should I make first three bullets good practice notes.
17:09:06 [IanYVR]
TBray: Move 4, 5 to 3.2.4
17:09:14 [IanYVR]
TBray: Make them good practice notes as well.
17:09:38 [IanYVR]
TBray: Move bullet 6 to section on XML.
17:09:41 [IanYVR]
[Agreement]
17:09:43 [DanCon]
yes, pls
17:09:47 [Stuart]
ack DanCon
17:09:47 [Zakim]
DanCon, you wanted to ask what the editor expects to do with the 'format' term
17:10:22 [Chris]
ij: timbl would like format and media type to be wedded for eternity
17:10:42 [Stuart]
ack Dave0
17:10:43 [Chris]
ij: plan to talk about xml as a format representation
17:10:44 [timbl]
"format" must be introduced as being used in the sense of "Internet Media Type"
17:10:45 [DaveO]
q+ to ask that formats, languages, documents, representations be connected
17:10:48 [IanYVR]
DC: Please bold "format" when connected to internet media type
17:11:02 [DanCon]
ack daveo
17:11:02 [Zakim]
DaveO, you wanted to mention his comments on extensibility and versioning for shoulds of format specifications. and to ask that formats, languages, documents, representations be
17:11:05 [Zakim]
... connected
17:11:09 [timbl]
RESOLVED "format" must be introduced as a <defn> as being used in the sense of "Internet Media Type"
17:11:38 [DanCon]
wow... extensibility is the main architectural issue about representations, for my money. +1 to DaveO
17:11:51 [TBray]
q+ to grumble about 3.2.1
17:13:05 [Chris]
q+ to grumble about the level of nesting producing 3.2.2.1. Binary v. Textual
17:13:16 [Stuart]
ack timbl
17:13:16 [Zakim]
timbl, you wanted to edit teh qnames line
17:13:22 [IanYVR]
Resolved: Create new section 3.2.1 for first three bullets on the use of standards.
17:13:27 [Stuart]
ack Tray
17:13:31 [Stuart]
ack TBray
17:13:31 [Zakim]
TBray, you wanted to grumble about 3.2.1
17:13:55 [IanYVR]
3.2.1. Desirable Characteristics of Format Specifications
17:14:08 [IanYVR]
q+
17:14:11 [DanCon]
-1 to bray; our customer base includes authors
17:14:16 [IanYVR]
TBray: Lose user/author points
17:14:29 [IanYVR]
TBray: Add I18N
17:14:29 [Chris]
q+ to disagree with timbray on wat he just said about usability and authoring
17:14:35 [Chris]
q?
17:14:42 [DaveO]
q+ to ask that formats, languages, vocabularies, media types, representations, messages, documents be clarified, related, diagramed.
17:14:45 [Stuart]
q+
17:14:48 [DanCon]
ack chris
17:14:48 [Zakim]
Chris, you wanted to grumble about the level of nesting producing 3.2.2.1. Binary v. Textual and to disagree with timbray on wat he just said about usability and authoring
17:14:50 [Stuart]
ack Chris
17:15:04 [IanYVR]
CL: Can we flatten the toc, please?
17:15:35 [IanYVR]
CL: I disagree about removing user, author needs.
17:16:01 [timbl]
q+ to users
17:16:05 [DanCon]
chris, which is the fundamental thing of the web per bos?
17:16:12 [Stuart]
q?
17:16:19 [DanCon]
ack dancon
17:16:19 [Zakim]
DanCon, you wanted to endorse having a subsection on extensibility
17:16:23 [Stuart]
ack DanCon
17:16:33 [IanYVR]
DC: For my issue, extensibility is the main arch point.
17:16:35 [Stuart]
ack Ian
17:17:45 [Chris]
please make them point to further reading eg on simplicity of authoring (see Bert Bos writings on subject) and user needs (see Steven pemberton essays)
17:17:57 [DanCon]
pointer to pemberton essay?
17:18:22 [IanYVR]
TBL: "Further light reading"
17:18:22 [Chris]
not to hand currently
17:19:08 [Stuart]
ack DaveO
17:19:08 [Zakim]
DaveO, you wanted to ask that formats, languages, vocabularies, media types, representations, messages, documents be clarified, related, diagramed.
17:19:10 [IanYVR]
IJ: My proposal was to delete author/programmer/user needs and point to other resources.
17:19:14 [Roy]
q+
17:19:28 [Chris]
got it
17:19:29 [Chris]
http://www.nist.gov/cgi-bin/exit_nist.cgi?url=http://www.w3.org/2002/Talks/1104-usability-workshop/
17:19:44 [IanYVR]
DO: Try to reduce number of terms, and diagram how they are related.
17:19:46 [DanCon]
the heading "3.2.1. Desirable Characteristics of Format Specifications" could go, for me. promote the things under it or something. (just a suggestion)
17:19:49 [Roy]
q-
17:20:07 [DanCon]
thx for the pointer, chris.
17:20:46 [DanCon]
... but the pointer has gone 404
17:20:50 [IanYVR]
TBray: I think "vocabulary" is ok to refer to a set of tags.
17:21:02 [IanYVR]
TBL: It's used in RDF as well (set of props and classes).
17:21:11 [Stuart]
q-
17:21:14 [DanCon]
er.. no, not 404, but some wierd javascript redirect to http://www.w3.org/2002/Talks/1104-usability-workshop/
17:21:21 [Chris]
right - why is 3.2.1. Desirable Characteristics third level but 3.3. XML-Based Representations is second level
17:21:41 [IanYVR]
There is agreement that we need to be careful when we use terms.
17:21:55 [Roy]
q+
17:23:02 [IanYVR]
IJ: I think that a series of diagrams better than one to show all term relationships.
17:23:10 [Chris]
(linked from http://zing.ncsl.nist.gov/uig_w3c/presentations.html)
17:23:19 [IanYVR]
DO: I think that we have two types of digrams.
17:23:22 [Chris]
Presentations for the Workshop on Usability and the Web
17:23:25 [Stuart]
ack timbl
17:23:25 [Zakim]
timbl, you wanted to users
17:23:25 [DanCon]
of course diagrams are high-cost, TBray; do you discount their value?
17:23:41 [Chris]
chris puts high value on diagrams
17:24:40 [DanCon]
(I don't think the layer cake is a particularly good success story in diagrams. it confuses as much as it clarifies)
17:24:50 [IanYVR]
Mmm, cake.
17:25:26 [IanYVR]
TBL: Don't confuse what makes a good format and what makes a good spec.
17:25:48 [IanYVR]
TBL: The message is "be aware of the different audiences of your specification"
17:26:44 [DaveO]
Ian, my comments are really: reduce the number of terms, rigorously define the terms AND the formal relationship between the terms, and show the appropriate relationships in diagram form.
17:27:17 [Stuart]
+1 to DaveO
17:27:20 [DanCon]
daveo, any particular cases where we have more terms than we need?
17:27:33 [IanYVR]
TBL: Section 3.2.1 talks about both formats and specs. Please just focus on properties of specs.
17:27:38 [Stuart]
q?
17:27:45 [IanYVR]
TBray: But error handling and info hiding is really about the format.
17:27:55 [IanYVR]
TBray: Maybe that's a useful rhetorical technique.
17:28:01 [DaveO]
Dan, I think the relationship between format/language/vocabulary is confusing. Is somebody a format author, an language author and/or a vocabulary author?
17:28:11 [IanYVR]
q?
17:28:14 [DanCon]
got it, dave
17:28:14 [IanYVR]
ack Roy
17:28:23 [Stuart]
ack Roy
17:28:31 [IanYVR]
RF: In section on error-handling, please delete first sentence.
17:28:40 [IanYVR]
d/Given that representations are generated by humans (either coded directly or mediated by an authoring tool) and then transmitted in a heterogeneous network, it is inevitable that errors will occur.
17:28:55 [DaveO]
And how does a "specification" relate to a format? Are they the same? When are they different? Are they different aspects?
17:29:11 [IanYVR]
A format specification defines a format
17:29:16 [IanYVR]
A protocol specification defines a protocol
17:29:36 [IanYVR]
[Agreement to delete sentence per RF's suggestion]
17:29:38 [IanYVR]
<break>
17:29:48 [DaveO]
Is a specification a schema? Or is a schema a type of a document that makes up a specification?
17:43:01 [Roy]
Roy has left #tagmem
17:51:41 [IanYVR]
</break>
17:53:05 [IanYVR]
3.2.2. Taxonomic Categorization of Data Formats
17:53:34 [IanYVR]
3.2.2.2. Final-form v. Reusable
17:53:56 [IanYVR]
SW: Is comment about XSL-FO in para three a swipe?
17:53:58 [IanYVR]
TBray: No.
17:54:07 [IanYVR]
[Paul returns to meeting]
17:54:32 [IanYVR]
Reviewing "In general XML-based data formats are more re-usable and repurposable than the alternatives, although the example of XSL-FO shows that this is not an absolute.
17:54:32 [IanYVR]
"
17:54:52 [IanYVR]
3.2.2.1. Binary v. Textual
17:55:13 [IanYVR]
RF: "All things being equal (a rare state of affairs) textual formats are generally preferable to binary ones in Web applications."
17:55:18 [IanYVR]
RF: Please say for what.
17:55:32 [IanYVR]
CL: What about audio streaming?
17:55:40 [IanYVR]
TBray: Clearly that's a specialized situation.
17:56:16 [IanYVR]
TBray: I firmly believe that if you are evaluating a design for a new format, you should arrange to do it in a text format if that can be done.
17:56:18 [IanYVR]
q?
17:57:01 [IanYVR]
CL: How about "if you're choosing between a binary format and a textual format, and they are aobut the same size, then pick textual since there are lots of advantages"
17:57:24 [timbl]
Text-based formats are recommended when the amount of data is small, and inspectable for
17:57:40 [IanYVR]
TBray: It is advantageous for formats to be textual rather than binary.
17:57:57 [IanYVR]
TBL: However, text based formats have a large overhead for large datasets.
17:58:30 [IanYVR]
Resolved: Delete "All things being equal (a rare state of affairs) textual formats are generally preferable to binary ones in Web applications."
17:58:42 [IanYVR]
Action CL: Propose a replacement sentence.
17:58:50 [IanYVR]
(with TB)
17:59:10 [timbl]
q+ to say 3.2.2.2 needs a pointer to presentation vs content
17:59:22 [Chris]
+1 to cl text above ;-)
17:59:30 [IanYVR]
Action IJ: Add link from issues list binaryXML-30 to upcoming workshop
17:59:51 [Roy]
Roy has joined #tagmem
18:00:03 [DanCon]
I invite somebody (Chris?) to notify www-tag about the workshop.
18:00:04 [IanYVR]
3.2.2.2. Final-form v. Reusable
18:00:12 [timbl]
q?
18:00:22 [Roy]
q+
18:00:22 [TBray]
ack timbl
18:00:23 [Zakim]
timbl, you wanted to say 3.2.2.2 needs a pointer to presentation vs content
18:00:27 [Chris]
q+ to link final form to 'means nothing' in sonpres-26
18:00:29 [Stuart]
ack timbl
18:00:38 [IanYVR]
TBL: "Final-form v. Reusable" is close to content v. presentation. We should at least link them if not merge them.
18:01:08 [IanYVR]
TBL: And include a link to contentPresentation link.
18:01:17 [IanYVR]
TBL: We may be confusing people by using new terms for old concepts.
18:01:19 [Stuart]
ack Roy
18:01:24 [IanYVR]
RF: +1 to TBL's comment.
18:01:28 [IanYVR]
RF: Delete third para.
18:02:11 [IanYVR]
Resolved: Delete "In general XML-based data formats are more re-usable and repurposable than the alternatives, although the example of XSL-FO shows that this is not an absolute.
18:02:11 [IanYVR]
"
18:02:40 [Chris]
delete 3.2.2.2. Final-form v. Reusable
18:03:10 [Stuart]
q?
18:03:12 [Chris]
discuss in 3.2.3. Presentation, Content, and Interaction
18:03:26 [IanYVR]
Proposed:
18:03:33 [IanYVR]
- Merge 3.2.2.2 with content presentation stuff
18:03:46 [IanYVR]
- Elevant 3.2.2.1 and 3.2.2.3 to higher level.
18:03:47 [Stuart]
ack Chris
18:03:47 [Zakim]
Chris, you wanted to link final form to 'means nothing' in sonpres-26
18:04:08 [Chris]
chris has said that already by now
18:05:36 [IanYVR]
3.2.2 binary v. textual
18:05:44 [IanYVR]
3.2.3 composable v. standalone
18:05:53 [IanYVR]
3.2.3 content v. presentation AND final-form v. reusable
18:06:05 [IanYVR]
3.2.43 content v. presentation AND final-form v. reusable
18:06:08 [Roy]
ack Roy
18:06:08 [Zakim]
Roy, you wanted to talk about confusion of representation and web page in 3.2.2.3
18:06:12 [Chris]
3.2.4 on that ;ast one
18:06:13 [Stuart]
ack Roy
18:06:17 [IanYVR]
3.2.2.3. Composable v. Standalone
18:06:26 [IanYVR]
RF: "it is not typically embedded in representations encoded in other formats."
18:06:39 [IanYVR]
RF: I don't understand what 3.2.2.3 is about.
18:07:54 [IanYVR]
DO: Container v. something that fits inside a container.
18:08:06 [timbl]
q+ to criticize "Composable" para 1
18:08:13 [IanYVR]
RF: Does this include issues like including non-xml in xml?
18:08:35 [IanYVR]
RF: SOAP header designed to fit inside a SOAP header.
18:08:47 [Stuart]
q+ Paul
18:08:49 [timbl]
q+ paul
18:09:02 [IanYVR]
RF: SOAP envelope provides container. Then there's the notion of something that fits inside a container v. something that can be outside on its own.
18:09:02 [IanYVR]
q?
18:09:12 [IanYVR]
ack timbl
18:09:12 [Zakim]
timbl, you wanted to criticize "Composable" para 1
18:09:20 [IanYVR]
TBL: 3.2.2.3 as written is confused.
18:09:45 [TBray]
q+
18:09:50 [IanYVR]
TBL: Is "composability" about things that enclose or things that are enclosed?
18:10:16 [IanYVR]
ack Paul
18:10:16 [DaveO]
q+ to say there are 3 concepts: standalone, containers, and container extensions
18:10:32 [Chris]
q+ to note that PDF can enclose svg which can point to JPEG, nowadays
18:10:47 [IanYVR]
PC: DO is right. The major feature of SOAP that distinguishes it from other formats is its extensibililty points: headers, body (and intermediaries).
18:10:56 [IanYVR]
PC: Major arch design of SOAP is its extensibility.
18:11:41 [Chris]
however, I do like composability as a term
18:11:55 [Stuart]
q?
18:11:57 [IanYVR]
RF: You can put images inside a PDF document.
18:12:01 [IanYVR]
TBray: And XML as well.
18:12:14 [IanYVR]
TBray: I think that 3.2.2.3 is hopelessly muddled. Candidate for termination...
18:12:20 [Chris]
nononono
18:12:47 [IanYVR]
TBray: "Composability" here is trying to do too much...
18:12:58 [Chris]
nono but listening to tim bray and willing to be convinced
18:13:00 [IanYVR]
TBray: Perhaps move some stuff to protocols on payloads and envelopes.
18:13:10 [Chris]
however payloads does not entirely cut it
18:13:28 [IanYVR]
q?
18:13:37 [IanYVR]
CL: I'd like to keep composability.
18:13:41 [IanYVR]
q?
18:13:45 [IanYVR]
q- TBray
18:14:04 [IanYVR]
ack Chris
18:14:04 [Zakim]
Chris, you wanted to note that PDF can enclose svg which can point to JPEG, nowadays
18:14:18 [IanYVR]
CL: Composability we have said generally is a good thing.
18:14:54 [Stuart]
ack DaveO
18:14:54 [Zakim]
DaveO, you wanted to say there are 3 concepts: standalone, containers, and container extensions
18:15:18 [Stuart]
q+
18:15:38 [Chris]
in particular, xml formats that discuss where they can contain other stuff and what happens when they are not the rootmost element, are good
18:15:40 [IanYVR]
DO: Raison d'etre of container is to have extensions.
18:15:47 [Stuart]
q+ to ask whether any of the language of HTML modularisation is relevant eg host language
18:15:56 [TBray]
q+
18:16:04 [IanYVR]
DO: Clearly a standalone language could be a container as well (e.g., PDF).
18:16:12 [timbl]
q+ to agree with what Chris said in words, and ask him to write it uo. That formats hsould be designed fom the understanding that there will be bigger things of whichthey will form a part.
18:16:34 [IanYVR]
CL: SMIL talks about host language
18:16:37 [Stuart]
ack Stuart
18:16:37 [Zakim]
Stuart, you wanted to ask whether any of the language of HTML modularisation is relevant eg host language
18:16:38 [Chris]
smil also talks of a host language
18:16:41 [IanYVR]
PC: Host only works one level up.
18:16:47 [DaveO]
q+
18:16:52 [IanYVR]
(Caution about recursive hosting)
18:17:04 [DaveO]
q-
18:17:17 [Stuart]
ack TBray
18:17:37 [IanYVR]
TBray: I think this issue is mostly about XML today.
18:17:39 [IanYVR]
DC: What about MIME?
18:17:52 [IanYVR]
CL: Also MPEG
18:18:18 [IanYVR]
TBray: I accept container and standalone. Not sure about container extension.
18:18:34 [Chris]
clarification - bray asked if everyone doing containers used xml; i said no and gave an example
18:18:41 [IanYVR]
TBray: Brutal fact is that we haven't talked about this enough.
18:18:49 [IanYVR]
TBray: One proposal is to take this out now and back later if clarified.
18:19:02 [DaveO]
q+ to say that containers, container extensions, and standalone have potentially different models for extensibility.
18:19:52 [IanYVR]
TBray: I agree that there are issues here (e.g., what if I'm not the root of the document...)
18:19:52 [Stuart]
ack timbl
18:19:52 [Zakim]
timbl, you wanted to agree with what Chris said in words, and ask him to write it uo. That formats hsould be designed fom the understanding that there will be bigger things of
18:19:55 [Zakim]
... whichthey will form a part.
18:20:11 [IanYVR]
TBL: When you design a format, design it so that it can be part of a bigger system.
18:20:13 [Chris]
would like to see 'rootmost foo element' mentioned in this section as a specific example
18:20:58 [IanYVR]
TBL: This design requires both humility and cleanliness - don't assume you're the root.
18:21:09 [IanYVR]
TBray: E.g., use namespaces; put root element in namespace.
18:21:24 [IanYVR]
PC: Does IETF XML Guidelines refer to this?
18:21:26 [IanYVR]
DC: No.
18:21:33 [DanCon]
hmm... I have a pretty good cache of what timbl's has written and talked about in my head, but I don't recall a talk on designing a format to fit into a bigger world
18:21:53 [IanYVR]
The lego principle
18:21:57 [Stuart]
ack Dave0
18:22:03 [Stuart]
ack DaveO
18:22:03 [Zakim]
DaveO, you wanted to say that containers, container extensions, and standalone have potentially different models for extensibility.
18:23:05 [IanYVR]
RF: I think we should move on; we agree but don't have text.
18:23:10 [Stuart]
q?
18:23:15 [timbl]
No, I gave the talk at a distributed systems symposium at Cambrideg university between 1984 and 1988. Dave clarke/MIT and Karen Solins was there and we went punting. I remember the sldies but took no photos..
18:23:18 [IanYVR]
Action NW: Rewrite 3.2.2.3
18:23:34 [IanYVR]
3.2.2.4. Extensibility and Versioning
18:23:36 [DaveO]
I said that I feel uncomfortable going to Last Call without having material on language extensibility.
18:23:55 [IanYVR]
RF: Delete first sentence.
18:24:31 [IanYVR]
REsolved: Move first sentence to second, starting "For example..."
18:25:41 [IanYVR]
DO: We talk about extensibility and versionin.
18:26:38 [IanYVR]
NW: My biggest problem with this section is that the attempt to use M and N makes it harder to read.
18:27:08 [IanYVR]
q+
18:27:27 [Chris]
q+ to note PNG stuff on fwd and backward compat
18:27:44 [DanCon]
ack danc
18:27:44 [Zakim]
DanCon, you wanted to noodle on the extensibility box... I agree, but I don't see motivation
18:27:44 [Chris]
q+ to worry about 'as if it didn't exist'
18:27:58 [Stuart]
ack DanCon
18:27:59 [IanYVR]
DC: I think that extensibility is the biggest arch issue in formats.
18:28:05 [IanYVR]
DC: I also agree with the good practice box.
18:28:11 [IanYVR]
DC: I don't see the argument behind it.
18:28:25 [IanYVR]
DC: Please tell a story.
18:28:37 [DanCon]
(I actually didn't say story this time ;-)
18:28:39 [Stuart]
ack Ian
18:28:54 [timbl]
q+ to say you like DaveO's analisys, and would add that the "ignoring" styles can be and should be formalized as transforms which transform a new document into an old.
18:29:38 [DanCon]
hmm... ignoring styles... I suppose it's come up in several specs... but I still wonder if we have enough experience to generalize
18:29:56 [DanCon]
let alone formalie
18:30:01 [timbl]
http://www.w3.org/Talks/1998/0415-Evolvability/slide11-1.htm
18:30:33 [ndw]
q+ to describe this in terms of a specific set of compatibility rules is probably an error.
18:31:08 [timbl]
q?
18:31:29 [IanYVR]
DO: There are roughly three practices in 3.2.2.4
18:32:24 [IanYVR]
DO: Something missing from IJ's text - when you are designing a container, define what contained content must do.
18:32:40 [IanYVR]
q+
18:32:48 [Chris]
ack chris
18:32:48 [Zakim]
Chris, you wanted to note PNG stuff on fwd and backward compat and to worry about 'as if it didn't exist'
18:33:14 [IanYVR]
CL: "Ignore unknown content" is not always desirable behavior.
18:33:38 [DaveO]
Actually, I meant when designing a container, provide a model that allows required extensions to be identified as required.
18:34:18 [TBray]
q+ to make some remarks on the general status of this document and where we go from here
18:35:08 [Roy]
ack Roy
18:35:08 [Zakim]
Roy, you wanted to note that there are no principles in section 3
18:35:11 [TBray]
q+ paul
18:35:35 [IanYVR]
RF: No principles at all in section 3. We are going in circles because we don't have principles guiding us.
18:35:47 [Stuart]
q?
18:35:53 [IanYVR]
RF: If you use a self-descriptive syntax, it improves extensibility and evolvability.
18:36:02 [Chris]
well as usual, the principles are reverse engineerd from the practice
18:36:20 [IanYVR]
RF: If you have a self-descriptive syntax that allows you to plan for evolvability (e.g., ignore data format when value = 0).
18:36:20 [Chris]
but in fact there are, strong, consistent principles that apply to section 3
18:36:42 [IanYVR]
RF: Once you lay down principle you are looking for, your self-descriptive syntax is better.
18:37:05 [DanCon]
indeed, I'm confident there are, chris. we're just not very far along in the document-level work on the reverse engineering
18:37:28 [IanYVR]
q?
18:37:36 [timbl]
http://www.w3.org/Talks/1998/0415-Evolvability/slide23-1.htm Optional flags
18:38:10 [IanYVR]
q-
18:38:15 [Stuart]
ack timbl
18:38:15 [Zakim]
timbl, you wanted to say you like DaveO's analisys, and would add that the "ignoring" styles can be and should be formalized as transforms which transform a new document into an
18:38:18 [Zakim]
... old.
18:38:19 [ndw]
q+ to describe this in terms of a specific set of compatibility rules is probably an error.
18:38:29 [ndw]
q-
18:38:33 [IanYVR]
TBL: I agree that "optional flags" be in ther.e
18:38:45 [IanYVR]
TBL: There are some valuable and distinct concepts that I'd like to put in here....
18:38:50 [Chris]
q+ EndOfQueue
18:39:04 [IanYVR]
TBL: One language being sublanguage of another is a good example.
18:39:17 [DanCon]
Zakim, close the queue. If you don't grok, tell ralph we want a new feature
18:39:17 [Zakim]
I don't understand 'close the queue. If you don't grok, tell ralph we want a new feature', DanCon
18:39:29 [IanYVR]
TBL: We can describe the sorts of transforms DO is describing.
18:39:48 [IanYVR]
I remember TBL's discussion of "no changes outside this subtree" and wonder if that topic is related to what's being discussed here.
18:39:53 [Stuart]
ack DanCon
18:39:53 [Zakim]
DanCon, you wanted to ask if anybody's interested in writing in the finding genre on extensibility: distill experience with what works and what doesn't. what about HTML helped
18:39:56 [Zakim]
... (ignore unknown tags) and what didn't (clean up messy punctuation) and to estimate that we're 20% of the way thru a 6 month discussion of extensibility and such in data formats
18:40:22 [IanYVR]
DC: Good to try to be crisp ("M and N") but only if we are far enough along.
18:40:38 [IanYVR]
DC: Would someone want to write a finding about extensibility experience in real formats (HTML, HTTP, ..)
18:40:49 [IanYVR]
DC: We haven't finished the reverse engineerring.
18:40:50 [timbl]
We should formlize "ignore": and transforms, and formlaize "sublanguage" in term sof the expectations of publisgers and reader.
18:40:55 [Chris]
ignore unknown tags did not help
18:41:02 [Stuart]
ack TBray
18:41:02 [Zakim]
TBray, you wanted to make some remarks on the general status of this document and where we go from here
18:41:13 [Stuart]
ack paul
18:41:18 [Chris]
danc are you proposing a new issue on extensibility?
18:41:26 [IanYVR]
q- EndOfQueue
18:41:30 [IanYVR]
----
18:41:35 [DanCon]
ohh... good idea, Chris. yes, please.
18:41:37 [IanYVR]
On moving the document forward.
18:42:07 [IanYVR]
TBray: I agree with DO's analysis of extensibility and with DC that we have more work to do.
18:42:57 [DanCon]
or... hmm... when I asked for an issue on the dualism between message passing and shared state, the TAG didn't agree to add it, on the grounds that "duh... that's part of the architecture". so I wonder if the TAG would adopt an issue on extensibility
18:43:20 [DaveO]
oh, dan, that's an interesting idea....
18:43:36 [IanYVR]
TBray: I think that we may have to triage and cut some stuff that's not ripe in section 3.
18:44:09 [IanYVR]
TBray: I'd be about 60/40 today to work until X Sep, and see where we are. We cut at that point.
18:44:28 [ndw]
Currently, November
18:44:28 [Stuart]
q?
18:44:29 [Chris]
november i believe
18:44:29 [DaveO]
q+ to talk about importance of section 3/4 and dates.
18:44:48 [IanYVR]
DO: We could just publish section 2.
18:44:55 [IanYVR]
(as last call).
18:45:06 [IanYVR]
DO: We could do what TB says and work up to known date.
18:45:54 [Stuart]
q?
18:45:59 [Stuart]
ack DaveO
18:45:59 [Zakim]
DaveO, you wanted to talk about importance of section 3/4 and dates.
18:46:02 [IanYVR]
DO: Another option is to add a few more months to hammer away, and though costly, less costly than finishing now and then doing that work much later.
18:46:17 [Stuart]
ack DanCon
18:46:17 [Zakim]
DanCon, you wanted to lean toward another few months of work on section 3 and 4... the Sep date is as good a guess as any
18:46:31 [IanYVR]
DC: I think a few months more work on 3/4 is cost effective.
18:46:40 [IanYVR]
q+
18:46:47 [Chris]
i agree on a couple mor emonths work on 3/4 ... good progress this meeting
18:47:08 [TBray]
q+ to note fairly massive editorial changes coming as consequence of last 3 days' discussions
18:47:18 [Stuart]
ack Ian
18:48:55 [IanYVR]
IJ: I think findings help immensely.
18:49:03 [timbl]
q+ to ask that any new work on extensability should include a mention of the qualities of RDF ion this respect.
18:49:44 [TBray]
I agree with doing a finding on extensibility
18:49:46 [Stuart]
ack Tbray
18:49:46 [Zakim]
TBray, you wanted to note fairly massive editorial changes coming as consequence of last 3 days' discussions
18:49:49 [IanYVR]
IJ: They allow readers to focus on specific topics.
18:49:55 [DanCon]
IJ: I don't mean to lose focus on the arch doc, but findings actually help.
18:50:38 [IanYVR]
Action IJ: Produce Editor's Draft Weds or Thurs of next week.
18:50:56 [Stuart]
ack timbl
18:50:56 [Zakim]
timbl, you wanted to ask that any new work on extensability should include a mention of the qualities of RDF ion this respect.
18:51:03 [IanYVR]
TBray: I am passionately convinced we can't go much longer before last call.
18:52:24 [IanYVR]
----
18:52:25 [IanYVR]
Scheduling
18:58:17 [IanYVR]
28 July: SW regrets, NW to Chair
19:00:58 [IanYVR]
7 Sep:
19:01:30 [IanYVR]
11-12 Sep: DO, TBL, SW, IJ
19:01:51 [IanYVR]
CL: I am available 1, 19 (west coast), weekend of 20-21, 22 Sep
19:02:18 [IanYVR]
Week of 6 Oct: IJ, NW, PC, DO, CL, RF, TB
19:02:31 [IanYVR]
PC: Please earlier in the week.
19:02:56 [IanYVR]
CL: Can we meet in Europe?
19:03:13 [IanYVR]
CL:I will have spent almost all of Sep in the US
19:04:36 [IanYVR]
Action NW: Make a ftf meeting proposal for Monday's teleconference.
19:04:40 [IanYVR]
TBL: Early OCt works for me.
19:05:17 [IanYVR]
SW: I am willing to host in the UK
19:05:46 [IanYVR]
Action SW: Formulate a proposal to meet in Bristol.
19:06:16 [IanYVR]
[TBL and TB leave]
19:06:30 [IanYVR]
SW: I can sort out mtg facilities without problem for a group this size.
19:06:39 [DanCon]
when folks send regrets for a telcon (or when they see an agenda and they've already sent regrets) please report on actions you own. I guess I'll send mail on this.
19:07:09 [IanYVR]
PC: Note that AC meeting is in Yokahama.
19:07:58 [IanYVR]
Action IJ: Propose to admin folks that TAG meet at the Prince Hotel in Yokahama 15,16 Nov and morning of 17 Nov.
19:08:26 [IanYVR]
[I.e., to confirm that we are all meeting in the same location]
19:09:25 [IanYVR]
---
19:09:42 [IanYVR]
Next meetings:
19:10:21 [DanCon]
I confirm availability for the 28July telcon
19:10:53 [IanYVR]
PC: Please plan meetings if critical people can attend and make progress on specific topics.
19:12:35 [IanYVR]
I observe that 11 Aug and 1 Sep seriously at risk. Probably should cancel them.
19:12:53 [IanYVR]
---
19:12:59 [IanYVR]
NW: We could also split arch doc in three.
19:13:14 [IanYVR]
<lunch>
19:13:27 [Roy]
Roy has left #tagmem
19:13:55 [IanYVR]
ADJOURNED
19:14:09 [IanYVR]
Thanks to our hosts!
19:14:14 [IanYVR]
Thanks for the ping ping table!
19:14:18 [IanYVR]
ping pong table!
19:18:14 [Chris]
rrsagent, bye
19:18:14 [RRSAgent]
I see 1 open action item:
19:18:14 [RRSAgent]
ACTION: IJ to re-word "spelling" box [1]
19:18:14 [RRSAgent]
recorded in http://www.w3.org/2003/07/22-tagmem-irc#T18-24-59