Note: This log has been edited slightly, primarily to remove interactions prior to discussion beginning in earnest, and after the meeting was adjourned. Some TAG scheduling information has also been removed.
[10:35:58]
<Ian> TBL: Problems with previous minutes?
[10:36:05]
<Ian> ....TB expressed some concerns by email.
[10:36:27]
<Ian> ...my feeling is that while we may not have resolved some points listed in minutes, that's the direction it was headed.
[10:36:33]
<Ian> ...are you happy with the policy?
[10:36:39]
<Ian> TB: Yes. Quite reasonable.
[10:38:16]
<Ian> IJ: I again suggest a 24-hour review of minutes. What do people think?
[10:38:35]
<tim-lex> Add on Agenda: XFORMS what to do
[10:38:38]
<Roy> I prefer 24-hour review
[10:38:50]
<Zakim> +DOrchard
[10:39:02]
<Ian> PC: (to IJ) I'm flexible either way. There were few times we had to correct a synopsis on the AB list.
[10:39:12]
<Ian> ...but I can take time on a Tuesday to review minutes.
[10:39:33]
<Ian> NW: I agree with Paul.
[10:40:25]
<Ian> IJ: I have a preference for a 24-hour review. I will try that way for a while.
[10:40:30]
<Ian> TBL: Agenda additions?
[10:40:32]
<Ian> (None)
[10:40:35]
<Ian> --------------
[10:40:37]
<Ian> Action item review.
[10:40:57]
<Ian> 1. Sign Collab agreement
[10:40:58]
<Ian> RF: Done.
[10:41:37]
<Ian> IJ: Still need TB.
[10:41:44]
<Ian> 2. Issue tracking policy
[10:41:52]
<Ian> Status: Done.
[10:41:59]
<tim-lex> Zakim, who is here?
[10:42:00]
<Zakim> I see TimBL, Stuart, Paul, Norm, TBray, Ian, Roy, DOrchard
[10:42:03]
<Ian> 3. Register three issues from XML Protocols WG
[10:42:14]
<Ian> Status; Done. See issues list http://www.w3.org/2001/tag/ilist
[10:42:29]
<Ian> 4. Get editable CVS space for TAG
[10:42:47]
--> TimBray (~tbray@00-50-ba-d3-1a-2d.bconnected.net) has joined #tagmem
[10:42:50]
<Ian> TBL: I've been talking with systems team. Not trivial (due to access control).
[10:42:54]
[10:42:54]
<TimBray> howdy
[10:43:12]
<Ian> TBL: I think people should get collaborator accounts (if you don't already have them).
[10:43:19]
<Ian> 5. Summarize input on www-tag
[10:43:29]
<Ian> Pending.
[10:43:58]
<Ian> 6. As part of preparation for TAG panel at W3C's Technical Plenary 2002, solicit input from chairs on what issues the TAG should address, and which documents the TAG should produce.
[10:44:10]
<Ian> Done: http://lists.w3.org/Archives/Member/chairs/2002JanMar/0019.html
[10:44:54]
<Ian> DO: Some confusion about the action item. The minutes said request to chairs for issues. I thought action was more about requesting information at panel.
[10:45:07]
<Ian> TBL (looking at DO's email): Looks fine to me.
[10:45:18]
<Ian> ...we will be presenting info about panel and we will also be listening to them.
[10:45:43]
<Ian> PC: TAG participants should also remember that the tech plenary panel is a public event. Need to ensure that topics to be discussed can be discussed in public.
[10:45:56]
<Ian> TBL: My feeling is that most TAG topics should be discussed in the public forum.
[10:46:17]
<Ian> PC: Chairs might put issues before us that are not necessarily for public forum.
[10:46:55]
<Ian> NW: I have to return to my ftf meeting. Please call my mobile phone if you need to reach me.
[10:47:02]
<Zakim> -Norm
[10:47:08]
<Ian> -------------------------
[10:47:11]
<Ian> Upcoming meetings
[10:47:17]
<Ian> * 12 Feb ftf.
[10:47:25]
<Ian> TBL: We have booked video room at MIT.
[10:47:41]
<Ian> PC: TB, DO, and PC will attend by videoconf.
[10:48:10]
<Ian> ...please schedule the ftf meeting to start at 10am ET (7am PT).
[10:48:18]
<Ian> ...we are flexible on meal breaks and termination time.
[10:48:47]
<Ian> Stuart: I intend to travel to Boston.
[10:49:09]
<Ian> RF: I probably will not be able to join you.
[10:49:31]
<tim-lex> Zakim, mute Stuart
[10:49:32]
<Zakim> Stuart should now be muted
[10:49:41]
[10:49:45]
<tim-lex> Roy sounds clear now - sorry Stuart!
[10:50:19]
[10:51:15]
<Zakim> -Stuart
[10:51:32]
<Ian> Action IJ: Reschedule video conf times.
[10:51:43]
<Ian> Action PC/IJ: Test video link in advance.
[10:51:44]
<Zakim> +??P1
[10:52:09]
<Stuart> Zakim, ??P1 is me
[10:52:10]
<Zakim> +Stuart; got it
[10:52:48]
<Ian> ---
[10:52:50]
<Ian> Panel
[10:52:53]
<Ian> PC: See proposal:
[10:53:04]
<TimBray> I just went on speakerphone... holler if audio downgrades
[10:53:24]
<Ian> PC Proposal - http://lists.w3.org/Archives/Member/tag/2002Jan/0021.html
[10:53:43]
<Ian> TBL: Most important thing I'd like to see out of meeting : perceived holes.
[10:53:53]
<Ian> SW: Let's set expectations on how we will receive input.
[10:54:01]
<Ian> PC: To be covered in initial part of panel presentation.
[10:54:14]
<Ian> ...we'll start gathering data and experience over next couple of months.
[10:55:26]
<Ian> PC: please respond to my proposal by email. This is a natural agenda item for our ftf agenda.
[10:55:40]
--> DanC (~connolly@tux.w3.org) has joined #tagmem
[10:56:05]
[10:56:12]
<Ian> TBL: People at AC find more interesting what has not been decided: What does the TAG not yet know (instead of what they do know)?
[10:56:26]
[10:56:55]
[10:57:04]
<Ian> PC: I'll stay on top of this since both on TAG and plenary organizing committee.
[10:57:13]
<Ian> ---
[10:57:17]
<Ian> TAG and WWW Hawaii 2002/05
[10:57:34]
<Ian> TBL: Murray Maloney doing dev day. See email from Tim: http://lists.w3.org/Archives/Member/tag/2002Jan/0018
[10:57:41]
<Ian> Some TAG presence possibilities:
[10:57:49]
<Ian> - Interactive lunch (TAG walks around with mics)
[10:57:50]
<Ian> - Panel
[10:58:01]
<Zakim> +??P3
[10:58:27]
--> Chris (~chris@tux.w3.org) has joined #tagmem
[10:58:35]
<Ian> Zakim, ??P3 is Chris
[10:58:36]
<Zakim> +Chris; got it
[10:58:37]
<Chris> hi all
[10:58:55]
<Ian> PC: Query, Schema, and XSL WGs are meeting week after WWW2002.
[10:58:59]
<Chris> forgot we added half an hour ....
[10:59:06]
<Ian> ...some of us have to get back to North America in a timely fashion.
[10:59:32]
<Ian> TBL: Who on the call plans to be at dev day:
[10:59:34]
<Ian> [Details of individual attendance removed]
[11:03:07]
<Ian> PC: my pref is to have TAG talk in public as much as possible. Even a couple of people ok.
[11:03:18]
<Ian> TBL: We could do an
interactive lunch.
[11:03:52]
[11:03:53]
<Ian> ---
[11:04:04]
<Ian> TBL: What about more TAG stuff earlier in the week at the W3C track?
[11:04:14]
<Ian> PC: I'm doing a query presentation at the w3c track.
[11:04:22]
<Ian> TBL: W3C track is more educational.
[11:05:06]
<Ian> ---
[11:05:09]
<Ian> Calendar.
[11:05:18]
<Ian> Future holidays and meeting planning.
[11:05:48]
<Ian> PC: There are two Mondays in May with Candian/US holidays.
[11:06:07]
<Ian> ...I publish my WGs calendar 8-9 months in advance. I handle them way in advance, and I think the TAG needs to do the same.
[11:06:35]
<Ian> I'd like us to have a predictive calendar way in advance.
[11:06:47]
<tim-lex> http://www.w3.org/Member/Eventscal.html
[11:06:54]
[11:07:27]
<Ian> PC: Holiday information is subjective for each group.
[11:07:53]
<Ian> Action PC: Send IJ link to public calendar of holidays.
[11:08:06]
<Ian> PC: I'd like us to look forward several months to confirm Monday meetings.
[11:08:41]
<Ian> Action IJ/PC: Fill in calendar for next several months with holiday information and double check conflicts with Monday meetings.
[11:08:43]
<Ian> --------------------
[11:08:49]
<Ian> Issue tracking: Postponed.
[11:09:02]
<Ian> -------------------------------
[11:09:07]
<Ian> Technical issues:
[11:09:29]
<Ian> TBL: We don't have a list of issues to look at. (I hope in the future we will.)
[11:09:42]
<Ian> TBL: I would like to talk about the architectural space, and do some categorization.
[11:09:53]
<Ian> TB: We do have a list of issues - three have been accepted.
[11:10:30]
<Ian> Issues lsit:
[11:10:34]
<tim-lex> http://lists.w3.org/Archives/Public/www-tag/2002Jan/0063
[11:10:34]
<Ian> http://www.w3.org/2001/tag/ilist
[11:11:00]
<TimBray> http://lists.w3.org/Archives/Public/www-tag/2002Jan/
[11:13:16]
<Ian> TBL: Add a summary of resolution, and ensure link to resolution message.
[11:13:20]
<Ian> -----
[11:13:34]
<Ian> w3cMediaType-1: http://lists.w3.org/Archives/Public/www-tag/2002Jan/0174
[11:13:43]
<Ian> Should W3C WGs define their own media types?
[11:14:08]
<Ian> TB: I agree that the correct answer is "yes"
[11:14:28]
<Ian> TBL: RF's document talks about "visibility".
[11:14:58]
<Ian> TB: Some people raised point that there may be some cases where there's a low expectation that content will be served as a resource.
[11:15:14]
<Ian> TBL: "Yes, where there is a language being produced." As opposed to policy, for example.
[11:15:58]
<Ian> CL: To what extent are we advisable of tieing media types to namespaces.
[11:16:26]
<Ian> TBL: Fourth issue - "Should media types transition to URLs (so that we have the richness of various systems for making, e.g., transitive media types)?
[11:16:46]
<Ian> ...Digital signature people needed this. Don Eastlake drew up a draft of this (treating media type as a URL).
[11:16:58]
<Ian> PC: I'm not familiar with that draft.
[11:17:10]
<Ian> RF: I am, but not sure why it's needed.
[11:17:23]
<Ian> TBL: I'd like to declare consensus on w3cMediaType-1 "yes".
[11:17:39]
<Ian> SW: Two questions in this issue. We haven't talked about guidelines and policies yet.
[11:17:55]
<Ian> TB: Practical matter - who actually does "it". IETF? W3C WG?
[11:17:59]
<tim-lex> http://www.ietf.org/rfc/rfc3023.txt
[11:18:12]
<Ian> TB: Even though this is IETF work, the W3C WG needs to ensure that this happens.
[11:18:35]
<Ian> TBL: It's reasonable for the TAG to point to IETF work, or to say what we don't like of IETF work.
[11:18:51]
<Ian> ...our scope should include HTTP, e.g.
[11:18:57]
<Ian> PC: Summary of this issue is:
[11:19:19]
<Ian> - Guidelines: If the WG is defining something that can be served up as a resource, define a media type for it. The WG should take responsibility to ensure that it's done.
[11:19:37]
<Ian> TBL: I think we need to take it further:
[11:19:48]
<Ian> (TBL agrees with PC's statement.)
[11:20:12]
<Ian> TBL: I've found that having a registration document and a spec separate is kind of crazy. The job of the spec is to define the media type.
[11:20:56]
<Ian> ...things might fall between the cracks if delay between spec and registration of media type.
[11:21:57]
<Ian> TBL: We should tie registration to the Rec track process. We should get the media type before Recommendation.
[11:22:04]
<Ian> CL: IETF wants a stable spec.
[11:22:17]
<Ian> CL: We are asking people to serve content as early as CR.
[11:22:26]
<Ian> TBL: "x-" is deprecated.
[11:22:45]
<Ian> TB: Doesn't 3023 facilitate this?
[11:22:47]
<Ian> CL: I hope so.
[11:22:55]
[11:22:57]
[11:23:05]
<Ian> SW: Do we have formal liaisons with IETF?
[11:23:20]
<Ian> TBL: Yes. We can say to the IESG "The TAG would like it t work this way."
[11:23:41]
<Ian> CL: Should the media type registration form be a (normative) appendix to the spec?
[11:23:48]
<Ian> TBL: Is there a form in RFC 3023?
[11:24:11]
<Ian> RFC 3023: http://www.ietf.org/rfc/rfc3023.txt
[11:24:36]
<Ian> Resolved: Registration form for media types should be part of W3C technical reports.
[11:24:47]
<Ian> Question: Latest point by which registration must appear in spec?
[11:24:53]
<Ian> (Before CR or after CR?)
[11:25:03]
<Chris> before CR
[11:25:25]
<Ian> TBL: At start of CR. If there are no implementation problems, WG expects to advance to PR and to Rec with no serious changes.
[11:25:40]
<Chris> should be drafted, like the rest of the spec, in WD phase
[11:26:06]
<Ian> TBL: You register the mime type, and you attach it to a spec whose stability will mature. The promise you make when first attached you warn that it may change. And when goes to Rec, you guarantee that won't change.
[11:26:16]
<Ian> CL: What happens if it becomes incompatible.
[11:26:33]
<Ian> TB: media types are less sensitive to versions. Also, I don't think we should bend policy for the exceptional case.
[11:26:39]
<Ian> TBL: Namespace will refine granularity.
[11:26:54]
<Ian> PC: I think we should state this.
[11:27:32]
<Ian> DO: As TB said, the identifier is fairly coarse-grained; people should go to namespace for more info. This is guidance to a process that we think spec developers should go through.
[11:27:37]
<Ian> W3C namespace persistence policy:
[11:28:00]
<Ian> http://www.w3.org/1999/10/nsuri
[11:28:37]
<Ian> TBL: You have to make clear the policy attached to the namespace (e.g., will never change, may change in compatible means, etc.). WG asked to state policy assocated with namespace.
[11:29:36]
<Ian> Action DO: Take a first stab at writing a policy to summarize resolution of w3cMediaType-1
[11:29:38]
<Ian> -----------
[11:29:57]
<Ian> customMediaType-2
[11:30:10]
<Ian> Endorsement of RFC 3023?
[11:30:18]
<Ian> RF: Has this been tested? Do browsers work with this?
[11:31:05]
<Ian> RF: There's a content-handler screen in most browsers that allows you to assign a media type to a handler.
[11:31:28]
<Ian> TB: The whole notion of +xml is to allow generic XML processors to get in there.
[11:31:36]
<Ian> ...as far as I know, nobody has tried this.
[11:32:03]
<Ian> RF: I'm worried about whether the "+" will be parsed by media type parsers.
[11:32:14]
<Ian> TBL: Is there SVG with "+" on it?
[11:32:16]
<Ian> CL: Yes.
[11:32:31]
<Ian> TBL: If it broke browsers, we might have already heard about it.
[11:32:40]
<Ian> (Turning to issue three)
[11:32:51]
[11:33:34]
<Ian> TBL: I think that the namespace of the first element is definitive of the document. You can't jump into the middle of a document in a space you know, if you don't know the outermost namespace.
[11:33:51]
<Ian> DO: One objection on mailing list: there was a shorthand example of xslt with root node as HTML.
[11:34:09]
<Ian> ...I think you need to clarify your definition: is it the actual encoded root element, or the "unshorthanded" version.
[11:34:19]
<Ian> TBL: Is that document fundamentally an xslt script or an html page?
[11:34:29]
<Ian> ...you can look at it as an HTML page with some smart bits in it.
[11:34:35]
<Ian> CL: Or as a template that will produce and HTML page.
[11:34:38]
<TimBray> afk for 30 seconds
[11:34:48]
<Ian> DO: Given that it's in the xslt spec, pretty clear that for xslt processors.
[11:35:18]
<Ian> TBL: What could an HTML processor seeing xslt do? Panic? Call out a plug-in?
[11:35:52]
<Ian> DO: I'd want to distinguish at the top level.
[11:36:09]
<Ian> TBL: It's nice for an xml document to be self-describing. The only piece you can pick is the outermost piece.
[11:36:21]
<DanC> the XSLT/HTML example shows that the meaning of a document depends on what sort of agent you present it to. Present that document to an HTML user agent, and it'll sorta display it (it'll get confused by the XSLT tags). Present it to an XSLT engine and it'll fill out the template.
[11:36:41]
<Ian> DO: If you said "logical root node" in the xslt/html case, would work.
[11:36:44]
<DanC> maybe it shouldn't be that way, but it is.
[11:36:53]
<Ian> DO: HTML short hand at top is actually XSLT.
[11:37:07]
<Ian> TB: We could also bite the bullet and say that this case is the exception that proves the rule.
[11:37:33]
<Ian> TBL: We need to define a rule that will work everywhere. We can build in exceptions that we already know of.
[11:38:04]
<Ian> TBL: PHP3 documents really HTML documents with smart bits built in. In fact, the way you process the document is to feed to xslt processor.
[11:38:17]
<Ian> DO: Does this issue come up with xml query and the use of query constructors?
[11:38:55]
<Ian> PC: I don't think we've done enough thinking about this yet. TBL is talking about an outer wrapper. We've not talked anywhere about how principle processors calls secondary processor. That's probably a bug in the overall arch. Not sure we
[11:39:02]
<Ian> get additional value by talking only about root.
[11:39:08]
<Ian> TBL: MathML WG's problem:
[11:39:14]
<Ian> - They've got MathML defined as a spec.
[11:39:18]
<Ian> - Can embed in xhtml.
[11:39:27]
<Ian> - You can write a formula and display in different browsers.'
[11:39:48]
<Ian> - But browsers have different behavior depending on how the content is served.
[11:40:38]
<Ian> - Math folks have to browser sniff and either serve as "HTML" or as @@
[11:40:47]
[11:40:57]
<Ian> TimBL: Netscape is dispatching on toplevel namespace, IE is not.
[11:41:24]
<Ian> TBL: How to make documents selfdescribing without relying on media type.
[11:41:30]
<Ian> CL: Which browser is misbehaving?
[11:41:36]
<Ian> TB: Have to say one of them is.
[11:42:14]
<Ian> TBL Proposal:
[11:42:55]
<Ian> - Software that purports to support a given namespace and which is given an xml document where the document element is in that namespace should process it correctly.
[11:43:06]
<Ian> TB: Independent as how it's served (media type)?
[11:43:18]
<Ian> TBL: Media type, as RF said, is a hint.
[11:43:59]
<Ian> TB: An issue ismaking me nervous. Software should dispatch on namespaces. However, I hesitate to go in the direction of deprecating media types.
[11:44:31]
<Ian> ...I don't want to fire up an xml processor and parsing the source to find out that content should be handed to an SVG processor. People should not serve everything as application/xml.
[11:45:00]
<Ian> TBL: Advantage of putting an svg+xml media type is: (1) more efficient (2) proxies can see into it (3) software can see into it (e.g., operating system can change icon).
[11:45:11]
<Ian> ...All the same, you should also be able to dispatch on namespace.
[11:45:16]
<Ian> RF: Security issues on browser side.
[11:45:51]
<Ian> ...this has shown up before. Handler algo can bypass security mechanism.
[11:46:35]
<Ian> RF: If you've been given something that has a specific media type, and the contents say it's something else, you have to have the sense to stop and ask the user to confirm.
[11:47:13]
<Ian> TB: I think it's bad behavior to sniff content and ignore media type (e.g., when bytes suggest a file is HTML0.
[11:47:29]
<Ian> ...(bad behavior for browsers and other software).
[11:48:02]
<Ian> TB: Religious convictions by some communities: "If we say (in the header) that it's UTF-16, then damnit it is."
[11:48:54]
<Ian> PC: I'd like someone to write up scenarios as part of our work on issue 3.
[11:49:05]
<Ian> ..there are obviously strong opinions on this matter.
[11:49:20]
<Ian> TBL: In our last discussions, we've strayed to generic scenarios - (charset, for example).
[11:49:42]
<Ian> ...For instance, charset is hairier - can't sniff.
[11:49:59]
<Ian> CL: You can say that authoring tool knows information and XML provides perfectly good manner to do this.
[11:50:17]
<Ian> TBL declares a rat-hole.
[11:50:35]
[11:51:00]
<Ian> TBL: Good idea to write up scenarios that demonstrate where there are problems. I think we should also write up areas where there is not contention.
[11:51:05]
<Ian> TBL summarizing:
[11:51:08]
<TimBray> Ian, disagree with "charset... can't sniff" - point is that XML processor almost always *can* figure out what the charset is, better than the server
[11:51:29]
[11:51:36]
<Ian> TBL: Summary to collect scenarios?
[11:51:43]
[11:52:17]
<Ian> Action TB: I will post a note to www-tag summarizing what I see as the issues on this. I think we have pretty good agreement in principle that dispatching on namespaces is a good thing and that media types should not be deprecated. Question of corner cases.
[11:52:26]
<Ian> RF: I can add some information on the fundamentals of messages.
[11:52:46]
<Ian> ...for example on the subject of charsets in the IETF: all of the components in the system need to be consistent in how they interpret the charset.
[11:53:23]
<Ian> RF: If some processors look at charset in media type and others inside the document, then it's possible to introduce security errors by modifying the charset in the content.
[11:53:48]
<Ian> CL: You can get a situation where you have an incorrect encoding in the file, and when you save to disk, you have to rewrite.
[11:54:00]
<Ian> TBL: Fundamental question as to whether charset is intrinsic or extrinsic.
[11:54:15]
<Ian> CL: For SVG registration, I was expecting to require that they always be the same.
[11:54:42]
<Ian> PC: Let's do technical work at front of meeting.
[11:54:50]
<Ian> TBL: I will need an even sharper guillotine.
[11:55:08]
<Ian> PC to TB: Give examples of resources on the web that people do things differently.
[11:56:03]
<Ian> TB: About issue 2: Seems easy to me: if someone thinks we should take a stand against 3023, please do so real soon. Otherwise we will adopt.
[11:56:13]
<Ian> RF: I think that Mark was talking about section 7.1 specifically.
[11:56:19]
<Ian> TBL: So, propose that for issue 2:
[11:56:29]
<Ian> - We don't see any problem with 3023 except for charset issue.
[11:56:52]
<Ian> PC: I haven't read this yet. I'd like to hold up until next week.'
[11:57:02]
<Ian> CL: I've read, and participated in its formulation.
[11:57:10]
<Ian> Homework: Read RFC 3023
[11:58:02]
<Ian> IJ: I intend to make RFC log available immediately. Will send summary to TAG for review for 24 hours.
[11:58:06]
<Zakim> TAG_Monthly()10:30AM has ended