- From: Ian B. Jacobs <ij@w3.org>
- Date: 07 Apr 2003 18:41:59 -0400
- To: www-tag@w3.org
Hello,
The minutes of the 7 Apr 2003 TAG teleconf are
available as HTML [1] and as text below.
- Ian
[1] http://www.w3.org/2003/04/07-tag-summary.html
====================================================
Minutes of 7 Apr 2003 TAG teleconference
Nearby: [4]IRC log | [5]Teleconference details · [6]issues list ·
[7]www-tag archive
[4] http://www.w3.org/2003/04/07-tagmem-irc.html
[5] http://www.w3.org/2001/tag/group/#remote
[6] http://www.w3.org/2001/tag/ilist
[7] http://lists.w3.org/Archives/Public/www-tag/
1. Administrative
1. Roll call: NW (Chair), TBL, PC, DO, TB, CL, RF, IJ (Scribe):
Regrets: SW. Missing: DC.
2. Accepted [8]31 Mar telecon minutes
3. Accepted this [9]agenda
4. Accepted [10]summary of TAG activity with two suggestions:
1. PC reminder about report to AC in May
2. CL suggested wording for progress on issues
3. Action IJ: Send out summary with these changes.
5. Next meeting: 14 April. No regrets signaled.
[8] http://www.w3.org/2003/03/31-tag-summary.html
[9] http://www.w3.org/2003/04/07-tag.html
[10] http://lists.w3.org/Archives/Member/tag/2003Apr/0007.html
1.1 Meeting planning
* The TAG will strive to organize a virtual meeting shortly after
the WWW Conference. See [11]thoughts from SW on organizing a
virtual meeting.
Completed action TBL 2003/03/31: Propose June dates (after 4
June). (See [12]questionnaire)
The TAG will try to finalize the date next week after remaining
TAG participants have completed questionnaire.
* Upcoming discussions:
+ The TAG expects to discuss its presentation to the AC on 14
and 21 April.
+ Action IJ: Report to mtg organizer TBL constraint on slot for
TAG report, then report back to TAG on revised slot.
[11] http://lists.w3.org/Archives/Member/tag/2003Mar/0082.html
[12] http://www.w3.org/2002/09/wbs/34270/05%252F06.03/
1.2 W3C Track Presentation
* [13]W3C track [30]: "TAG scope"
* [14]Notes from Paul Cotton
[13] http://www2003.org/t_www.htm
[30] http://www.textuality.com/xml/rddl3.html
[14] http://lists.w3.org/Archives/Member/tag/2003Apr/0010.html
[Chris]
'what is the tag and why should you care" fits in 30 minutes
[Chris]
when is the www slot, actually?
[Ian]
PC suggestion:
1. scope and role of the TAG
2. sample findings issued by the TAG and their results
3. overview of the Web Architecture document
[Chris]
who wil be there - ian, paul, chris, timbl
[Ian]
NW: Please reply on email to PC's proposal
Next week: TAG will finalize who will give which piece of the
track presentation on 14 April.
2. Technical
1. [15]Architecture document
2. [16]contentTypeOverride-24
3. [17]namespaceDocument-8
4. [18]IRIEverywhere-27
2.1 Architecture document
See also: [19]findings.
1. [20]26 Mar 2003 Working Draft of Arch Doc:
1. Action DC 2003/02/06: Attempt a redrafting of 1st para under
[21]2.2.4 of 6 Feb 2003 draft
2. Action DC 2003/01/27: write two pages on correct and
incorrect application of REST to an actual web page design
3. Action DO 2003/01/27: Please send writings regarding Web
services to tag@w3.org. DO grants DC license to cut and paste
and put into DC writing.
4. Completed action CL 2003/0127: Draft language for arch doc
that takes language from internet media type registration,
propose for arch doc, include sentiment of TB's second
sentence from CP10. ([22]Done)
CL: Belongs in section 4.2 of Architecture Document.
5. Action DC 2003/03/17: : Write some text for interactions
chapter of arch doc related to [23]message passing, a dual of
shared state.
[19] http://www.w3.org/2001/tag/findings
[20] http://www.w3.org/TR/2003/WD-webarch-20030326/
[21] http://www.w3.org/2001/tag/2002/webarch-20030206#uri-use
[22] http://lists.w3.org/Archives/Public/www-tag/2003Apr/0034.html
[23] http://lists.w3.org/Archives/Public/www-tag/2003Mar/0018.html
[Ian]
Done.
IJ: Who is reading the arch doc?
[Ian]
NW: I am getting closer to reading it.
[Chris]
I have been reading it this week, yes
[Ian]
TBL also reading arch doc.
2.2 contentTypeOverride-24
* [24]contentTypeOverride-24
+ See [25]email from DC to Voice Browser WG.
+ Completed action IJ 2003/03/24: Draft up some language; make
connection to error-handling issue. TAG position with
rationale why to not override server value of content type.
([26]Done)
[24] http://www.w3.org/2001/tag/open-summary.html#contentTypeOverride-24
[25] http://lists.w3.org/Archives/Public/www-tag/2003Feb/0085.html
[26] http://www.w3.org/2001/tag/doc/mime-respect-20030405.html
[Ian]
IJ: I completed the action item, but haven't made the [27]draft
public. I intend to publish this in a week; please review.
CL: Some of the material was in an earlier finding. Please link
back to [28]Internet Media Type registration, consistency of
use
IJ: Yes, I agree. I'll put publication of this on agenda for
next week
[27] http://www.w3.org/2001/tag/doc/mime-respect-20030405.html
[28] http://www.w3.org/2001/tag/2002/0129-mime
2.3 namespaceDocument-8
* [29]namespaceDocument-8
+ Next steps on [30]RDDL Proposal from [31]Tim Bray/Paul Cotton
[29] http://www.w3.org/2001/tag/open-summary.html#namespaceDocument-8
[30] http://www.textuality.com/xml/rddl3.html
[31] http://lists.w3.org/Archives/Public/www-tag/2003Feb/0213
[Ian]
TB: I have an action to fix this up to ensure that it's valid,
modularized xhtml. Two substantive issues before the TAG:
1. Do we support this version of RDDL on a technical basis?
2. How do we move it forward?
TBL: I think that the TAG is not set up to be a WG at this
time; Rec track docs would be quite a drain on resources at
this time. If this were a draft, I think at this time it would
be better to fork off another WG.
[paulc]
Please see
[32]http://lists.w3.org/Archives/Member/tag/2003Apr/0012.html
for my view.
[32] http://lists.w3.org/Archives/Member/tag/2003Apr/0012.html
[Ian]
TBL: Another possibility is to say "we don't think this is
contentious, we don't have time to get review, we'll publish as
a Note.": Then, if picked up, then can put on Rec track. Or if
not used because of problems, move to a WG for more work.
PC: On this front, I think the TAG should "ask permission" and
not "ask forgiveness". Therefore I would like to propose the
following:
1. we publish our proposal for namespacedocument-8 [$1\47] as a
Note ASAP
2. we specifically request input for the AC membership at the
May AC on how the content of this Note if and should be
progressed to Recommendation track.
PC: We should negotiate this precedent with the AC. With simple
change by TB, we could publish as Note quickly and get ac
feedback.
TB: I think I agree with TBL and PC; don't want to be sloppy to
respond formally to public input. What about publishing this as
a finding? I could also see publishing as a Note.
[Zakim]
Chris, you wanted to talk about life after rec, testsuites, and
other resource suckers
[Ian]
CL: Lots of responsibilities for Rec track work (e.g., test
suites, life after Rec, etc.) I support publication as a
finding.
NW: I agree with PC (publication as a Note)
[Chris]
we could still ask the AC if the finding should go on the rec
track and if so who should do it would work
[Ian]
NW: I think that findings have more stature; people used to
seeing docs from TAG at this point. People are more used to
seeing spec-like things as Notes.
IJ: Note more spec-like; TR page as location for document
likely to get more attention.: I lean slightly towards Note
publicatoin.
[Zakim]
timbl_, you wanted to ask about links from
[33]http://www.textuality.com/xml/rddl3.html
[33] http://www.textuality.com/xml/rddl3.html
[Ian]
Action TB: (1) Clean up messy section 4 of RDDL draft and (2)
Investigate and publish a canonical mapping to RDF.
Summarizing: TAG doesn't think that Rec track best option for
now (at least without consulting the AC).
TBL: I think finding is inappropriate; people expect a certain
genre of thing in a finding. This is Note-like. We could
publish a finding explaining why the Note is good....
TB: Can you have a Note that says "This represents the
consensus of...."
IJ: Yes.
[TBray]
What Norm said
[Chris]
finding can be short, but should still exist
[Ian]
Proposed: Plan is to publish TB's revised RDDL document as a
W3C Note. Status section would say that it represents the
consensus of the TAG.
CL: The finding would say why the solution is desirable.
IJ: I think that rationale would be better in the document.
[paulc]
Where do we say that users of namespaces SHOULD use the
suggested format.
[Ian]
CL: I'd like each issue to close with a finding.
[Chris]
its a consistency thing
[Ian]
TB: Current language in Note does not say "namespaces SHOULD
use the suggested format." I would be fine to say that, but
don't think it needs it.
[TBray]
Current doc says "A Resource Directory is designed to be
suitable for service as the body of an entity returned by
dereferencing a URI serving as an XML Namespace name."
[Ian]
TBL: I hear PC saying put language spec in a Note, put
recommendations on usage in a finding. I feel that we can put
the RDDL Note forward, but I agree where there will be
applications where people will use XML or RDF schema. I don't
want to force people to use it.
NW: I agree with CL to use finding to answer finding, publish
spec in Note.
[TBray]
OK, I can go with the the 2-doc solution
[Ian]
IJ: I can go with the 2-doc solution.
Proposal: TAG expects to publish RDDL Spec as a Note (status
section to indicate consensus of TAG), and to produce a finding
to answer question of namespaceDocument-8, namely that groups
SHOULD use RDDL.
TBL: I think we should say that RDDL is a good example (don't
say "SHOULD" in finding; just indicate RDDL as a good example).
[DaveO]
I think we should say that RDDL should be used.
[Ian]
Proposal: TAG expects to publish RDDL Spec as a Note (status
section to indicate consensus of TAG), and to produce a finding
to answer question of namespaceDocument-8.
[timbl_]
ok by me
[Ian]
TB: I'm optimistic that in the finding we'll find consensus on
verbiage.
[timbl_]
I don't want to recommend RDDL any more than we recommend XML,
RDF or SVG
[Ian]
Proposal: TAG expects to publish RDDL Spec as a Note (status
section to indicate consensus of TAG that this is a suitable
representation of a resource), and to produce a finding to
answer question of namespaceDocument-8 (with some sort of
pointer to the RDDL spec).
Proposal: TAG expects to publish RDDL Spec as a Note (status
section to indicate consensus of TAG that RDDL is a suitable
format for representations of an XML namespace), and to produce
a finding to answer question of namespaceDocument-8 (with some
sort of pointer to the RDDL spec).
Resolved: TAG expects to publish RDDL Spec as a Note (status
section to indicate consensus of TAG that RDDL is a suitable
format for representations of an XML namespace), and to produce
a finding to answer question of namespaceDocument-8 (with some
sort of pointer to the RDDL spec).
Action TB: Work on RDDL Note.
Action PC: Work on TAG finding.
2.4 IRIEverywhere-27
* [34]IRIEverywhere-27
+ Action CL 2003/03/31: Revised position statement on use of
IRIs. See [35]email from CL on next steps.
[34] http://www.w3.org/2001/tag/open-summary.html#IRIEverywhere-27
[35] http://lists.w3.org/Archives/Public/www-tag/2003Apr/0033.html
[DaveO]
I have to step away for a few minutes.
[Ian]
CL: I'd like more discussion this week; deadline 21 April? Also
need to convey to Martin the desirability of seeing
[36]http://www.w3.org/International/iri-edit/ updated to
include iDNS and published as draft 4, and to move to RFC soon.
I'd like to address question of 'blessed wording' regarding IRI
that three XML-related specs can use to get to Proposed Rec.
[36] http://www.w3.org/International/iri-edit/
[TBray]
Kanji example in
[37]http://www.tbray.org/ongoing/When/200x/2003/03/31/IRI
[37] http://www.tbray.org/ongoing/When/200x/2003/03/31/IRI
[Ian]
TBL: I think there is a fundamental question that has not been
resolved, and is causing a lot of tension.: Whether,
fundamentally, the fundamental string is the URI, or whether we
are dispensing with URIs in favor of Unicode strings instead.
[Chris]
position A says IRI is a way of talking about URI
position B says IRI is the real thing and URI is a subset that
should go away
[Ian]
TBL: I was under the impression during development of IRIs,
that the model was position A. I think the TAG needs to adress
this bifurcation (A v. B)
TB: I agree with the TBL and CL characterization of the heart
of the issue.
[Chris]
and please lets get to blessed text after we have discussed
this
[Ian]
TB: "Is any URI an IRI?" I think the answer is No; lots of
sloppiness about hexifying.
[Chris]
strongly disagree with TimBray
[Ian]
TB: I think IRIs need to be rigid and deterministic about when
hexifying is used, and that the mapping (to URI) process be
well-characterized.
CL: I don't think it's true that all URIs are IRIs.
[Some discussion of equivalence measures around hexifying]
CL: It does not follow that the URI version of an IRI is the
same as that IRI. It does not follow that the URI version of an
IRI is the same as that IRI in all cases: same when you
dereference; not the same in e.g., namespace comparisons.
NW: Why inappropriate to convert to URI before comparison?
CL: A number of specs don't do it that way; they do simple
string matching in a number of specs. Therefore, not reasonable
in practice to require conversion to URI. E.g., you have to
have a kanji character and upper case hex and lower case hex to
be the same.
[TBray]
We really need to do this in a room with a whiteboard
[Ian]
CL: Too much water to push uphill (especially when extra
processing doesn't get you much).
[Zakim]
timbl_, you wanted to argue that theis is relatively little
water to push up hill
[Ian]
TBL: I've been there too.... I was convinced of CL's argument,
but upon further reflection believe it's untenable.: Suppose
that identifiers are unicode strings and you don't have to
canonicalize them to compare them. There is ten years of
software using 7-bit fields for this quantity.
[paulc]
I need to step out for 3-4 min.
[Ian]
TBL: If suddenly you allow namespaces that can differ in 7-bit
systems but not in 8-bit systems. Changing the XML spec is
relatively easy. You have a transition strategy: ask them to
canonicalize namespace IDs and xpaths. During the interim, the
only time things actually fail is when people use things that
only differ in case of hex encoding. So this is a corner case.
Easier to move to full canonicalization and full equality and
to be consistent with 10 years of code and fix latest
departures.
CL: I strongly disagree.
TB: I'm not sure that CL and I disagree that much. In terms of
URIs, it's a fact that everyone uses string comp in namespace
applications. We have ample evidence that this is prone and
shakey to failure, but people do it anyway.
[Chris]
everyone uses string comparison in namespace comparisons, and
in xpath. and in xml query. and ....
[Ian]
TB: One reason has to do with hex-encoding. We can remove that
sloppiness in the IRI spec; but we'd have to abandon the
insistence that every URI is an IRI.
TBL: I hear TB proposing that IRIs are always canonical.
[Zakim]
Chris, you wanted to point out that I really, really want to
talk about blessed text in the next 20 minutes
[paulc]
I'm back.
[Ian]
TBL: Are you saying, CL, that browsers that use hex encoding
are wrong?
CL: Yes, they are doing it too early. They should do when they
send over HTTP transport.
TBL: If you are telling me that the encoded and unencoded forms
are equivalent....
CL: Yes.
RF: When a robot takes advantage of some heuristic, this is not
for the purpose of determining equivalence of the identifier;
it's equivalence of an operation.
TBL: Each algorithm in the deployed software, though, is using
a different piece of the URI spec for its heuristics.
RF: There is a reason to create an equivalence relationship
between IRIs and URIs. That there are other mechanisms that
don't respect that equivalence is irrelevant. I agree with TBL.
NW: I think that TB is right - the key to make this all fit
together is to say "Not all URIs are IRIs, and you define
mappings that are reversible"
[Chris]
deprecated subset of URIs
[Ian]
[On text about IRIs in specs at this point]
CL: Should we be in the business of producing parts of specs
that have guarantees associated with them, or not.: Or do we
say "Here's our best guess, do the best you can to prepare
something for the Director."
[Zakim]
timbl_, you wanted to say we should respond and we should not
suggest the result has papal infallibility.
[Ian]
TBL: If we are talking about this, we owe people a response,
but without any guarantees.
[Chris]
agree about the papal infallibility
[Ian]
TB: see language in xml 1.1...hmmm, doesn't say much.
CL: There is language in schema spec as well. People could
point to that (It's a Rec)
TB: I think the anyURI type is underspecified. Last time I
looked, there were very few syntactic restrictions on what you
can put in an anyURI. I don't think that that's a good
solution.
TBL: How about if we tell people to refer to the IRI draft.
Then we explain to people what that means: When you refer to
the IRI spec, you take on that %7e and %7E are the same.
[Chris]
this is the option A, push water uphill argument
[Ian]
TBL: That gets the XML specs off the hook. We need to explain
that, the syntax and semantics are defined by URI specs.
NW: Core WG wants to say that these things are IRIs, not URIs.
[Chris]
Core WG wants to say these things are IRIs
[Ian]
TB: I think that it's clear that we probably can't solve their
problem for them.: IRI, though the right answer, isn't done.
TBL: Propose that specs continue to be well-defined in terms of
URIs, and only as well-defined as the IRI spec currently is.
URI conformance + xml namespace conformance will give you this
flexibility.
NW: A lot of existing software will no longer be conformant.
CL: XML Namespace software will break.
RF: But IRIs won't look in the future like they look today.
IRIs will change to support IDNA.
NW: If you do what TBL just said, then you have to use URI
comparison and not string comparison.
RF: Then use the field, define in the other specs as CDATA, and
forget about it.
[Ian]
CL: I have an action to write this up.
[Chris]
I cannot complete writing this up
all proposed solutions have vehement objections
[Ian]
NW: IJ: please move the question of text that WGs may include
in specifications up on the agenda next week.
No resolution.
2.5 Other issues that have associated action items
* [38]URIEquivalence-15
+ SW proposal: Track RFC2396bis where [39]Tim Bray text has
been integrated. Comment within the IETF process. Move this
issue to pending state?
* [40]xmlIDSemantics-32
+ See [41]Chris Lilley draft finding
* [42]abstractComponentRefs-37
* [43]xlinkScope-23
+ Status report?
+ See [44]draft, and [45]SW message to CG chairs.
* [46]siteData-36
+ Action TBL 2003/02/24 : Summarize siteData-36
* [47]xmlFunctions-34
+ Action TBL 2003/02/06: State the issue with a reference to
XML Core work. See [48]email from TimBL capturing some of the
issues.
* [49]binaryXML-30
+ Action TB 2003/02/17: Write to www-tag with his thoughts on
adding to survey.
+ Next steps to finding? See [50]summary from Chris.
* [51]contentPresentation-26
+ Action CL 2003/02/06: Create a draft finding in this space.
Deadline 3 March.
* [52]rdfmsQnameUriMapping-6
+ Action DC 2003/02/06: Propose TAG response to XML Schema
desideratum ([53]RQ-23).
* [54]uriMediaType-9
+ Action DC 2003/02/06: Start discussion on
discuss@apps.ietf.org, but not urgent
* [55]HTTPSubstrate-16
+ Action RF 2003/02/06: Write a response to IESG asking whether
the Web services example in the SOAP 1.2 primer is intended
to be excluded from RFC 3205
+ See [56]message from Larry Masinter w.r.t. Web services.
* [57]errorHandling-20
+ Action CL 2003/02/06: Write a draft finding on the topic of
(1) early/late detection of errors (2) late/early binding (3)
robustness (4) definition of errors (5) recovery once error
has been signaled. Deadline first week of March.
* [58]metadataInURI-31
+ Action SW 2003/02/06: Draft finding for this one.
* [59]fragmentInXML-28 : Use of fragment identifiers in XML.
1. Connection to content negotiation?
2. Connection to opacity of URIs?
3. No actions associated / no owner.
[38] http://www.w3.org/2001/tag/open-summary.html#URIEquivalence-15
[39] http://www.textuality.com/tag/uri-comp-4
[40] http://www.w3.org/2001/tag/ilist#xmlIDSemantics-32
[41] http://www.w3.org/2001/tag/doc/xmlIDSemantics-32.html
[42] http://www.w3.org/2003/04/24-tag-summary.html#abstractComponentRefs-37
[43] http://www.w3.org/2001/tag/ilist.html#xlinkScope-23
[44] http://lists.w3.org/Archives/Member/tag/2003Mar/0094.html
[45] http://lists.w3.org/Archives/Member/tag/2003Mar/0104
[46] http://www.w3.org/2001/tag/ilist.html#siteData-36
[47] http://www.w3.org/2001/tag/ilist#xmlFunctions-34
[48] http://lists.w3.org/Archives/Public/www-tag/2003Feb/0309.html
[49] http://www.w3.org/2001/tag/open-summary.html#binaryXML-30
[50] http://lists.w3.org/Archives/Public/www-tag/2003Feb/0224.html
[51] http://www.w3.org/2001/tag/open-summary.html#contentPresentation-26
[52] http://www.w3.org/2001/tag/open-summary.html#rdfmsQnameUriMapping-6
[53] http://www.w3.org/TR/2003/WD-xmlschema-11-req-20030121/#N400183
[54] http://www.w3.org/2001/tag/open-summary.html#uriMediaType-9
[55] http://www.w3.org/2001/tag/open-summary.html#HTTPSubstrate-16
[56] http://lists.w3.org/Archives/Public/www-tag/2003Feb/0208.html
[57] http://www.w3.org/2001/tag/open-summary.html#errorHandling-20
[58] http://www.w3.org/2001/tag/open-summary.html#metadataInURI-31
[59] http://www.w3.org/2001/tag/ilist#fragmentInXML-28
3. Other actions
* Action IJ 2003/02/06: Modify issues list to show that
actions/pending are orthogonal to decisions. IJ is working with
PLH on this. Revisit this end of April.
_________________________________________________________________
Ian Jacobs for Norm Walsh and TimBL
Last modified: $Date: 2003/04/07 22:36:12 $
--
Ian Jacobs (ij@w3.org) http://www.w3.org/People/Jacobs
Tel: +1 718 260-9447
Received on Monday, 7 April 2003 18:42:39 UTC