W3C home > Mailing lists > Public > www-tag@w3.org > April 2003

RE: [Minutes] 7 Apr 2003 TAG teleconf (arch doc, contentTypeOverride-24, namespaceDocument-8, IRIEverywhere-27)

From: Paul Cotton <pcotton@microsoft.com>
Date: Tue, 8 Apr 2003 19:49:04 -0400
Message-ID: <E7AC4500EAB7A442ABA7521D1881439706324A08@tor-msg-01.northamerica.corp.microsoft.com>
To: "Ian B. Jacobs" <ij@w3.org>, <www-tag@w3.org>

>[Chris] 
>who wil be there - ian, paul, chris, timbl

This may be what Chris said but I believe it is possible that other TAG
members may also be at the conference.

Paul Cotton, Microsoft Canada 
17 Eleanor Drive, Nepean, Ontario K2E 6A3 
Tel: (613) 225-5445 Fax: (425) 936-7329 
mailto:pcotton@microsoft.com

  

> -----Original Message-----
> From: Ian B. Jacobs [mailto:ij@w3.org]
> Sent: April 7, 2003 6:42 PM
> To: www-tag@w3.org
> Subject: [Minutes] 7 Apr 2003 TAG teleconf (arch doc,
contentTypeOverride-
> 24, namespaceDocument-8, IRIEverywhere-27)
> 
> 
> 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 Tuesday, 8 April 2003 19:49:40 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:47:17 GMT