IRC log of tagmem on 2003-12-01

Timestamps are in UTC.

19:52:17 [RRSAgent]
RRSAgent has joined #tagmem
19:52:26 [Chris]
Zakim, this will be tag
19:52:26 [Zakim]
ok, Chris; I see TAG_Weekly()2:30PM scheduled to start 22 minutes ago
19:53:38 [Stuart]
Stuart has joined #tagmem
19:56:33 [Chris]
Ian, in why does uriMediaType-9 show an open action for me?
20:00:09 [DanC]
DanC has joined #tagmem
20:00:27 [Zakim]
TAG_Weekly()2:30PM has now started
20:00:28 [Zakim]
20:00:35 [Roy]
Roy has joined #tagmem
20:01:42 [Zakim]
20:01:43 [Zakim]
20:01:44 [Zakim]
20:01:49 [Stuart]
zakim, ??p0 is me
20:01:49 [Zakim]
+Stuart; got it
20:01:58 [Ian]
Ian has changed the topic to:
20:02:12 [Zakim]
20:02:35 [Ian]
zakim, call Ian-BOS
20:02:35 [Zakim]
ok, Ian; the call is being made
20:02:37 [Zakim]
20:02:37 [Stuart]
zakim, ??p1 is Paul
20:02:38 [Zakim]
+Paul; got it
20:03:12 [Zakim]
20:03:21 [Stuart]
zakim, mute paul
20:03:21 [Zakim]
Paul should now be muted
20:03:33 [Ian]
zakim, drop DanC
20:03:33 [Zakim]
DanC is being disconnected
20:03:34 [Zakim]
20:03:43 [Ian]
We got your ans. mach
20:04:08 [Stuart]
zakim, who is here?
20:04:08 [Zakim]
On the phone I see Chris, Stuart, Paul (muted), Ian
20:04:09 [Zakim]
On IRC I see Roy, DanC, Stuart, RRSAgent, Zakim, Chris, Ian
20:04:11 [Zakim]
20:04:12 [Zakim]
20:04:15 [timbl]
timbl has joined #tagmem
20:04:24 [Zakim]
20:04:43 [Zakim]
20:05:58 [Zakim]
20:06:12 [DanC]
down with what, Stuart?
20:06:21 [TBray]
TBray has joined #tagmem
20:06:32 [Ian]
Roll call: SW, TBL, IJ, CL, DC, RF, TB, PC
20:06:36 [Ian]
Regrets: NW
20:06:42 [Ian]
Not sure: DO
20:06:43 [Zakim]
20:06:51 [DanC]
en-gb:lurgy = en-us:cold?
20:06:57 [Ian]
zakim, mute PaulC
20:06:57 [Zakim]
PaulC should now be muted
20:07:21 [Ian]
[DC agrees to Chair]
20:07:27 [Stuart]
zakim, mute paulc
20:07:27 [Zakim]
PaulC was already muted, Stuart
20:07:31 [Ian]
20:07:57 [Ian]
Accept the minutes of the 15-17 Nov ftf meeting?
20:08:11 [Ian]
20:08:18 [Ian]
CL: I propose to accept.
20:08:21 [Ian]
TBray: yep, looked ok
20:08:46 [Stuart]
zakim, unmute paul
20:08:46 [Zakim]
PaulC should no longer be muted
20:08:56 [Ian]
Resolved: Accepted. Abstaining: TBL, PC
20:09:01 [Stuart]
zakim, mute paul
20:09:01 [Zakim]
PaulC should now be muted
20:09:05 [Ian]
Accept the minutes of the 24 Nov teleconf?
20:09:18 [Ian]
20:09:31 [Ian]
Resolved to accept.
20:09:36 [Ian]
(those minutes).
20:10:02 [Ian]
DC: Comments on today's agenda?
20:10:10 [Zakim]
20:10:13 [Ian]
Reminder: next meeting 4 Dec.
20:10:18 [Ian]
SW will Chair.
20:10:26 [Ian]
TBL: I will not be able to make the first five minutes.
20:10:44 [Ian]
DC: Backup chair?
20:11:04 [Ian]
Reminder: teleconf is 8am PT/11am ET
20:11:08 [Ian]
(on 4 Dec)
20:11:13 [Ian]
CL reconfirms.
20:11:42 [DanC]
I think I'm available
20:12:04 [Ian]
SW: IJ and I will produce agenda tomorrow.
20:12:09 [Ian]
Video meeting in Feb 2003:
20:12:09 [Ian]
1. Action SW/PC 2003/11/10: Explore possibility of TAG videolink TAG distributed meeting in February.
20:12:14 [Ian]
[Postpone discussion]
20:12:18 [Zakim]
20:12:25 [Ian]
20:12:25 [Ian]
20:12:25 [Ian]
# Tech Plenary
20:12:28 [Ian]
1. Action SW 2003/11/15: Take to tech plenary committee the TAG's proposal.
20:12:32 [Ian]
SW: I've completed that action.
20:12:41 [Stuart]
zakim, mute paul
20:12:41 [Zakim]
PaulC should now be muted
20:13:07 [Zakim]
20:13:17 [Ian]
SW: I've not received a response yet from the committee.
20:13:28 [Ian]
SW: The planning committee has yet to meet.
20:13:45 [Ian]
Negotiations with WGs for last call:
20:13:45 [Ian]
1. SW/I18N done
20:13:45 [Ian]
2. Schema/PC done. MSM has confirmed.
20:13:45 [Ian]
3. SVG/CL done
20:13:46 [Ian]
4. HTML/IJ done
20:13:48 [Ian]
5. Todo: Voice/SW, XML Core/NW, WSDL/DO
20:14:04 [Ian]
SW: I have not received reply from I18N WG yet.
20:14:12 [Ian]
IJ: I have not yet received reply from HTML WG.
20:14:29 [Ian]
CL: Loop is closed with SVG WG.
20:14:43 [Ian]
SW: No progress with Voice yet.
20:14:48 [Ian]
[NW not here for Core]
20:15:17 [Ian]
DO: No progress yet.
20:15:20 [Ian]
20:16:00 [Ian]
Comments on 28 Nov 2003 WD of the Arch Doc?
20:16:18 [Ian]
20:17:08 [Ian]
Proposal: Withdraw this actino item for v 1.0 Arch Doc:
20:17:15 [Ian]
Action IJ 2003/10/08: Starting from DO's diagram, create a diagram where the relationships and terms are linked back to the context where defined. Ensure that the relationships are in fact used in the narrative; any gaps identified? With DO, work on term relationship diagram.
20:17:23 [Ian]
SW, TB, TBL: Seconded.
20:17:28 [Ian]
Resolved: Withdrawn.
20:17:45 [Ian]
Action IJ 2003/11/15: Close issue 6 with TB proposed text. (Done) Inform reviewer. (Not done)
20:18:02 [Ian]
IJ: Otherwise I think the actions have been done in the 28 Nov draft.
20:18:19 [Ian]
CL: I did my actions 1., 2. Number 3 is not yet done.
20:19:20 [Ian]
IJ: I believe CL's actions also incorporaetd in 28 Nov draft.
20:19:35 [Ian]
IJ: I believe NW's 2/3 actions also incorporaetd in 28 Nov draft.
20:19:47 [Ian]
DC: We don't know whether they have been incorporated to NW's satisficastion.
20:19:55 [Ian]
NW's actions recorded as done.
20:20:04 [Ian]
1. Completed action TB: Rewrite paragraph on ambiguity in section 2.2.
20:20:16 [Ian]
Action RF 2003/10/08: Explain "identifies" in RFC 2396.
20:20:26 [Ian]
RF: The existing draft expires this week...I'd better do it...
20:20:29 [Ian]
Resolved: Continued.
20:20:39 [Ian]
Completed Action DO/TBL 2003/11/15: Produce new text for a small subsection 1.2.4 (or perhaps for 1.2.1)
20:20:58 [Ian]
DO: 2/3 not doen.
20:21:09 [DaveO]
DaveO has joined #tagmem
20:21:35 [Ian]
IJ: I incorporated TBL/DO text in 28 Nov draft; they haven't signed off yet.
20:22:09 [Ian]
20:22:17 [Ian]
(section 1.2.2)
20:22:32 [Ian]
DC: DO's action on WSDL WG continued.
20:22:39 [Ian]
DC: DO's action 3 continued.
20:23:05 [Ian]
TBray: DO, do you regard this as important for LC?
20:23:19 [Ian]
DO: I am fine with this not being done for LC.
20:23:27 [Ian]
DO: Please continue (indefinitely).
20:23:54 [Ian]
1. Action TBL 2003/07/14: Suggest changes to section about extensibility related to "when to tunnel".
20:24:05 [Ian]
TBL: Please continue indefinitely (after LC).
20:24:08 [Ian]
IJ: I'll move to issues lsit.
20:24:25 [Ian]
Completed action DC 2003/11/15: Elaborate on value of orthogonality of specs in section 1.2.1 including example HTTP/HTML
20:24:33 [Ian]
DC: Done to my satisfaction.
20:24:46 [Ian]
IJ: I expanded on it as well in 28 Nov draft.
20:25:15 [Ian]
IJ: Please see my discussion on META/refresh in that section.
20:25:37 [Ian]
1.2.1. Orthogonal Specifications
20:25:40 [TBray]
20:25:41 [Chris]
20:26:09 [Ian]
TBray: CL and I had some back and forth on this.
20:26:10 [Chris]
and http-equiv="refresh now"
20:26:21 [Ian]
TBray: I like the motherhood and apple pie language before the bulleted list.
20:26:22 [TBray]
" The HTML specification allows content providers to instruct HTTP servers to build response headers from META element instances. This is a clear abstraction violation; the developer community deserves to be able to find all HTTP headers from the HTTP specification (including any associated extension registries and specification updates per IETF process). Furthermore, this design has led to confusion in user agent development. The HTML specification state
20:26:43 [Ian]
TBray: I think the first sentence needs rephrasing.
20:26:55 [Ian]
TBray: the HTML spec supplements HTTP servers.
20:27:08 [Ian]
CL: In fact, the HTML spec is an instruction for HTTP servers, which is universally ignored.
20:27:18 [Ian]
CL: That's evidence of a problem having arisen.
20:27:33 [Ian]
TBray: Perhaps a bit of phrasing "This doesn't work in deployed servers as specified!"
20:27:52 [TBray]
3rd bullet: " Some authors use the META/http-equiv approach to declare the character encoding scheme of an HTML document. By design, this is a hint that an HTTP server should emit a corresponding "Content-Type" header field. In practice, the use of the hint in servers is not widely deployed and many user agents peek inside the HTML document in preference to the "Content-Type" header field. This works against the principle of authoritative representation m
20:28:41 [Ian]
Action IJ: Salt this text to taste to emphasize that problems have arisen.
20:28:44 [DanC]
emph " servers is not widely deployed "
20:28:57 [Ian]
RF: There are servers that implement it!
20:29:13 [Ian]
RF: [Some] Content management systems do this.
20:29:15 [DanC]
20:29:21 [Chris]
content magagement systems, and the discontinued GN server
20:29:21 [DanC]
20:29:47 [Ian]
DC: My action 2 done; action now on IJ.
20:29:54 [Ian]
My action 3 is done.
20:29:55 [Roy]
/me just froggy throat from cold
20:30:01 [Ian]
DC: My action 3 is done
20:30:05 [Ian]
DC: Please continue action 4.
20:30:13 [Ian]
Action SW: 2003/11/15: Verify that "agent" is used consistently in the document and makes sense as both people and software. [Subsumed by IJ?]
20:30:16 [Ian]
TBray: Better than it used to be.
20:30:19 [Ian]
IJ: I agree with TB.
20:30:33 [Ian]
SW: Please continue my action 1.
20:30:55 [Ian]
Action IJ: Please link to SW's photos from the 15 Nov minutes.
20:31:01 [Ian]
SW's action 2 is closed.
20:31:27 [Chris]
yes, i agree
20:31:30 [Ian]
[On text in 1.2.2]
20:31:45 [Chris]
yes, i agree that a sentence of introduction would be helpful
20:32:07 [Ian]
TBL: The gist is missing: It's not just enough to make an extension language, you also need to make it so that not only old documents members of the new language, but also that new docs, without much damage, can be interpreted in the old language.
20:32:35 [Ian]
TBL: Ok that extension is inverse of subset.
20:33:03 [Ian]
TBL: Missing text is that you need to ensure that a doc in the extension language can be interpreted in the old language with predictable results.
20:33:42 [Roy]
"second" and "first" is ambiguous
20:34:15 [Ian]
TBL: Should be in para about "Language extension".
20:34:33 [DanC]
I note "we", the TAG decided on whatever timbl, daveo, and Ian agree to.
20:35:33 [Ian]
20:35:56 [timbl]
"Clearly, an extension language is better than an incompatible language, but in practice greater compatability is needed. Ideally, an instance of the superset language, in many cases can be safely and usefully processed as though it were in the subset language. Extensability the property of a langauge that allows this. The original language design can accomplish extensability by defining, for predicable unknown extensions, the handling by implementations -- for
20:36:01 [Roy]
Language A' is an extension of language A if and only if A is a subset of A'.
20:36:29 [DanC]
ack tbray
20:36:29 [Zakim]
TBray, you wanted to comment on the draft
20:36:39 [Ian]
TBray: I sent email (URI?) with comments on the draft.
20:37:17 [Ian]
20:37:43 [Ian]
TBray: I think CL and I agree that most of the issues are probably not controverial.
20:37:51 [Ian]
CL: I agree with TB's assessment.
20:38:09 [Ian]
[TB has the floor]
20:38:22 [Chris]
my response at
20:38:36 [Ian]
1.2.4 Is the 2nd sentence of the first para, about the longevity of
20:38:36 [Ian]
messages, new in this draft? It doesn't have anything to do, not in
20:38:36 [Ian]
the slightest, with the actual point being made in this section.
20:38:42 [Ian]
q+ to talk about https if we get there.
20:39:09 [Ian]
TBray: Propose to lose that sentence.
20:39:12 [Ian]
CL: Fine to drop.
20:39:58 [Ian]
Action IJ: s/messages exchanged/technology shared.
20:40:16 [Chris]
"the technology shared among agents in the Web may last
20:40:17 [Chris]
longer than the agents themselves" would also be fine.
20:40:38 [Ian]
TBray: I propose that second para be dropped.
20:40:48 [Ian]
20:40:52 [Ian]
First sentence only?
20:41:03 [Ian]
TB proposal: Rewrite first sentence per CL proposal.
20:41:08 [Chris]
So, I agree
20:41:09 [Chris]
with Tim about loosing the last para, but also suggest deleting "not
20:41:09 [Chris]
in terms of APIs or data structures or object models, but in terms of
20:41:09 [Chris]
protocols,". Make a positive point about the benefits of message based
20:41:09 [Chris]
interop, its not necessary to knock other approaches to make the
20:41:09 [Chris]
20:41:18 [Chris]
ian does now
20:42:09 [Stuart]
s/content and sequence/content,sequence and semantics/
20:42:13 [Chris]
deletion proposed *is* in IRC
20:43:33 [TBray]
s/not in terms of APIs or data structures or object models, but//
20:43:43 [Ian]
(in FIRST para)
20:44:01 [DanC]
"The Web follows Internet tradition in that its important interfaces are defined in terms of protocols, by specifying the content and sequence of the messages interchanged."
20:44:10 [Ian]
TBL: I'd like semantics to go in para.
20:44:13 [Ian]
TBray: I can live with semantics.
20:44:18 [DanC]
"The Web follows Internet tradition in that its important interfaces are defined in terms of protocols, by specifying the content, sequence and semantics of the messages interchanged."
20:44:24 [Chris]
The Web follows Internet tradition in that its important interfaces are defined by specifying the content and sequence of the messages interchanged.
20:44:29 [TBray]
The Web follows Internet tradition in that its important interfaces are defined in terms of protocols, by specifying the content, sequence, and semmantics of the messages interdchanged.
20:45:30 [Roy]
s/content, sequence and/syntax, semantics, and sequence/
20:45:30 [Chris]
The Web follows Internet tradition in that its important interfaces are defined by specifying the content, sequence and semantics of the messages interchanged.
20:45:40 [TBray]
I'm OK with that
20:45:43 [Chris]
20:45:44 [Ian]
CL: Fine.
20:45:47 [Chris]
+1 to roy
20:46:06 [timbl]
timbl has joined #tagmem
20:46:10 [TBray]
The Web follows Internet tradition in that its important interfaces are defined in terms of protocols, by specifying the syntax, semantics, and sequence
20:46:17 [TBray]
...of the messages interchanged
20:46:29 [Chris]
go for it
20:46:30 [Ian]
Resolved: Accept TB's sentence.
20:46:47 [Ian]
Proposed: Drop third para.
20:46:51 [Ian]
Resolved: Drop third para.
20:47:07 [DanC]
RRSAgent, pointer?
20:47:07 [RRSAgent]
20:47:11 [Chris]
rrsagent, pointer?
20:47:11 [RRSAgent]
20:47:24 [Ian]
TBray: 2. Would anyone else like to tighten up the first para by retaining
20:47:24 [Ian]
just the first and last sentences? It would be immensely clearer I
20:47:24 [Ian]
20:47:40 [TBray]
Parties who wish to communicate must agree upon a shared set of identifiers and on their meanings. Thus, Uniform Resource Identifiers ([URI], currently being revised) which are global identifiers in the context of the Web, are central to Web architecture.
20:48:24 [Ian]
CL: I'm ok with losing second sentence...
20:48:28 [Roy]
/me diff's are so much clearer
20:48:51 [Chris]
I am fine with Tim Brays text
20:48:59 [Ian]
I note that this value bit comes back later in the section on ambiguity.
20:49:55 [Ian]
DC: I meant "network effect" sentence as motivation for first constraint.
20:50:22 [Ian]
q+ to comment.
20:50:58 [DanC]
ack ian
20:50:58 [Zakim]
Ian, you wanted to talk about https if we get there. and to comment.
20:51:37 [Ian]
IJ: There's a tie-in in 2.3 in section on ambiguity.
20:51:46 [Ian]
DC: I don't like first para of 2.
20:51:55 [Ian]
CL: +1 to TB's proposal.
20:52:57 [Ian]
TBL: Delete 2nd sentence, leave third.
20:53:02 [Chris]
20:53:04 [Ian]
(of first para of section 2)
20:53:12 [Ian]
Resolved: Delete sentence two of first para of 2.
20:53:14 [Chris]
20:53:50 [Ian]
TBray: I don't understand "Of particular importance are those messages that express a relationship between a URI and a representation of the resource it identifies. "
20:53:56 [Ian]
DC: Those are "200 Ok" responses.
20:53:59 [Ian]
TBray: Then please send that.
20:55:00 [Ian]
20:55:58 [Ian]
IJ Proposal: Clarify intent of sentence in question as last sentence of para of 2.2.
20:56:16 [Roy]
seems redundant to the sentence following it
20:56:22 [Ian]
DC: The point is that the way URIs take on meaning is that you get representations back when you deref the URI; 200 Ok reponses are thus key.
20:57:02 [Ian]
20:57:06 [DanC]
ack ian
20:57:43 [TBray]
yes, but doing well I think, have covered most of my hot-button issues
20:58:00 [Ian]
DC: I'm ok to lose the sentence, having heard RF.
20:58:25 [Ian]
Proposal to delete "Of particular importance are those messages that express a relationship between a URI and a representation of the resource it identifies."
20:58:25 [Roy]
20:58:28 [Ian]
CL: ok
20:58:29 [Ian]
DC: Ok
20:58:30 [Ian]
TBray: Ok
20:58:42 [Ian]
20:58:50 [Stuart]
20:58:50 [Ian]
Resolved: Delete said sentence of 2.2.
20:59:04 [Ian]
s/URI ownership URI/URI ownership
20:59:06 [Ian]
20:59:29 [Ian]
3.2. Messages and Representations
20:59:40 [Ian]
TBray: I propose change to read:
20:59:48 [Chris]
20:59:55 [Chris]
Some is about the resource, some is specific to a particular resource
20:59:55 [Chris]
20:59:56 [Ian]
A messsage may include: data, metadata about the data, and metadata about the resource.
21:00:14 [Ian]
CL: My point was that some is about the resource, some about the representation.
21:00:22 [Ian]
CL: E.g,. content-language is about the representation.
21:00:28 [Ian]
21:01:00 [Ian]
TBray: Change to "metadata about the representation data"
21:01:50 [Chris]
we need to say both - resouece and representation metadata
21:02:14 [Chris]
'Vary' for example is about the resource
21:02:20 [Chris]
ack chris
21:02:21 [Ian]
TBL: Simplify to metadata about the resource and the message.
21:02:29 [timbl]
may include data and metadata about the resource and the message.
21:02:34 [DanC]
ack chris
21:02:35 [DanC]
ack ian
21:03:07 [DanC]
by "general" do you mean "typical"?
21:03:08 [Ian]
IJ: I moved "resource metadata" out of ordered list since not the general case.
21:03:09 [Stuart]
message ~= message metadata, representation, represenation metadata and resource metadata?
21:03:37 [TBray]
may include representation data as well as metadata about the resource, the representation, and the message.
21:03:49 [timbl]
Propose: A message may include data, and metadata about the resource and the message.
21:04:21 [Stuart]
+1 to TBray's draft
21:04:22 [Ian]
CL, DC: We prefer TB's proposal.
21:04:27 [Chris]
prefer tbrays one
21:04:44 [Roy]
prefers TBray's draft
21:04:46 [TBray]
A message may...
21:04:50 [Chris]
21:05:03 [timbl]
21:05:05 [Ian]
Resolved to accept TB"s proposal.
21:05:33 [Ian]
TB Proposal: Lose GPN just before 3.5
21:05:35 [TBray]
Lose GP at end of 3.4.1
21:05:56 [Ian]
TBray: We say the same thing in preceding para (as in GPN)
21:05:59 [Chris]
"Server managers MUST ensure that resource
21:05:59 [Chris]
metadata is appropriate for each representation."
21:06:16 [Roy]
This is not the responsibility of server managers.
21:06:19 [timbl]
s/appropraite for each represnetation/correct
21:06:24 [Stuart]
how about s/approriate/accurate/
21:06:45 [Chris]
21:06:45 [TBray]
s/each/all the/
21:06:47 [Roy]
21:06:51 [Ian]
CL: My point is that if your metadata says something about a resource, make sure it works for all representations.
21:06:58 [DanC]
ack Roy
21:07:07 [Ian]
RF: I don't think this is appropriate at all. It's not the server manager's responsibility.
21:07:29 [Ian]
RF: A server manager is incapable of knowing all the resources in the server namespace.
21:07:36 [timbl]
21:07:39 [Ian]
RF: The metadata depends on how the author intends a resource to be used.
21:07:45 [Ian]
(through representations).
21:08:03 [timbl]
q+ to point out that we can't really go into the disnction between different parties in the publisher.
21:08:03 [DanC]
ack timbl
21:08:04 [Zakim]
timbl, you wanted to point out that we can't really go into the disnction between different parties in the publisher.
21:08:20 [Ian]
TBL: I think that RF's distinction is between different parties within the publisher (abstraction).
21:09:00 [Ian]
IJ proposal to either add "metadata, especially that applying across representations" and deleting GPN.
21:09:02 [Chris]
q+ to argue that distinguishing between resouce and representation is the crucial thing; drop 'server manager'
21:09:58 [Chris]
+1 to what Ian said
21:10:03 [Chris]
ok now to drop the box
21:10:15 [Chris]
ack chris
21:10:15 [Zakim]
Chris, you wanted to argue that distinguishing between resouce and representation is the crucial thing; drop 'server manager'
21:10:32 [Ian]
Proposed rewrite of sentence before GPN: Furthermore, server managers can help reduce the risk of error through careful assignment of representation metadata (especially that which applies across representations)."
21:10:36 [Ian]
(and delete GPN).
21:10:49 [DanC]
21:11:13 [Ian]
21:11:19 [Ian]
21:11:43 [Ian]
3.5 Why the new XForms plug? It adds nothing to the example and
21:11:43 [Ian]
creates confusion because people are going to wonder if this is special
21:11:43 [Ian]
and different and couldn't have been done with old-fashioned HTML
21:11:44 [Ian]
forms. Must be removed.
21:11:44 [Ian]
21:11:44 [Roy]
suggestion: Resource owners must manage the resource's provided metadata as carefully as they manage the data, ensuring that they remain consistent with the intended semantics of the resource.
21:12:16 [Ian]
TBray: Move back from Xforms to HTML forms.
21:12:38 [Ian]
TBray: Might make people think that you need Xforms to do this.
21:12:46 [Ian]
CL: Propose "for example" around Xforms.
21:12:49 [Ian]
TBray: I'm fine with that.
21:12:55 [Chris]
add "for example' right before xforms
21:12:55 [Stuart]
21:12:58 [Ian]
Proposed: "Built with, for example, XForms")
21:13:16 [Ian]
RF: I think the idea is good, not sure it improves readability.
21:13:19 [timbl]
(built with XForms ro HTMl forms)
21:13:47 [TBray]
OK with TBL's too
21:13:57 [Chris]
q+ to say it makes a link to a finding
21:13:59 [Ian]
21:14:00 [Roy]
simple is better
21:14:14 [Ian]
TBray: Propose to lose parenthetical
21:14:22 [timbl]
Could we see the text we agreed on at the f2f in the 111?
21:14:26 [Ian]
DC: +1 to lose parenthetical
21:14:31 [Ian]
RF: +1 to lose parenthetical
21:14:43 [Ian]
Resolved: Lose parenthetical re: xforms.
21:14:45 [Ian]
21:14:46 [DanC]
ack Chris
21:14:46 [Zakim]
Chris, you wanted to say it makes a link to a finding
21:15:23 [Ian]
DC: Finding is cited in last para of the section.
21:15:55 [Ian]
4.2.2 "must understand". I totally don't agree that "must understand"
21:15:55 [Ian]
is limited to markup from another namespace. XHTML could for example
21:15:55 [Ian]
have applied a "must understand" policy to new XHTML elements (they may
21:15:55 [Ian]
have, for all I know). All you need to do is /markup from an
21:15:55 [Ian]
unrecognized namespace/unrecognized markup/
21:16:32 [Ian]
DO: That's correct.
21:17:01 [Ian]
CL: Namespace can be relevant.
21:17:45 [Ian]
CL:You could have different handling whether in or out of namespace (and unrecognized).
21:17:58 [Ian]
21:18:13 [Ian]
21:18:21 [Ian]
q+ to say that "including mixing strategies" appears in next para.
21:18:26 [Chris]
21:18:59 [Ian]
TBray: CL's example is deceiving. It's a particular example.
21:19:09 [Ian]
TBray: CL's example is less simple.
21:19:13 [Ian]
DO: +1 to TB
21:19:16 [Ian]
TBL: +1 to TB.
21:19:29 [Ian]
Resolved to accept TB's proposal.
21:19:47 [Ian]
4.3 The para beginning "Note that when content, presentation, and
21:19:47 [Ian]
interaction are separated" is *very* fuzzy and I think could just be
21:19:47 [Ian]
nuked. I don't remember discussing this, is it the output of TAG
21:19:47 [Ian]
21:19:48 [Ian]
21:19:48 [Ian]
21:19:51 [Ian]
q+ to talk about https
21:20:11 [DanC]
TBray proposes to delete para "Note that when content, presentation, and interaction ..."
21:20:30 [DanC]
CL drafted it, Ian rewrote it
21:20:48 [Ian]
TBray: I withdraw my comment.
21:21:03 [Ian]
4.5.2 is the TAG comfy with being this much in favor of XPointer? I'd
21:21:03 [Ian]
need to hear a few explicit "YESes"
21:21:26 [TBray]
To define fragment identifier syntax, use at least the XPointer Framework and XPointer element() Schemes.
21:21:36 [Ian]
TBL's text was this: "XLink is an appropriate specification for representing links in hypertext XML applications.
21:21:36 [Ian]
21:22:11 [TBray]
21:23:55 [Roy]
Please condense all four paragraphs of 4.5.2 into one.
21:24:08 [TBray]
+1 to Roy
21:24:28 [Ian]
TBL proposal: Move "XLink is an appropriate specification for representing links in hypertext XML applications." to 4.4
21:24:35 [Chris]
I think that 4.5.2 is fine as it is
21:24:48 [Ian]
Support for move: TB
21:25:06 [Ian]
TB, CL: Leave where it is.
21:25:08 [Chris]
better where is is
21:25:42 [Ian]
TBL: Proposed change title of section to 4.5.2to "Hyperlinks in XML"
21:26:30 [TBray]
q+ to return to the xpointer-assertion sentence & make sure we cleaned that up
21:26:33 [Ian]
21:26:48 [Chris]
Propose moving "XLink is an appropriate specification for representing links in hypertext XML applications." to before " XLink allows links to have multiple ends"
21:27:21 [TBray]
Middle of 1st para of 4.5.2
21:27:24 [Ian]
TBL: I think that makes sense..........
21:27:27 [Chris]
establishes a hypertext context
21:27:44 [Ian]
IJ proposes louder back link to hypertext.
21:27:49 [Ian]
21:27:51 [Roy]
editorial: s/( in | for ) XML// for all section headings 4.5.*
21:28:02 [Ian]
IJ summarizing:
21:28:10 [TBray]
+1 to Roy
21:28:14 [Ian]
1) s/use at least/consider
21:28:26 [Ian]
2) move third para to first para per CL proposal.
21:28:33 [Ian]
3) Link back to hypertext links section.
21:28:36 [Ian]
(all in 4.5.2)
21:28:47 [Ian]
TBray: +1
21:28:48 [Ian]
TBL: +1
21:29:01 [Ian]
SW: Don't use "consider" twice in same para.
21:29:03 [Ian]
21:29:10 [Chris]
yes we do
21:29:30 [TBray]
21:29:31 [DanC]
"specifically" might help, yes.
21:29:36 [Ian]
Resolved: Accept IJ proposal.
21:29:51 [Ian]
4.5.5 2nd para, 2nd sentence is COMPLETELY WRONG. Yes, you can convert
21:29:51 [Ian]
back & forth between qunames & URI/local-part pairs. What you can't do
21:29:51 [Ian]
is go back & forth from qnames to URIs; which is clearly what Norm
21:29:51 [Ian]
21:30:07 [Ian]
TBray: Yes there is. What there isn't is qname -> URI.
21:30:26 [TBray]
There is no single, accepted way to convert a QName into a URI or vice-versa.
21:30:32 [Chris]
There is no single, accepted way to convert a QName into a URI.
21:30:46 [TBray]
don't lose vice-versa please
21:30:54 [TBray]
OK chris?
21:31:08 [Ian]
SW, TBL: Qualified names and QNames are different.
21:31:30 [Roy]
First sentence defines them as same.
21:31:31 [Ian]
TBray: I think SW is right.
21:31:35 [Stuart]
Propose s/("Qnames")//
21:31:49 [Chris]
section is called "4.5.5. QNames in XML" so no ambiguity...
21:32:23 [Ian]
IJ: I am confused seeing qualified name , then qname, then not understanding the relation.
21:32:37 [Ian]
TBray: Nuke "QName", then insert a sentence explaining relation.
21:33:19 [Roy]
/me I need to go, but please continue without me
21:33:23 [Ian]
TBL: "Qualified names were introduced by XMLNS and are represented in XML by the "Qname" construct."
21:33:24 [DanC]
thanks, roy
21:34:01 [Ian]
IJ: I understand the proposed change the goal of ensuring that text is not inconsistent.
21:34:18 [DanC]
PROPOSED: to fix QName stuff to the satisfaction Lilley and Williams
21:34:35 [Ian]
TBray: +1
21:34:36 [DanC]
21:34:47 [Roy]
Roy has left #tagmem
21:34:49 [Ian]
Action IJ: Do another draft.
21:34:53 [Ian]
(before Thursday)
21:35:07 [DanC]
21:35:11 [Ian]
RRSAgent, stop