IRC log of tagmem on 2003-01-13

Timestamps are in UTC.

18:57:24 [IanLunch]
IanLunch has changed the topic to:
19:13:45 [DanConn]
DanConn has joined #tagmem
19:48:58 [tim-desk]
tim-desk has joined #tagmem
19:54:42 [tim-desk]
tim-desk has changed the topic to:
19:57:02 [Stuart]
Stuart has joined #tagmem
19:57:29 [Stuart]
Evening All
19:58:08 [DanConn]
19:59:03 [tim-desk]
Zakim, this is tag
19:59:04 [Zakim]
ok, tim-desk
19:59:10 [Norm]
Norm has joined #tagmem
19:59:30 [TimBL]
I hope he deals in for more than a moment ;-)
19:59:36 [TimBL]
19:59:54 [Norm]
I said momentarily, not "for a moment" :-)
20:00:21 [Zakim]
20:00:30 [Zakim]
20:00:44 [Stuart]
zakim, ??P1 is me
20:00:45 [Zakim]
+Stuart; got it
20:01:03 [Norm]
zakim, who's on the phone?
20:01:04 [Zakim]
On the phone I see TimBL, Stuart, Norm
20:01:41 [Zakim]
20:01:50 [Ian]
RRSagent, start
20:02:22 [TBray]
TBray has joined #tagmem
20:02:45 [Zakim]
20:02:54 [Zakim]
20:04:04 [Ian]
TBL: CL likely regrets
20:04:21 [Ian]
Present: TBL, SW, DC, NW, TB, IJ
20:04:24 [Zakim]
20:04:55 [Zakim]
20:05:08 [Ian]
zakim, ??P6 is Paul
20:05:09 [Zakim]
+Paul; got it
20:05:24 [Ian]
Not hear: RF
20:05:39 [DanConn]
d'oh! that's the wrong minutes to review, no?
20:05:56 [TBray]
there were some corrections to the minutes
20:06:06 [PaulC]
PaulC has joined #tagmem
20:06:08 [TBray]
20:06:20 [DanConn]
I see "Agenda 6Jan" at
20:07:03 [Ian]
TB: s/decoration/declaration/
20:07:08 [Ian]
(in 6 Jan minutes)
20:08:45 [Ian]
Accepted minutes from 6 Jan with change made.
20:08:54 [Ian]
Additional agenda requests:
20:09:15 [Ian]
20:09:33 [Ian]
Next meeting: 20 Jan.
20:09:37 [Ian]
IJ will be there, but in France.
20:10:03 [Ian]
TBL: MIT is closed 20 Jan.
20:10:13 [DanConn]
TBL: 20Jan is an MIT holiday, MLK holiday
20:10:18 [DanConn]
MLK day
20:10:30 [DanConn]
so stuff like telcon operators won't be there
20:10:44 [Ian]
Resolved to meet 20 Jan.
20:10:50 [DanConn]
I offer tentative regrets for 20Jan
20:11:10 [Ian]
20:11:16 [Ian]
- 3 Jan meeting to welcome new TAG participants.
20:11:19 [Ian]
- 10 Jan no meeting.
20:12:10 [Ian]
20:12:42 [Ian]
Resolved: Meet 3 Jan, do not meet 10 Jan.
20:12:45 [Zakim]
20:13:27 [DanConn]
Zakim, mute me
20:13:28 [Zakim]
sorry, DanConn, I do not see a party named 'DanConn'
20:13:32 [DanConn]
Zakim, I am DanC
20:13:33 [Zakim]
ok, DanConn, I now associate you with DanC
20:13:35 [DanConn]
Zakim, mute me
20:13:36 [Zakim]
DanC should now be muted
20:14:05 [Ian]
20:14:13 [Ian]
* XLink teleconference scheduled for 16 Jan; see meeting details (TAG-only).
20:14:22 [Ian]
20:15:07 [Ian]
[Discussion of participants.]
20:16:08 [DanConn]
MIT holiday calendar:
20:17:17 [Ian]
Action SW: Invite Micah Dubinko as well.
20:18:11 [Ian]
[Review of agenda of XLink meeting]
20:19:28 [Ian]
IJ: What about starting discussion with a proposal (e.g., TB's proposal).
20:19:42 [Zakim]
20:19:44 [Ian]
NW: I think that concrete proposal based on XLink will not encourage discussion.
20:19:51 [Stuart]
20:20:22 [Ian]
zakim, ??P5 is Roy
20:20:23 [Zakim]
+Roy; got it
20:20:47 [Roy]
Roy has joined #tagmem
20:20:57 [Ian]
TB: What about opening discussion on goals of linking in XHTML 2.0?
20:21:24 [Ian]
TBL: Let's return to the original requirements.
20:22:13 [Ian]
TBL: I have the feeling the HTML WG has tried to provide a generalized solution, rather than providing a way for authors to make links across vocabs.
20:22:34 [Ian]
SW: I'm not sure we have a clear articulation of the problem.
20:23:34 [Ian]
IJ: Do we have anyone who will champion a cause?
20:23:55 [Ian]
TB: I will champion (1) new functionality for linking in XHTML 2.0 and (2) some principles for linking for the syntax.
20:24:22 [TimBL]
I am prepared to speak on behalf of xlink:a
20:24:57 [TBray]
actually, I said that I'm prepared to make my arguments *if* it's considered to be helpful in making progress
20:25:20 [Ian]
TB: It's important to understand where the HTML WG is coming from, and what they think is important.
20:26:26 [Ian]
IJ: We did hear them say "external namespace is not a huge hurdle."
20:26:52 [Ian]
[SW and TB will chat more about agenda]
20:27:51 [Ian]
IJ: On xlink:a, how do you handle content model?
20:28:04 [Norm]
20:28:06 [Ian]
TBL: You export the content model of html:a.
20:28:38 [Ian]
TBL: Answer - you crosslink the schemas.
20:29:00 [Ian]
NW: That particular style solution does not address a big part of the process space - some vocabs don't have HTML elements at all.
20:29:27 [Ian]
20:29:30 [Norm]
I just don't think now's the time, Tim, I wasn't trying to make it a one-sided discussion :-)
20:29:30 [Ian]
TAG ftf meeting
20:29:51 [Ian]
Initial mtg page:
20:29:54 [Norm]
I want an XLink solution for DocBook which will *never* have HTML inlines in it.
20:29:59 [DanConn]
ack me
20:30:01 [Ian]
20:30:05 [Norm]
ack norm
20:30:13 [Ian]
SW: I would like to talk about Tech Plenary.
20:30:20 [Ian]
DC: I hope we will chew over Arch Doc text.
20:31:38 [Ian]
IJ: Most expected text is from action items; there's not much.
20:31:46 [DanConn]
Ian: I expect text from ChrisL on data formats, and perhaps from Tim/Roy on http-14
20:32:00 [Ian]
TB: I'll look at latest editor's draft and send comments.
20:32:04 [DanConn]
DanC: hmm... that's not a whole lot... hmm...
20:32:15 [Ian]
20:32:25 [Ian]
New issue? * Architectural issues with XInclude; see email from M. Murata
20:32:30 [Ian]
20:33:02 [Ian]
NW: Consensus of Core WG was that XInclude was doing roughly the right thing. Unsure whether this should be bumped to TAG or whether Core WG should politely indicate that the WG has considered the issue.
20:33:09 [TBray]
20:33:22 [Ian]
NW: Purpose of XInclude is to combine infosets of two XML Docs.
20:33:36 [Ian]
NW: The only thing it makes sense to include are bits of plain text and bits of XML.
20:33:56 [Ian]
NW: XInclude willfully disregards the MIME type. That's its purpose in life.
20:34:24 [Ian]
TB: If this a symptom of a larger problem, we should invest time in it. If this only appears in XInclude, we can safely ignore.
20:34:41 [Ian]
TBL: I think there's need out there; just hasn't been available.
20:34:42 [Ian]
20:34:46 [Ian]
ack TBray
20:34:53 [Norm]
20:35:00 [Stuart]
ack TBray
20:35:08 [TimBL]
20:35:15 [Ian]
DO: I don't think there's anything architectural to look at here. I'd advise against accepting this as an issue.
20:35:29 [Ian]
NW: I think there's a deep and ugly issue lurking here (though we may choose to not take it up).
20:35:37 [Stuart]
ack Norm
20:35:42 [PaulC]
FYI to chair and meeting: Paul and David are using the same phone for the rest of this call.
20:35:42 [Ian]
NW: Frag identifier reliance on MIME type is worrisome...
20:35:54 [DanConn]
Norm, is this different from "fragmentInXML-28 : Use of fragment identifiers in XML"?
20:35:57 [Ian]
TB: I think this intersects with recent flurry about content negotiation.
20:36:27 [DanConn]
hmm... i thought "fragments and mime types" was on our agenda; I thought I was obliged to tell RDFCore what we decided about it...
20:37:31 [Norm]
Yes, fragmentInXML-28 is a good hanger for the larger issue
20:37:48 [Ian]
TBL: What happens if there's a doc served as plain text and you say "treat as plain text". What about the inverse?
20:39:04 [Stuart]
20:39:16 [Stuart]
ack TimBL
20:39:57 [Ian]
NW: With XInclude, you can point to a doc served as text/plain and say "treat as XML". If well-formed, all will go well. I have no problem with that. Murata-san says that that's not the right thing to do since that's explicitly overriding the MIME type.
20:39:58 [Ian]
20:40:13 [Ian]
TB: We say in arch document not to override MIME type.
20:41:32 [Ian]
IJ: Did we say that or did we say "There's one authoritative way to do this; if you do something else you're on your own?"
20:41:44 [Ian]
TB: I think that XInclude is doing the right thing here.
20:42:14 [Ian]
TB: We are not talking about general resource representation retrieval. This is a clear special case.
20:42:16 [Ian]
NW: I agree.
20:42:29 [Ian]
20:43:01 [Ian]
DC: Does XInclude recommend Accept headers?
20:43:24 [Ian]
DC: I'm inclined to accept this as a new issue (or almost any disposition).
20:43:41 [Ian]
SW: Does anyone propose we take this on as a new issue?
20:44:08 [Ian]
TBL: I haven't read the spec in enough detail.
20:45:04 [Ian]
TB: I agree with TBL that there may be an issue lurking out there, but I don't think we should accept until we have a better crystalization.
20:45:54 [Ian]
TB: I would decline on the basis that XInclude functionality is special and wired into XML's view of the world; it is not of particular arch import.
20:46:13 [Ian]
TBL: If it's fundamental to XML, I think we can't say that it's not important to Web architecture.
20:46:41 [Ian]
TBL: My sense is that there are two functions - they are accepting either xml or taking a plain text doc and doing a rather risky conversion.
20:46:44 [Norm]
20:46:50 [Ian]
q- DanC
20:47:13 [PaulC]
20:47:30 [TBray]
20:47:55 [Ian]
TBL: Fear of ending up specifying same thing in 6 places, inconsistencies, fear of having URI+media type pair.
20:48:12 [Ian]
NW: Nothing risk about conversion of XML -> text/plain
20:48:34 [Ian]
TB: Suppose I ask for something to be included as text that has entity refs?
20:48:39 [Ian]
NW: They are processed.
20:48:42 [Stuart]
ack norm
20:48:56 [Ian]
TBL: I'd like to raise as an issue. I don't want to put it in the head of our queue.
20:49:01 [Ian]
ack PaulC
20:49:04 [Norm]
20:49:26 [Ian]
TB: We don't want to get onto the slippery slope of turning URIs into doubles.
20:49:40 [Stuart]
ack TBray
20:50:00 [Ian]
TB: It does strike me as architecturally question that XInclude doesn't say anything about this (e.g., what happens when content is not xml)?
20:50:06 [Ian]
NW: XInclude will fail.
20:50:30 [Ian]
20:50:34 [Ian]
ack DanC
20:50:35 [Zakim]
DanC, you wanted to propose that we don't find material for a new issue, but we note the requestors stay tuned to fragmentsInXML-28
20:51:13 [Ian]
NW: I'm uncomfortable with that proposal since I'm not sure what the Core WG can do to get to PR.
20:51:28 [Ian]
DC: I think that the Core WG should try to satisfy the commenter.
20:51:46 [Ian]
TB: I'd be willing to second DC's proposal to formally attach this input to issue 28.
20:51:59 [Ian]
TB: TBL has convinced me that there's something here we can't ignore.
20:52:07 [Ian]
TBL: That's fine by me.
20:52:33 [Ian]
Resolved: Include this question as part of issue 28.
20:52:58 [Ian]
PC: I'd like minutes to say what, if anything, we are saying to Core WG.
20:53:05 [DanConn]
... TAG isn't instructing the XML Core WG in any particular way...
20:53:09 [Ian]
DC: Nothing special; let Core WG do as it usually does.
20:53:17 [DanConn]
... other than to address the comment in the usual way.
20:53:35 [Ian]
PC: Thank you, that's fine.
20:54:24 [Ian]
Action IJ: Add this to issue 28 (with reference to XInclude).
20:54:34 [Ian]
20:55:27 [Ian]
1. xmlProfiles-29
20:55:30 [Ian]
20:55:53 [Ian]
TB: I'm still uncomfortable here since CL claims there's a big issue here that needs solving. Not in my experience.
20:56:01 [Ian]
TB: I think we need more feedback from the community.
20:56:30 [Ian]
Proposal: Move NW proposal to www-tag
20:56:31 [Ian]
20:57:04 [DanConn]
"Considering ID attributes"
20:57:06 [DanConn]
20:57:43 [Ian]
20:57:55 [DanConn]
minimal effort for who? not the readers of the XML specs
20:58:02 [Ian]
ack DanC
20:58:03 [Zakim]
DanC, you wanted to express opposition to Norm's skunkworks
20:58:04 [Stuart]
ack Norm
20:58:05 [PaulC]
David O is leaving the meeting now.
20:58:30 [Ian]
DC: If NW's skunkworks proposal, please don't send out in TAG name. There are a lot more readers than writers.
20:58:47 [Ian]
NW: I'm not suggesting this as the sum total; this is "one extreme."
20:58:50 [TBray]
20:59:02 [Ian]
TBL observes that NW's proposal amounts to a diff.
21:00:28 [TBray]
Dan: that's what Norm is about to post it
21:00:48 [Norm]
21:00:53 [TBray]
21:02:08 [Ian]
TB: I suggest proposing to www-tag, but with a status section that we don't know whether it represents TAG consensus, but well-enough cooked to get feedback.
21:02:25 [Ian]
Resolved: Send NW proposal (0012) to www-tag
21:02:32 [Ian]
Action NW: Forward proposal to www-tag.
21:02:34 [Ian]
21:03:07 [Ian]
21:03:16 [Ian]
SW: Any discussion of NW summary?
21:03:20 [Ian]
21:03:46 [Ian]
NW: I suggested one to pick.
21:04:23 [Ian]
TB: I am increasingly convinced that there would be benefit to the community if W3C published a Rec that was not mandatory, but could be used when appropriate to improve interoperability.
21:04:28 [Ian]
TB: I am favoring Sandro's proposal:
21:04:35 [Ian]
21:04:38 [Stuart]
21:05:04 [Ian]
TB: Like NW, I could live with "none".
21:05:54 [Ian]
IJ: Do you really want the full machinery of the Rec track, or would Note suffice?
21:05:58 [Ian]
TB: Rec track.
21:06:51 [Ian]
TB: If we think this should go to Rec, we can either write it or go back to the Director/AC on which other group should address.
21:07:32 [PaulC]
21:07:46 [Ian]
TB Proposal: Suggest that W3C take one of these proposals and publish as a W3C Rec.
21:08:01 [Stuart]
ack TBray
21:08:09 [Ian]
PC: I think I prefer publishing as a WD with a status section with the intention to take to Rec.
21:08:10 [Ian]
ack PaulC
21:08:20 [Ian]
PC: I would prefer WD over Note to get wider review.
21:09:10 [Ian]
[No support to publish directly as Note.]
21:10:29 [Ian]
[Some discussion of splitting big pieces into smaller documents to advance them according to ripeness.]
21:12:45 [Ian]
TB Proposal: The TAG thinks W3C should proceed with a recommendation for a data format for namespace docs (not compulsory) and that such a document should follow the Rec track process. The content of the document should be taken from the RDDL challenge proposals; they are
21:12:52 [Ian]
isomorphic in technical content.
21:13:02 [Ian]
NW: Seconded.
21:14:09 [TBray]
TimBL: s/The content/The initial content/
21:14:33 [TBray]
21:14:37 [TimBL]
in favor
21:14:43 [PaulC]
Paul is in favor.
21:14:46 [Ian]
In favor: TB, PC, TBL, NW
21:14:51 [Ian]
Objections: None.
21:14:57 [Roy]
21:15:01 [Ian]
Abstentions: DC, SW
21:15:15 [Ian]
[Roy in favor]
21:15:30 [Ian]
[We note that DO is no longer in the meeting]
21:16:12 [Ian]
Resolved: The TAG thinks W3C should proceed with a recommendation for a data format for namespace docs (not compulsory) and that such a document should follow the Rec track process. The initial content of the document should be taken from the RDDL challenge proposals; they are isomorphic in tecnical content.
21:16:59 [Ian]
Action PC, TB: Write up a WD.
21:17:16 [Ian]
[Enlisting the help of the contributors]
21:17:26 [Ian]
DC: Please include drawbacks in the draft.
21:18:15 [Ian]
21:18:19 [DanConn]
e.g. using an HTML dialect (ala Sandro's proposal) for the RDF namespace wouldn't work, I don't think.
21:18:35 [Ian]
21:18:39 [Ian]
# binaryXML-30
21:19:12 [Ian]
TB: There seem to be real requirements out there to be able to send info around in a manner that is either (1) more compact or (2) more rapidly parsed.
21:19:20 [Ian]
TB: I am convinced by some usage scenarios.
21:19:36 [Ian]
TB: I am, however, unconvinced that there is a single format that will meet the needs of the various applications.
21:19:47 [Stuart]
21:19:47 [Ian]
TB: There is work in this area in MPEG, but that's loaded with IPR problems.
21:20:01 [Ian]
TB: I think this should be a do-nothing unless somebody comes forward with a plausible candidate.
21:21:22 [Ian]
TB: I'd be reluctant to pour energy into this without a candidate that solves a broad range of problems.
21:21:32 [TBray]
and is royalty-free
21:22:00 [Ian]
TBL: The discussion has been about decompression on the fly on small devices.
21:22:55 [Ian]
TBL: The only time it's interesting - send message to someone with whom you share a knowledge of namespaces. [Scribe thinks TBL talked about partial evaluation as approach to problem in some cases.]
21:23:09 [Ian]
TBL: This is not generic magic you can sprinkle over XML documents generally.
21:24:11 [Ian]
IJ thinks TB was referring to this email:
21:24:13 [DanConn]
TBL's comments seem quite similar to my comments on trust boundaries and binary XML...
21:24:22 [Ian]
Robin Berjon:
21:24:31 [Ian]
SW: Is this an arch issue or an engineering document?
21:24:43 [Ian]
DC: Engineering, but applies to a number of WGs.
21:25:07 [Ian]
TB: I think we should defend XML as a generalized information format; prevent people from retreating to specialized formats.
21:26:06 [TimBL]
The idea is that you can't compact general things without some header info which explains what the short things will mean. Compression is available for desktop-sized machines in the general case, so one does not need binary XML in that case. The need is when you have a small device which cannot hold the decomression tree.
21:26:30 [Ian]
21:26:35 [Ian]
21:26:48 [TimBL]
Then, a prior knowledge of the XML namespaces it uses would allow one to make a faster encoding.
21:27:21 [Ian]
PC: A number of people in Microsoft are interested in this problem; I am looking forward to CL action is completed.
21:27:31 [Ian]
21:27:49 [TBray]
what TimBL said... but compression effectiveness depends on msg size, with big enough msgs you could compress effectively & self-descriptively
21:27:55 [Ian]
Completed DC action: Review of 1. TB's "How to Compare Uniform Resource Identifiers" draft finding.
21:28:11 [Ian]
SW: I'll move this up on the agenda next week.
21:28:16 [Ian]
21:28:29 [Ian]
PC: Let's focus on next week's agenda on who should be writing what.
21:29:03 [Ian]
21:29:08 [Ian]
RRSAgent, stop