IRC log of tagmem on 2002-06-17
Timestamps are in UTC.
- 18:48:21 [RRSAgent]
- RRSAgent has joined #tagmem
- 18:48:25 [Zakim]
- Zakim has joined #tagmem
- 18:50:18 [DanCon]
- Zakim, this will be TAG
- 18:50:19 [Zakim]
- ok, DanCon
- 18:51:36 [Stuart]
- Stuart has joined #tagmem
- 18:54:48 [DanCon]
- RRSAgent, pls record my regrets for 24Jun; I'll be at an MIT LCS meeting.
- 18:54:48 [DanCon]
- I'm logging. I don't understand 'pls record my regrets for 24Jun; I'll be at an MIT LCS meeting.', DanCon. Try /msg RRSAgent help
- 18:55:16 [DanCon]
- Ian, any particular reason to include "completed actions" twice in the agenda?
- 18:55:27 [DanCon]
- as 1.0.6 and 1.2?
- 18:55:41 [DanCon]
- er... 1.1.6 and 1.2
- 18:56:44 [DanCon]
- and norm's action on formatting properties shouldn't be swept under the 1.2 rug; it's for discussion
- 18:57:04 [Zakim]
- TAG_Weekly()2:30PM has now started
- 18:57:12 [Zakim]
- +??P0
- 18:57:56 [Zakim]
- +??P1
- 18:58:09 [DanCon]
- odd... http://www.w3.org/2001/tag/2002/0607-intro is dated 7 June 2002 at the top but $Date: 2002/06/14 20:54:17 $ at the bottom
- 18:58:12 [Stuart]
- Zakim, ??P1 is me
- 18:58:13 [Zakim]
- +Stuart; got it
- 18:58:37 [Stuart]
- Zakim, ++P0 is Norm
- 18:58:38 [Zakim]
- sorry, Stuart, I do not recognize a party named '++P0'
- 18:58:55 [Zakim]
- +Tim.Bray
- 18:58:58 [TBray]
- TBray has joined #tagmem
- 18:59:01 [Stuart]
- Zakim, ??P0 is Norm
- 18:59:02 [Zakim]
- +Norm; got it
- 18:59:09 [Norm]
- Norm has joined #tagmem
- 19:00:01 [Zakim]
- +DanC
- 19:00:54 [TBray]
- I get a 404
- 19:01:18 [TBray]
- s/galley/gallery/
- 19:01:21 [Ian]
- zakim, what is code?
- 19:01:22 [Zakim]
- I don't understand your question, Ian.
- 19:01:23 [Zakim]
- +DOrchard
- 19:01:40 [Norm]
- 0824, Ian
- 19:01:43 [Roy]
- Roy has joined #tagmem
- 19:01:45 [Ian]
- Thanks Norm.
- 19:01:45 [Zakim]
- +Ian
- 19:01:56 [Norm]
- zakim, who's here?
- 19:01:57 [Zakim]
- On the phone I see Norm, Stuart, Tim.Bray, DanC, DOrchard, Ian
- 19:02:02 [Zakim]
- On IRC I see Roy, Norm, TBray, Stuart, Zakim, RRSAgent, Ian, DanCon
- 19:02:33 [Zakim]
- +??P5
- 19:02:40 [Norm]
- zakim, p5 is Roy
- 19:02:42 [DaveO]
- DaveO has joined #tagmem
- 19:02:42 [Zakim]
- sorry, Norm, I do not recognize a party named 'p5'
- 19:02:48 [Norm]
- phhppht
- 19:02:56 [Ian]
- zakim, P5 is Roy
- 19:02:56 [Norm]
- zakim, ??p5 is Roy
- 19:02:58 [Zakim]
- sorry, Ian, I do not recognize a party named 'P5'
- 19:02:59 [Zakim]
- +Roy; got it
- 19:02:59 [DanCon]
- Zakim, ??P5 is aRoom
- 19:03:03 [Zakim]
- sorry, DanCon, I do not recognize a party named '??P5'
- 19:03:08 [DanCon]
- Zakim, Roy also holds PaulC
- 19:03:10 [Zakim]
- +PaulC; got it
- 19:03:18 [DanCon]
- Zakim, PaulC left Roy
- 19:03:19 [Zakim]
- -PaulC; got it
- 19:03:31 [DanCon]
- Zakim, DaveO also holds PaulC
- 19:03:32 [Zakim]
- sorry, DanCon, I do not recognize a party named 'DaveO'
- 19:03:52 [DanCon]
- Zakim, DOrchard also holds PaulC
- 19:03:54 [Zakim]
- +PaulC; got it
- 19:03:58 [DanCon]
- Zakim, who's here?
- 19:04:02 [Zakim]
- On the phone I see Norm, Stuart, Tim.Bray, DanC, DOrchard, Ian, Roy
- 19:04:04 [Zakim]
- DOrchard has PaulC
- 19:04:07 [Zakim]
- Roy has no one
- 19:04:10 [Zakim]
- On IRC I see DaveO, Roy, Norm, TBray, Stuart, Zakim, RRSAgent, Ian, DanCon
- 19:04:17 [DanCon]
- expected: chris, tim
- 19:04:26 [Ian]
- Agenda: http://www.w3.org/2002/06/17-tag
- 19:04:31 [Ian]
- Scribe: IJ
- 19:04:38 [Ian]
- All here but TimBL, Chris
- 19:04:44 [Ian]
- Agenda commetns?
- 19:04:44 [Zakim]
- +ChrisL
- 19:05:29 [Chris]
- Chris has joined #tagmem
- 19:06:35 [Ian]
- [DO item confirmed.]
- 19:06:46 [Ian]
- Next meeting: 24 June?
- 19:06:49 [Ian]
- DC: TimBL and CD not available.
- 19:06:53 [Ian]
- s/CD/DC/
- 19:07:10 [Chris]
- ok, confirmed for me
- 19:07:20 [Ian]
- [No other regrets than DC, TimBL]
- 19:07:27 [Ian]
- Resolved: # Accept 10 June minutes:
- 19:07:30 [Ian]
- http://www.w3.org/2002/06/10-tag-summary
- 19:07:35 [Chris]
- yes, minutes are fine
- 19:07:49 [Ian]
- Completed action items verified.
- 19:07:56 [Ian]
- No actions withdrawn.
- 19:08:00 [Ian]
- -------------
- 19:08:04 [Ian]
- New issues?
- 19:08:09 [Ian]
- * PSVI considered harmful? (email from TB).
- 19:08:12 [Ian]
- http://lists.w3.org/Archives/Public/www-tag/2002Jun/0085.html
- 19:08:41 [Ian]
- TB: What was bothering me was that augmented info sets could only come about through schema validation (namely just one).
- 19:08:43 [DaveO]
- q+ PaulC
- 19:08:57 [DanCon]
- I 2nd the proposal to accept this issue. I'm not sure exactly what it is or what we'll do about it, but it's clear that doing something is worthwhile.
- 19:09:05 [Ian]
- TB: That strikes me as wrong. It may be worth specifying type-augmented infoset in abstract/generic terms.
- 19:09:21 [Ian]
- TB summarizing discussions:
- 19:09:49 [Ian]
- See email from Noah: http://lists.w3.org/Archives/Public/www-tag/2002Jun/0110.html
- 19:10:07 [DanCon]
- "(b) Applications that depend on a PSVI now require a very complex,
- 19:10:08 [DanCon]
- heavy-weight schema validation process, rather than a relatively simple
- 19:10:08 [DanCon]
- parsing process." -- clark, http://lists.w3.org/Archives/Public/www-tag/2002Jun/0119.html. Hear hear.
- 19:10:10 [Ian]
- CL: Seems like same as using DTD to get information and using it to enforce validity?
- 19:10:42 [DaveO]
- q-
- 19:10:43 [Ian]
- TB: Seems that PSVI repeats some mistakes DTDs made (conflation of two orthogonal issues).
- 19:10:48 [DaveO]
- q- paulc
- 19:11:25 [Ian]
- PC: Why is this a TAG issue and not to be dealt with in Schema/Query WG?
- 19:11:30 [DanCon]
- a reservation: it's not clear how this is "web architecture" as opposed to 2nd-guessing a WG's decisions. But though it's not clearly a web-architecture issue, it is a W3C architecture issue, in that it affects many WGs.
- 19:11:37 [Norm]
- q+
- 19:11:42 [Ian]
- TB: It seems to me that it cuts across work.
- 19:12:24 [Ian]
- TB: Maybe all the TAG needs to do is to raise this as an issue and ask the appropriate group to work on it. The important arch principle here is "where do types come from?" Types only being meaningful in context of PSVI is problematic, I think.
- 19:12:34 [Ian]
- DC: I share PC's concern about TAG second-guessing other WG's work.
- 19:12:44 [Ian]
- DC: It's clearly W3C architecture if not Web architecture.
- 19:12:56 [Ian]
- DC: If we let each WG optimize locally, we may not get a global optimization.
- 19:13:03 [Ian]
- DC: I support accepting this as an issue.
- 19:13:28 [Roy]
- [aside] Is there an XML processing architecture WG?
- 19:13:30 [Ian]
- NW: I share some of PC's concern as well. I'm not certain that some WGs will look at this at a broad enough level.
- 19:13:36 [Ian]
- NW: I second supporting accepting this issue.
- 19:13:47 [Ian]
- SW: Can we take this to XML COre?
- 19:13:49 [Ian]
- PC: No.
- 19:14:10 [Ian]
- PC: There is broad representation in this area. There are several groups already working together on this.
- 19:14:15 [Ian]
- (E.g., schema, query, xforms, ...)
- 19:14:58 [DaveO]
- q+
- 19:15:08 [Norm]
- q-
- 19:15:08 [Ian]
- TB: I read the query data model piece. It talks about the PSVI and clearly creates the impression in the reader's mind that the only way to get type info is through a w3c schema parser. I think that's wrong.
- 19:15:46 [Ian]
- PC: I'm reluctant to have the TAG take up an issue that questions some of the rationale why the Schema WG was created. E.g., schema charter accepted to model DTD functionality.
- 19:16:34 [Ian]
- TB: It is my opinion that annotating infosets through types is a good idea. But there are other ways through schema validation. And that annotating with default values is almost always a mistake. [Scribe would like review of this statemetn.]
- 19:16:49 [DanCon]
- indeed, the schema WG charter was accepted 4 years ago. i.e. we have 4 years of experience since then.
- 19:17:27 [Ian]
- DO: Maybe what PC is hearing is that this is an opportunity for the TAG to live up to one perceived function - technical coordination and expertise.
- 19:17:46 [Ian]
- DO: I hear TB saying infoset augmentation is more general than schema validation.
- 19:18:09 [Ian]
- PC: The XML Activity made an explicit decision that any WG could augment the infoset since the Core WG didn't want to do this as a critical work item.
- 19:18:36 [Ian]
- PC: A decision was made to delegate to the Schema WG to do this.
- 19:19:10 [TBray]
- er, anyone else get dropped?
- 19:19:31 [Zakim]
- -Tim.Bray
- 19:19:36 [Zakim]
- +Tim.Bray
- 19:19:41 [Ian]
- PC: Some pieces of thread have not been addressed yet.
- 19:19:48 [Chris]
- q+wierd noise has stopped
- 19:19:51 [Ian]
- PC: I think TB has not addressed Schema WG as an individual.
- 19:19:58 [DaveO]
- q-
- 19:20:03 [DaveO]
- cool queue
- 19:20:04 [DanCon]
- queue=
- 19:20:15 [Chris]
- thanks, dan
- 19:20:19 [Roy]
- q+
- 19:20:21 [Ian]
- PC: If you are going to define user-defined operators, the type system can't be completely pluggable. Otherwise query will have to be so flexible that we won't get it done.
- 19:20:33 [DaveO]
- q-
- 19:20:35 [DaveO]
- q+
- 19:20:50 [DanCon]
- hmm... paul's point that we should persue the matter with the WG 1st... I could live with that.
- 19:21:14 [Chris]
- yes, that is the principle we use as the first filter
- 19:21:51 [Ian]
- RF: I think the Schema WG has approached the issue from the perspective of schemas. TB wants to approach from the perspective of the Infoset. Why is it necessary to get Schema WG's permission here?
- 19:22:02 [Zakim]
- +TimBL
- 19:23:28 [TBray]
- q+
- 19:23:52 [Roy]
- q-
- 19:23:57 [tim-zzzZZ]
- tim-zzzZZ has joined #tagmem
- 19:23:58 [Roy]
- q+
- 19:24:09 [Ian]
- ack TBray
- 19:24:51 [Ian]
- TB: I think that there are a bunch of issues here well worth discussing: type-augmented infosets (outside of query), and would be excellent to do this in an interoperable manner.
- 19:25:04 [timbl]
- RRSAgent, pointer?
- 19:25:04 [RRSAgent]
- See http://www.w3.org/2002/06/17-tagmem-irc#T19-25-04
- 19:25:07 [Ian]
- TB: Granted, there should be a liaison with the Schema WG.
- 19:25:21 [Roy]
- I think TB has identified a gap in the architecture. So the real question is who should be asked to address/fill the gap?
- 19:25:26 [Ian]
- TB: We don't know what they think yet. I remain convinced that this is an issue for the TAG.
- 19:25:49 [Chris]
- q+
- 19:26:05 [Roy]
- q-
- 19:26:06 [Ian]
- ack Roy
- 19:26:10 [Ian]
- ack Chris
- 19:26:25 [DaveO]
- q+
- 19:26:30 [Ian]
- CL: How does this process differ from a charter proposal? I agree with TB's point about augmention-broader-than-schema.
- 19:26:52 [Ian]
- CL: When HTML people wanted to use XLink, they wanted to through augmention rather than through syntax.
- 19:27:08 [DaveO]
- CL said my point
- 19:27:08 [Ian]
- CL: But I also understand PC's point that people should talk to existing WGs where this is in scope.
- 19:27:10 [DaveO]
- q-
- 19:27:25 [Ian]
- CL: What would more discussion in the TAG add?
- 19:27:31 [DanCon]
- I learned quite a bit about XML schema requirements around PSVI stuff in an xmlschema-dev thread: http://lists.w3.org/Archives/Public/xmlschema-dev/2001Jun/0187.html
- 19:27:53 [DaveO]
- q+ paulc
- 19:28:08 [Ian]
- TB: We could ascertain whether there are apt to be infoset augmentation use cases outside of schema. And is it an arch principle that there should be a std way to do infoset augmentation and to exchange such augmentations (i.e., syntax).
- 19:28:28 [DaveO]
- q- paulc
- 19:28:31 [Ian]
- TB: And another principle - is it sufficient for Query WG to rely on current version of augmentations as proposed by Schema WG
- 19:29:03 [Ian]
- PC: One of the comments made at the processing model Workshop: fallacy in the augmentation design was that everyone who wishes to augment assumes they are last.
- 19:29:22 [timbl]
- q+
- 19:29:23 [Ian]
- PC: Question about whether XML Activity will take up this challenge was recently put to the AC.
- 19:29:57 [DaveO]
- don't log on irc then.
- 19:30:00 [DanCon]
- I don't think this issue is exactly what was discussed at the xml processing model workshop
- 19:30:46 [Ian]
- TBL: Just because a WG is going to work in an area doesn't mean that TAG discussion is inappropriate in that area.
- 19:31:02 [DaveO]
- q+
- 19:31:26 [Ian]
- TBL: I think it's still useful for the TAG to sync up with WGs (especially early, when a WG may have different ideas about architecture).
- 19:31:29 [Ian]
- ack Timbl
- 19:31:44 [TBray]
- http://www.w3.org/TR/query-datamodel/
- 19:31:49 [TBray]
- the doc above says:
- 19:32:16 [Ian]
- DO: If PC's thesis is correct (some work done in W3C about processing) then we could say "watch this group to see what they do."
- 19:32:30 [TBray]
- The data model is defined in terms of the [XML Information Set] after XML Schema validity assessment. XML Schema validity assessment is the process of assessing an XML element information item with respect to an XML Schema and augmenting it and some or all of its descendants with properties that provide information about validity and type assignment. The result of schema validity assessment is an augmented Infoset, known as the Post Schema-Validation Infos
- 19:32:37 [Ian]
- DO: I don't think we want to have issues about tracking work of other groups to see if they are doing the right thing.
- 19:32:43 [TBray]
- I have grave arch concerns with this assertion
- 19:32:48 [Ian]
- SW: What about having a round of discussions with Henry Thompson and others?
- 19:33:08 [Ian]
- PC: That's my point - discussion has not been sufficient yet.
- 19:33:23 [DaveO]
- q-
- 19:33:28 [timbl]
- Zakim, mute me
- 19:33:29 [Zakim]
- TimBL should now be muted
- 19:34:50 [Ian]
- DC: I'm happy to ask the XML Schema WG to do a version that has PSVI separate from validation. Maybe they would do this. They are collecting requirements.
- 19:35:14 [Ian]
- DC: I'd still rather it be an issue for us anyway.
- 19:35:38 [timbl]
- Spunds as though if there is this much discussion about it, then it may be an issue.
- 19:36:17 [Ian]
- Action DC: Talk to XML Schema WG about PSVI. Report to tag, who expects to decide whether to add as an issue next week.
- 19:36:18 [Ian]
- ------------------
- 19:36:23 [DaveO]
- It's certainly a "lower case i" issue, the discussion is about whether it's a "upper case I" Issue
- 19:36:32 [DanCon]
- ack Timbl
- 19:36:34 [Ian]
- New issue question * XLINK, HLINK, or neither? (email from TBL).
- 19:36:43 [Ian]
- TimBL email: http://lists.w3.org/Archives/Public/www-tag/2002Jun/0116.html
- 19:37:32 [Chris]
- q+
- 19:37:46 [DaveO]
- q+
- 19:38:02 [DaveO]
- I have some info background on xlink discussions..
- 19:38:08 [Ian]
- TBL: I thought that "hlink" was for gui semantics. Should RDF be used or schema annotations?
- 19:38:10 [Roy]
- xlink:href --> xmlns supported. Is that okay?
- 19:38:30 [Roy]
- q+
- 19:38:41 [Chris]
- yes, it implies namespace support
- 19:38:59 [Norm]
- Norm has joined #tagmem
- 19:39:06 [Chris]
- xlink is *not* only for hyperlinks
- 19:39:26 [timbl]
- Should xlink be required for
- 19:39:35 [timbl]
- (a) all URI parameters
- 19:39:52 [timbl]
- (b) all URI params pointing to documents which are hyperlinked fr om this one
- 19:39:59 [timbl]
- (c) nothing it is optional
- 19:40:05 [timbl]
- (d) none fo the above
- 19:40:18 [timbl]
- (e) all the above
- 19:40:18 [Norm]
- q+
- 19:40:24 [Ian]
- ack Chris
- 19:40:42 [Ian]
- CL: xlink is not just for hyperlinks. It's chartered to support replaced content (like images).
- 19:41:03 [Ian]
- TBL: I would include that.
- 19:41:05 [DanCon]
- timbl: image embedding is part of (my concept of) hypertext.
- 19:41:46 [Ian]
- CL: Some W3C WGs coming up with other mechanisms that rely on PSVI and hence Schema.
- 19:41:54 [timbl]
- q+
- 19:42:04 [Ian]
- CL: The notion of having a cell phone using a schema strikes me as "not entirely thought through."
- 19:42:10 [Ian]
- ack DaveO
- 19:42:33 [Ian]
- DO: Why should we look at this as an issue given what the charter of xlink says?
- 19:42:41 [Chris]
- using a schema "to find out where the links are"
- 19:42:54 [Chris]
- especially since it needs a link to get the schema
- 19:43:16 [Ian]
- DO: Shouldn't people talk to the WGs responsible for these technologies?
- 19:43:42 [DanCon]
- interesting... hyperlinking only... SVG went and used it for symbol references, which isn't hyperlinking, is it?
- 19:44:01 [Ian]
- RF: W3C has to do a better job of setting reqs on its specifications. When it started, xlink was meant to be general links on the Web. If only for hyperlinks, that's confusing.
- 19:44:07 [Chris]
- depending on whose definitions of 'hyperlink' you use
- 19:44:21 [TBray]
- q+
- 19:44:23 [Ian]
- TBL: People's terminology varies (a source of confusion) and that becomes a TAG issue.
- 19:44:41 [Roy]
- q-
- 19:44:57 [DanCon]
- again, it seems there's plenty here to justify the time of the TAG to discuss this issue.
- 19:45:05 [Ian]
- ack Norm
- 19:45:29 [DaveO]
- q+
- 19:45:31 [Ian]
- NW: The xlink spec seems to have all the necessary machinery to provide roles for fully generalized linking. I thought that all links would be based on xlink.
- 19:45:44 [Ian]
- ack Timbl
- 19:46:09 [Ian]
- TBL: (Clarification) - what do you mean by a link? Does a reference to a piece of a BNF expression in a speech grammar be a link?
- 19:46:17 [Ian]
- NW: Yes - if you point from here to there, use an xlink.
- 19:46:23 [DanCon]
- order? would the chair please ask if anybody wants this to *not* be a TAG issue?
- 19:46:43 [Chris]
- qagree it should be a TAG issue
- 19:46:43 [Ian]
- TB: I propose we accept this as an issue - domain of application of xlink. Are parts mandatory?
- 19:47:23 [Ian]
- TB: Xlink represents a lot of work and agony. Would it help if TAG made recommendations? I think that's worth an issue.
- 19:47:38 [Ian]
- DO, PC: Objections to making this a TAG issue.
- 19:48:20 [Ian]
- DO: I observe that one of the fundamental issues that came up on xlink charter discussions was - when you start doing more general hyperlinking, you want to give the author a better understanding of processing model when link occurs.
- 19:48:49 [Stuart]
- Q?
- 19:48:56 [Ian]
- DO: I thought xlink was not meant to be used for all linking (e.g., some from database community not satisfied with that).
- 19:49:07 [Ian]
- q=
- 19:49:08 [Zakim]
- Ian, if you meant to query the queue, please say 'q?'; if you meant to replace the queue, please say 'queue= ...'
- 19:49:12 [Ian]
- queue=
- 19:49:27 [Ian]
- PC: +1 to DO's comments.
- 19:49:47 [timbl]
- q+
- 19:49:59 [DaveO]
- Q+ paulc
- 19:50:05 [Ian]
- TB: I'm uncomfortable with history determining (mechanically) whether we decide to accept arch issues.
- 19:50:21 [timbl]
- The XLINK spec IMHO is made for GUI links.
- 19:51:33 [ian_]
- ian_ has joined #tagmem
- 19:52:19 [ian_]
- The architecure is "You shall use URIs." not "You shall use xlink"
- 19:52:21 [ian_]
- If you try to use Xlinks for semantics, I'd find that RDF is more generic - I wouldn't force peopel to use RDF for human-readable documents.
- 19:52:21 [Roy]
- xlink covers all explicit links. There are also implicit links and externally-defined links that are not covered.
- 19:52:22 [Stuart]
- q?
- 19:52:29 [timbl]
- qck T
- 19:52:31 [DaveO]
- q- paulc
- 19:52:32 [timbl]
- ack t
- 19:52:33 [Roy]
- q+
- 19:52:45 [DanCon]
- I've had lots of discussions where, 2/3rds of the way thru, folks discovered they had different ideas about what "link" or "hyperlink" or "reference" meant. I think the TAG could save W3C WG's a lot of time by spending some time discussing this stuff.
- 19:52:54 [DanCon]
- [the chair did ask, and PaulC and DaveO said they want it *not* to be a TAG issue]
- 19:53:36 [DanCon]
- hmm... interesting policy question... do we need consensus to accept an issue? or just majority?
- 19:53:55 [DaveO]
- q+
- 19:54:19 [Chris]
- having it added as an Issue does have some politicaly overtones, yes
- 19:54:30 [ian_]
- IJ: For me, issues list is just a tool. What do people think are other implications of putting on the issues list?
- 19:54:45 [ian_]
- TBL: Right, useful to assign issue number to get work done. Even if we make a quick resolution.
- 19:54:49 [Roy]
- q- so that TimBL an describe process
- 19:54:56 [ian_]
- TBL: Nomenclature consensus is already valuable.
- 19:55:00 [Roy]
- q-
- 19:55:15 [TBray]
- BTW I think I agree with DaveO on the appropriate use of xlink
- 19:55:17 [Chris]
- of course, we could always issue a finding that "there is no problem". Issue does not equate to "clearly broken"
- 19:55:19 [ian_]
- TBL: Just pointing out what people meant by "hypertext links" is time well-spent.
- 19:55:22 [DaveO]
- q+ paulc
- 19:55:42 [DanCon]
- "# By a majority vote, the TAG must agree to consider an issue as having sufficient breadth and technical impact to warrant its consideration." -- http://www.w3.org/2001/07/19-tag
- 19:55:59 [DanCon]
- it's in our charter. We're done with this one. this is an issue.
- 19:56:07 [TBray]
- don't agree that issue ==> finding
- 19:56:12 [Norm]
- nor do i
- 19:56:19 [ian_]
- q+
- 19:56:25 [ian_]
- ack DaveO
- 19:56:44 [ian_]
- DO: I would drop my concern if we get clear view of what "issue mean".
- 19:57:02 [ian_]
- DC: Our charter says "Majority vote" to accept issues.
- 19:57:44 [DanCon]
- indeed, we don't owe a finding on every issue. we owe a decision that we're done with an issue. our decision could be "well, we don't care anymore."
- 19:57:50 [Roy]
- agreed
- 19:57:56 [ian_]
- IJ: Dispositions may vary.
- 19:58:11 [DaveO]
- we not using the queue?
- 19:58:14 [ian_]
- Resolved: Add two issues. PSVI, xlinkScope.
- 19:58:15 [DanCon]
- q?
- 19:58:43 [ian_]
- Issue names: augmentedInfoset and xlinkScope
- 19:58:45 [DanCon]
- ian_, paul, do you still wish to speak?
- 19:58:45 [ian_]
- Action IJ: Add to issues list.
- 19:58:48 [ian_]
- q-
- 19:58:57 [DanCon]
- queue=
- 19:59:00 [ian_]
- -----------------
- 19:59:10 [ian_]
- 1. "TAG Finding: Consistency of Formatting Property Names, Values, and Semantics"
- 19:59:14 [ian_]
- http://www.w3.org/2001/tag/doc/formatting-properties
- 19:59:18 [ian_]
- TB: I second publication.
- 19:59:31 [ian_]
- TB: Do we have information about why the CSS WG did this?
- 19:59:37 [ian_]
- #
- 19:59:37 [ian_]
- 1. ACTION NW 2002/05/20: Find out source of issue from CSS WG
- 19:59:53 [ian_]
- CL: Once Steve Zilles stopped prodding people, people stopped thinking about harmonization.
- 20:00:00 [ian_]
- CL: SVG WG going down that path, too.
- 20:00:15 [ian_]
- [Scribe considers action closed, then.]
- 20:00:19 [ian_]
- CL: I second publication.
- 20:00:29 [ian_]
- q?
- 20:00:32 [Roy]
- plus one on publication
- 20:00:44 [ian_]
- Action IJ: call for review on www-tag of NW's finding.
- 20:00:55 [DanCon]
- ack DanC
- 20:00:57 [ian_]
- ----------------------------------
- 20:01:04 [ian_]
- # QNames as Identifiers (qnameAsId-18)
- 20:01:04 [ian_]
- 1. Review draft finding from NW. ACTION NW 2002/06/10: Revise finding by adding examples.
- 20:01:15 [ian_]
- NW: I published updates just before call began. Action completed.
- 20:01:41 [ian_]
- Action IJ: Announce 1-week review on www-tag.
- 20:01:44 [ian_]
- TB: I promise to read it.
- 20:02:01 [DanCon]
- that action is to bray and williams, no?
- 20:02:27 [timbl]
- q+
- 20:02:48 [ian_]
- Change Action from IJ to NW: Announce one-week review of qnames and first review of finding on property names.
- 20:03:19 [ian_]
- TBL: I have the feeling that the finding on qnames is different from other findings. "There's this problem and it won't go away." [Without saying "It will go away if you do this.]
- 20:03:33 [ian_]
- TBL: It's useful to note that (a) this is a hole in the architecture and (b) we are not patching it over.
- 20:03:44 [ian_]
- DC: I think that the document already says that.
- 20:04:18 [ian_]
- TBL: The hole is that you can't tell when something is a qname.
- 20:04:46 [DanCon]
- Norm, that wouldn't fix it.
- 20:04:49 [DanCon]
- s/norm/no
- 20:04:59 [Norm]
- Norm, too :-)
- 20:05:42 [TBray]
- what TimBL is saying is "you could imagine a syntactic signal that would tell you when something was a qname"
- 20:05:47 [ian_]
- DC: Changing XML would not fix the hole. The primary use is in XPath. The only thing that would fix it is to never do microparsing in attribute values or other content.
- 20:05:52 [Norm]
- nothing short of a new markup character can fix this
- 20:06:15 [ian_]
- TB: Should status section say this?
- 20:06:21 [DanCon]
- "the table of contents"?
- 20:06:21 [ian_]
- TBL: What about TOC for "holes".
- 20:06:34 [ian_]
- IJ: I started to do this in the arch document - "Design weakness"
- 20:06:48 [ian_]
- ------------------------
- 20:06:57 [ian_]
- #
- 20:06:57 [ian_]
- 1.
- 20:06:57 [ian_]
- # Internet Media Type registration, consistency of use
- 20:06:57 [ian_]
- 1. ACTION DC: research the bug in the svg diagram. There are two votes to remove the diagram (DC and TB).
- 20:07:36 [ian_]
- DC: I researched the bug. The bug was smaller than expected. MD said lacked context, but not more serious bug.
- 20:07:46 [Chris]
- the diagram could of course be *revised* not removed. no isue witha correct fiagram, surely
- 20:07:56 [ian_]
- ...as it sits, the text around link to diagram doesn't set the right context. Nobody but TBL said they would miss the diagram.
- 20:08:18 [ian_]
- TB: So (a) nuke diagram or (b) change text to fix context.
- 20:08:28 [ian_]
- DC: I18N folks would like it anyway.
- 20:08:46 [TBray]
- touch&eacu;
- 20:08:59 [Norm]
- eacu? who defines that one?
- 20:09:03 [DanCon]
- I propose: (a) cut the diagram out of our finding, (b) I notify the I18N WG that timbl has this nifty diagram they might want to use.
- 20:09:27 [ian_]
- Editorial suggestion from Graham Klyne:
- 20:09:28 [Chris]
- touché
- 20:09:31 [ian_]
- http://lists.w3.org/Archives/Public/www-tag/2002Jun/0084
- 20:09:40 [ian_]
- "3C Working Groups engaged in defining a language SHOULD arrange for the
- 20:09:40 [ian_]
- registration of an Internet Media Type (defined in RFC 2046 [RFC2046])
- 20:09:40 [ian_]
- for that language. An initial publication of the appropriate MIME type
- 20:09:40 [ian_]
- registration template SHOULD be available as part of the specification
- 20:09:40 [ian_]
- starting at Candidate Recommendation."
- 20:09:58 [ian_]
- TB: People are worried that requiring IETF stuff will create bureaucratic delays.
- 20:11:10 [TBray]
- touché
- 20:11:31 [Chris]
- We are not requiring them to wait until its published as an RFC, just to submit the registration, yes?
- 20:11:35 [Chris]
- q+
- 20:11:37 [Roy]
- That's my experience as well with IETF WG specs.
- 20:11:38 [DaveO]
- q+ paulc
- 20:11:39 [ian_]
- TBL: Our experience with speech grammars makes me more adamant that the full info required to register mime type should be appendix to spec. That gets more attention.
- 20:12:00 [ian_]
- TBL: You have to not only show us the language, but exactly what you understand from the fact that you get the mime type.
- 20:12:22 [DanCon]
- ack timbl
- 20:12:23 [DanCon]
- ack chris
- 20:12:25 [ian_]
- TBL: There are all kinds of last-minute tweaks in mime type application since no review of it.
- 20:12:31 [TBray]
- chris: woof woof
- 20:12:48 [DaveO]
- I thought it was stuart's dog: woof woof?
- 20:13:11 [ian_]
- CL: I think that there's a circular dependency here (use mime types, get implementation experience (which requires a mime type...))).
- 20:13:36 [Zakim]
- -DOrchard
- 20:13:40 [ian_]
- TB: I think the issue is real - circular dependency.
- 20:13:53 [Zakim]
- +DOrchard
- 20:14:04 [DaveO]
- q?
- 20:14:29 [ian_]
- CL: I am in favor of proposal to include an appendix that has the mime registration (developed in parallel with the spec).
- 20:15:43 [ian_]
- PC: If a WG wishes to skip CR, mime type registration necessary earlier. Why is direct inclusion necessary, however?
- 20:16:02 [ian_]
- PC: Why not link normatively to another document?
- 20:16:32 [ian_]
- TBL: Because the registration process is not a standards process. A Recommendation should not rely on something if it doesn't have a similar level of review.
- 20:17:09 [Roy]
- q=
- 20:17:10 [DanCon]
- may I answer/
- 20:17:10 [Zakim]
- Roy, if you meant to query the queue, please say 'q?'; if you meant to replace the queue, please say 'queue= ...'
- 20:17:15 [ian_]
- PC: How do we engage the existing IETF process to define the mime type? Do we send them the entire spec?
- 20:17:22 [Roy]
- q?
- 20:17:38 [ian_]
- DC: Copy materials relevant to registration from spec (appendix) into an internet draft.
- 20:17:50 [ian_]
- PC: But there's risk of getting out of sync. What to do in that case?
- 20:18:15 [ian_]
- TBL: They can't get out of sync. Every time you change you change the rec track doc, you change the Internet draft. And we don't allow internet draft to change unless w3c spec has changed.
- 20:18:17 [ian_]
- ack Paulc
- 20:18:39 [ian_]
- SW: The internet draft doesn't stay one forever, it becomes an RFC at some point.
- 20:18:46 [ian_]
- RF: Depends on whether informational rfc, or just a form,...
- 20:19:20 [ian_]
- RF: The confusion on the mailing list is whether there is some ordering involved. There isn't. There is a separate process in IETF land, where there is cut and paste from w3c spec->IETF land.
- 20:19:23 [DanCon]
- hmm... actually, roy makes a good point; the internet draft needn't become an RFC; it can just be pasted into the IANA registry, with a pointer to the W3C spec.
- 20:20:03 [ian_]
- PC: If this decision is in place, the XMLP WG will have to pull a mime type registrationinto one of its normative specs.
- 20:20:16 [DanCon]
- [several]: yes, paul.
- 20:20:18 [ian_]
- TBL: Yes, the primary spec referenced by the registration.
- 20:20:39 [ian_]
- q+
- 20:20:40 [Roy]
- i.e., the media frmat definition spec should contain the media type definition forms.
- 20:20:43 [ian_]
- ack Roy
- 20:20:53 [timbl]
- XMLProtocol is about to push XMLP to last call. The spec referenced by the registration document should include the registration document as a part.
- 20:21:33 [Chris]
- Given that we issued a finding that said it should be added 'at CR" and now changed irt to "a t last call" then clearly there should be a grace period for specs already in, or immeduiately about to enter, last call
- 20:22:30 [ian_]
- DC: Since PC wants to go from last call to PR, media type should be included directly in last call document.
- 20:22:44 [ian_]
- PC: The registration has been done.
- 20:23:30 [ian_]
- Action PC: Convey the desire of the TAG that registration be included in soap spec before going to last call.
- 20:23:50 [ian_]
- TBL: If there's some reason why the WG doesn't want that information in the spec, I'd want to know why.
- 20:23:58 [ian_]
- TB: I think grace period reasonable but prefer inclusion.
- 20:24:24 [Chris]
- yes we are standing by our finding
- 20:24:37 [ian_]
- Reagle:
- 20:24:42 [ian_]
- As I've noted earlier this could introduce a source of delay and confusion
- 20:24:42 [ian_]
- in the advancement of W3C specifications. Unless the TAG has determined
- 20:24:42 [ian_]
- that the IESG/IANA finds a section of a W3C specification to be an adequate
- 20:24:42 [ian_]
- registration request this means we'll have one version in a W3C
- 20:24:42 [ian_]
- specification, and one version published as an ietf-draft and subsequent
- 20:24:43 [ian_]
- Informational RFC contingent about IESG timing and discretion. (I noted it
- 20:24:45 [ian_]
- took ~6 months to publish the xmldsig requirements Informational RFC). The
- 20:24:47 [ian_]
- W3C will not be able to publish the CR until the IETF publishes the
- 20:24:48 [Roy]
- I read it and am standing by finding. Already rebutted.
- 20:24:50 [ian_]
- Informational RFC I presume? Which is unfortunate as implementation and
- 20:24:51 [ian_]
- operational experience might inform the media type registration, requiring
- 20:24:53 [ian_]
- a new Informational RFC.
- 20:24:55 [ian_]
- Consequently, I disagree with this finding and prefer that the media type
- 20:24:57 [ian_]
- registration proceed as specified in RFC2048; a W3C specification SHOULD
- 20:24:57 [TBray]
- http://lists.w3.org/Archives/Public/www-tag/2002Jun/0073
- 20:24:59 [ian_]
- reference the IETF document.
- 20:25:01 [ian_]
- http://lists.w3.org/Archives/Public/www-tag/2002Jun/0073
- 20:26:23 [ian_]
- RF: The main process is that there exists a spec somewhere that includes the correct forms. They can either be part of an Internet RFC....depends on type of media type being defined....if global, there has to be an Internet RFC saying where the format is defined.
- 20:26:26 [DaveO]
- As we are not going to get item #4 in the action items (the arch document), I object to publishing the arch document. There are some serious errors and omissions in the document. I will send my comments asap.
- 20:26:40 [ian_]
- RF: It doesn't matter if IETF docs go out of date.
- 20:26:57 [DanCon]
- I think I understand reagle's objection well enough to clarify; though I'd rather Roy did it. ;-)
- 20:27:12 [ian_]
- RF: You stil have to submit the original form.
- 20:27:12 [DaveO]
- sorry, I meant item #4 in the "findings section of the agenda".
- 20:27:46 [ian_]
- DC: Some entries in registry point to specs, not informational RFCs.
- 20:27:54 [ian_]
- RF: That's the old process. There's another one in place.
- 20:28:06 [ian_]
- RF: I already replied to Reagle.
- 20:29:50 [ian_]
- Action IJ/PC: Update finding to include text about last call if no CR.
- 20:29:53 [TBray]
- meta-issue: we MUST put some time into arch doc next week
- 20:30:30 [DanCon]
- I note the "this has no status" is after a page of very official-looking W3C logos and such.
- 20:30:34 [DaveO]
- Here is the SOAP 1.2 application/soap+xml RFC http://www.ietf.org/internet-drafts/draft-baker-soap-media-reg-00.txt
- 20:31:07 [DanCon]
- also, pls scribble out "7 June 2002" when you edit after 7jun.
- 20:31:28 [DanCon]
- ian_: chapter 1 edited ("economics of names")
- 20:31:46 [DanCon]
- ... I'm looking into diagrams
- 20:32:22 [ian_]
- TB: Please put this at front of agenda next week.
- 20:32:27 [DanCon]
- the "new issues" item should probably go at the bottom of the standing agenda.
- 20:32:39 [ian_]
- DO: Is this higher or lower priority than update on WSA WG on finding?
- 20:32:46 [DaveO]
- I take it that TAG members want this text folded into the SOAP 1.2 Part 1 spec: latest draft at http://www.w3.org/2000/xp/Group/2/06/06/soap12-part1.html
- 20:32:52 [Zakim]
- -Norm
- 20:32:53 [Zakim]
- -TimBL
- 20:32:54 [DanCon]
- norm is excused.
- 20:33:03 [TBray]
- gotta go too, bye
- 20:33:08 [Zakim]
- -Tim.Bray
- 20:34:08 [ian_]
- Adjourned
- 20:34:12 [ian_]
- RRSAgent, stop