- From: Ian B. Jacobs <ij@w3.org>
- Date: 10 Jun 2003 11:28:48 -0400
- To: www-tag@w3.org
Hello,
The minutes of the TAG's 9 Jun 2003 (2.5 hour) teleconf
are available as HTML [1] and as text below.
- Ian
[1] http://www.w3.org/2003/06/09-tag-summary.html
====================================================
Minutes of 9 June 2003 TAG teleconference
1. Administrative
1. Roll. All present: SW (Chair), TBL, DC, TB, DO, RF, CL, PC, NW, IJ
(Scribe)
2. Accepted minutes of [8]12 May teleconf and [9]2 Jun teleconference
3. Accepted this [10]agenda, with addition of item on W3C/IETF
meeting
4. Next meeting: 16 June. Regrets: PC
[8] http://www.w3.org/2003/05/12-tag-summary.html
[9] http://www.w3.org/2003/06/02-tag-summary.html
[10] http://www.w3.org/2003/06/09-tag.html
1.2 W3C/IETF meeting
[Ian]
DC: IETF/W3C teleconf is 17 June. Might talk about mime types.
Do you want anything on that agenda?
TB: We wanted them to provide web space and canonical URIs for
mime types.
[TBray]
where's that IANA/IETF mime-type directory?
[Ian]
DC: Maintaining "tidy uris" - promise to keep http URIs to mime
types and to give 1 year notice if they will change. Another
issue is I18N URIs.
[Zakim]
Chris, you wanted to ask abou IDNA and process stuff and to
also ask about URI mime registry and correct forum
[Ian]
CL: Is talking to Ned Freed the correct forum for pushing for
tidy URIs?
[CL has an action item]
DC: Norm in IETF is to address author. In general, ok to cc
public w3c/ietf mailing list
CL clarifying: Is our action the same?
TB: As I recall, DC had sent us a place in IETF land where all
the mime types were on one page. However, as I recall, it was
only really halfway there.
Example:
[11]http://www.iana.org/assignments/media-types/image/cgm
TB: I think CL had accurately described the pbs in his
[12]email:
Message-ID: <10684031578.20030228173630@w3.org>
To: webmaster@iana.org, CC: www-tag@w3.org,
ned.freed@mrochek.com
DC: Ned is editing the policy that says they have to do it
right. Make it policy through Ned Freed.
CL: I'll forward to w3c/ietf liaison list:
public-ietf-w3c@w3.org
[11] http://www.iana.org/assignments/media-types/image/cgm
[12] http://lists.w3.org/Archives/Public/www-tag/2003Feb/0302.html
[DanC]
if you mail me about IETF/W3C business, pls copy
public-ietf-w3c@w3.org
[Ian]
DC: Please read NF's policy document.
CL: I have read that.
DC: I pinged him to make a new draft; hoping he'll have one by
17 June
CL: What about i18n domain names?
RF: I18N domain names are done: IDNA is done; see [13]RFC 3490
(Internationalizing Domain Names in Applications (IDNA)) and
3491. Both Standards Track.
SW: What about talking about URLs/URNs at 17 June mtg?
DC: No urgency for 17 June meeting
[13] http://www.ietf.org/rfc/rfc3490.txt
[TBray]
URL = Universal Republic of Love
[Chris]
URI=URL+URC+URN
URN=not liked, URC=not implemented, thus URI== URL
qed
[TBray]
neat trick since URL and URC don't exist...
[Chris]
oh, *minor* issue of detail ;-)
[DanC]
hmm... the xml.gov interaction didn't bubble up into an issue?
oops.
[Ian]
DC: I can tell the IETF that we have some activity going on
around this topic (though no formal issue).
2. Technical
2.1 Architecture document
The TAG expects to pick up where it left off (approximately section
3.2) and to complete its walk-through of the Arch Doc.
1. [14]26 Mar 2003 Working Draft of Arch Doc:
1. Action DC 2003/01/27: write two pages on correct and
incorrect application of REST to an actual web page design.
DC requests to withdraw this one.
2. 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.
3. Action DC 2003/03/17: : Write some text for interactions
chapter of arch doc related to [15]message passing, a dual of
shared state. DC refers us to [16]Conversations and State
[14] http://www.w3.org/TR/2003/WD-webarch-20030326/
[15] http://lists.w3.org/Archives/Public/www-tag/2003Mar/0018.html
[16] http://www.w3.org/DesignIssues/Conversations
Actions from 2 June meeting:
1. RF to rewrite section 5. Section 5 is expected to be short.
2. TB to rewrite section 4 based on his [17]proposal for rewriting
section 4and suggestions from the TAG from 2 Jun teleconf.
([18]Done)
3. CL to make available a draft finding on content/presentation.
4. DO to update [19]description of [20]issue abstractComponentRefs-37
5. SW: to continue work on and make available a draft finding related
to the opacity of URIs.
6. NW: Take a stab at proposed new 4.5, wherever it ends up.
7. DO: Write up a couple of paragraphs on extensibility for section
4.
8. IJ: to start incorporating detailed suggestions on Arch Doc made
by the TAG (see [21]IRC log for details)
[17] http://lists.w3.org/Archives/Public/www-tag/2003May/0101.html
[18] http://www.tbray.org/tag/wa-c4.html
[19] http://lists.w3.org/Archives/Public/www-tag/2003Apr/0089.html
[20] http://www.w3.org/2003/06/24-tag-summary.html#abstractComponentRefs-37
[21] http://www.w3.org/2003/06/02-tagmem-irc.html
[Ian]
[Reviewing where we were in 3.1]
At end of meeting last week we were talking about references to
[22]2396bis.
CL: I request that we ignore IRIEverywhere-27 for this
teleconf. I expect to send in some clarifying material soon.
RF: Move the IRI bit at the end of 3.1 (whatever it says) to a
"Future directions" section for this leg of the tripod.
[Some agreement]
[3.2 URI Schemes]
RF: I rewrote this in 2396bis. Looks like first three paras of
arch doc (but more accurate than arch doc). Text in rfc2396bis
is more specific about role of schemes.
DC: I'm not thrilled about idea of cutting the text.
RF: I suggest reusing RFC2396bis text and including reference.
TB/PC: Why redundancy here valuable?
[22] http://www.apache.org/~fielding/uri/rev-2002/draft-fielding-uri-rfc2396bis-03.html
[Roy]
[23]http://www.apache.org/~fielding/uri/rev-2002/rfc2396bis.htm
l#scheme
[23] http://www.apache.org/~fielding/uri/rev-2002/rfc2396bis.html#scheme
[Ian]
DC: The URI draft says "mailto scheme for email addresses" but
says that "news is for usenet groups/articles". Please
harmonize types in the list of examples in RFC2396bis (e.g.,
mailboxes/files/newsgroups).
[Roy]
Each URI begins with a scheme name that refers to a
specification for assigning identifiers within that scheme. As
such, the URI syntax is a federated and extensible naming
system wherein each scheme's specification may further restrict
the syntax and semantics of identifiers using that scheme.
[Ian]
RF: More specific - "URIs ARE classified by scheme"
[Chris]
sounds like keyboard/mic too near desk issues
[Ian]
Action IJ: compare 3.2 text with RFC2396 version 3; compare and
harmonize; leaving about the same amount of text.
TB: In section 3.2, important thing is "New URI schemes". SO
make sure that: (1) reader understands what a scheme is (2)
reader has correct reference to URI spec.
RF: I think TBL and perhaps DC would like to emphasize the para
I copied in - in the sense that one specification leads to
another....
[DanC]
er... "layering"?
[Ian]
TB: Problematic to use myscheme: blort since there's no place
to go look for it.
[Roy]
yep, layered specifications
[Ian]
[Discussion about new URI schemes]
DC: They are extensible, locally (e.g., on my machine)
DC: We don't have a cogent argument in our doc against creation
of new uri schemes. E.g., if you are Apple, deploying new URI
schemes is easy (since Apple controls desktop).
[Chris]
would writing an rfc saying 'this is http spelled different'
make it non-proprietary
[DanC]
yes, bray's got it right here... 'if it has an existing name,
use that name' derivable from network-effects principle
[Ian]
TB: I think the apple thing is a test case. The reason it's the
wrong thing do to is that the information is available by HTTP
(music store responds to http requests). Despite that fact they
identified with a new URI scheme. It's bad since I could have
shared HTTP uri with more people.
[Chris]
okay. what if its a defined http subset, like a get-only
[Ian]
DC: "If it has an existing name, use it." This derives from the
network effect principle.
[Roy]
We should focus on the need to register new schemes and the
built-in reluctance in the IETF to allow registrations of
schemes that do not add value over existing set.
[Zakim]
DanC, you wanted to comment on examples and to and to riff on
multi-party motivation
[Ian]
DC: Apple should have keyed off of mime type. But in the
calendar case, they wanted people to put ics files on the Web.
Think globally.
CL: Perhaps one reason they did this was to subset HTTP. That
would be an advantage to a new scheme.
[Roy]
Answer: no, they wanted webdav URI as well.
[Ian]
PC: What special processing do these scheme resources get?
[tim_mit]
webcal: is of course similar
[Ian]
TB: I'm pretty convinced that there's no difference. Most of
the xml downloaded (before encryption) had to do with
presentation.
[DanC]
wierd! why is "only two tags, key and value" stupid, but RPV is
better than RDF/XML syntax?!?!?!
[tim_mit]
??
[Ian]
TB: They should have published standard HTTP URIs for these
resources and registered a mime type for the weird xml.
PC: So we are saying - don't create URI scheme; register your
mime type.
RF: The registration process for URI schemes is being revised.
In any case, we should emphasize in this section that the URI
schemes have to be registered. Part of the registration process
for URI schemes is MORE STRICT than the one for mime types.
[DanC]
strict registration process for schemes won't make them more
likely to get registered. :-{
[Zakim]
Chris, you wanted to point out that new schemes fits with rhe
upcoming component extensions work
[Ian]
RF: IETF rejects proposed schemes if deemed that they serve no
useful purpose.
CL: Component extensions work at W3C.
[TBray]
Rumor is that they did this because Safari's mime-type
dispatching is horribly inflexible
[Roy]
yes, webdav: was rejected for that reason
[Zakim]
tim_mit, you wanted to discuss why it is harder to do it with a
new mime type, and therefore to suggest comments on the
software architecture which follows.
[DanC]
which scenario are you speaking to, timbl? webcal: or items:?
[Roy]
DAV: was not rejected
[Ian]
TBL: It comes down to your software architecture. A typical
dispatcher either (1) munges internally or (2) downloads and
figures out what software to run on it. Apple registry may
split "application" v. "extension" (like old days)
[DanC]
aha! of course! we need http-head://www.w3.org/ vs.
[24]http://www.w3.org/ , right, Ian? ;-)
[24] http://www.w3.org/
[Ian]
TBL: One problem is two links that refer to the same thing
(e.g., webcal v. http URIs which mean different things
(different verbs for different uri schemes))
[Roy]
How does this discussion result in text for webarch?
[DanC]
the subscribe vs. copy choice is much like the "new window" vs
"new tab" vs same-window choice.
[Chris]
it relates to 'don't make new schemes unless you need to'
[Ian]
TB summarizing:
1. Gratuitous invention of URI schemes is not a good idea.
2. State what the decision criteria are that would strengthen or
weaken the attractiveness of a new URI scheme.
[Chris]
it still sounds like different schems, like get vs something
else, to me
subscribe is clearly having a side effect and should not use
get method
[tim_mit]
2) Gratuitous invention of RDF is not a good idea. On these two
laws hang all the law and the prophets. ;-)
[Ian]
TB: The interaction in apple case is HTTP; no functions
required that can't be done in HTTP; and wider applicability a
good thing => use HTTP uri scheme. If you want a URI and if
scheme exists that meets your needs and
there is a requirement for usage across wide range of
users/applications, then don't invent new one.
SW: Any value in enumerating what the costs are?
TB: Even if URI being invented for private reasons, usually one
finds public reasons.
IJ: Point to deep linking finding as well (basically "Keep your
options open."). Sell it as a benefit - this keeps your options
open!
[Zakim]
tim_mit, you wanted to suggest text for document along the
lines that "Client-side flexibility in the dispatching of new
MIME types should be suficiently powerful to allow new
... MIME types to introduce the necessary functionality"
[Ian]
[TBL: They could have introduced itunes as a sherlock plug-in]
TBL say:
1. Dispatching on mime types is a useful thing
2. We should write up the webcal story or the itunes story in a
finding.
Explain why you lose when you do it that way (itunes or webcal)
[DanC]
hear hear. stories to supplement principles
[Ian]
IJ:
1. Identify different ways of achieving extensibility
2. Relative costs
TBL: Can we have a finding on this? Can TB provide this text as
a finding?
TB: Sure, go ahead.
DC: Tell a story in the finding and seek a balance between
finding an arch doc.
[TBray]
but no more XML (sob):
[25]http://www.tbray.org/ongoing/When/200x/2003/05/14/AppleShut
down
[25] http://www.tbray.org/ongoing/When/200x/2003/05/14/AppleShutdown
[Ian]
Action IJ: Turn [26]TB apple story into a finding.
RF: On editor's note at end of 3.2? I think we should talk
about this, and that it should be in another section.
[this = authority component]
RF: Somewhere we should talk about how URIs are allocated. Some
are allocated using their own mechanisms; most are via
authority delegation. See 3.2 of RFC2396bis for info about
authority info. URI spec doesn't really talk about the social
aspects of delegating name allocation. We should probably
create a new toplevel section (3.x) on name allocation.
IJ: I'd like to make connection between meaning of resource and
authority over that meaning.
[26] http://www.tbray.org/ongoing/When/200x/2003/04/30/AppleWA
[Ian]
RF: "Allocating URIs"
Action IJ: add a new 3.x section on allocating URIs; taking
some text from rfc2396bis/3.2 and expanding slightly on social
aspects.
[Break]
[Ian]
[3.3. Fragment identifiers]
TB: There's lots of new stuff in rfc2396bis. See [27]section
3.5 Notion of a "Secondary Resource" : "The fragment identifier
component allows indirect identification of a secondary
resource by reference to a primary resource and additional
identifying information that is selective within that
resource."
TBL: I don't like the piece in the arch doc about "part or
view"
Action IJ: Integrate RF's 3.5 into from RFC2396bis into arch
doc section 3.3.
TB: For RF's 3.5, there are some issues related to RDF. I'll
send some text; I think people will disagree with "frag id
identifies something selective within a resource"
IJ: Recall that I will be trying to keep one story throughout
arch doc; I will probably do some combination of RF text +
adding to the first scenario in the arch doc.
[27] http://www.apache.org/~fielding/uri/rev-2002/draft-fielding-uri-rfc2396bis-03.html#fragment
[DanC]
before leaving RFC2396bis, shall we acknowledge RoyF's 2 week
'last call' ish new-issue deadline, please, Norm/Stuart?
[Norm]
Yes, DanC
[Ian]
TBL (about RFC2396bis) : The secondary resource (identified by
a thing with a #) is, like the primary resource, is determined
by the naming authority. There should be consistency between
primary and secondary resources. Just because you may not have
a representation yet; the resource still exists.
RF to TBL: Please read 3.5 soon to let me know if you're happy.
RF about RFC2396bis: If draft hasn't changed in 2 weeks, then
submitted to IESG for last call (for an internet-wide last
call). I don't expect technical changes at this point. If there
are minor wording changes, I'll produce a version 04 and then
there will be an immediate draft to IESG. PLEASE make comments
soon (within 2 week, ending 23 June).
[DanC]
RFs request was ackowledged by the chair.
[tim_mit]
TBL: There should be consistency between the idenity of primary
and secondary according to the authority and any infromation
returned in response to the dereferencing of the primary URI.
[Ian]
[3.4. Dereferencing a URI]
DC: Status of [28]metadataInURI-31?
SW: I did a first draft of finding; haven't worked on it
lately. There are various observers of URIs (e.g., origin
server) and various parts of URIs that may be more or less
opaque depending on the observer.
DC: Is your expectation of having finding done by end of June?
SW: I'd like to have finding in shape for our July mtg. I have
comments to integrate before sending to www-tag.
IJ: Big things won't happen for arch doc before end of June. I
can have a good draft for ftf meeting.
[28] http://www.w3.org/2001/tag/ilist.html#metadataInURI-31
[DanC]
yeah... it's a real bummer for us to have these marathon
meetings only to have the editor say "hold that thought for 2
weeks"
[Ian]
---
NW: Push story in 3.4.1 to earlier in 3.4. Move up "All
important resources SHOULD be idnetified by a URI" since not
about representations.
TB: Yes, move to the top.
IJ: Ok, I'll move that note higher up in the doc.
TB: Put it in 3. (before 3.1). Under 3.4.2, put in the example
of the bank account. When you say "Yes, charge my credit card
for the ticket to Oaxaca" to expand on scenario in section 1.
IJ: I can steal some text from finding to flesh out 3.4.2 a
bit; it's barren as it stands.
TB: Leave 3.4.3 with reference to deep linking finding.
NW: Move 3.4.3 up (talk about identification without access
before talking about access)
[Ok]
[3.4.4 Servicing a URI]
TB: Please include the word "persistence" in the title of 3.4.4
NW: Yes. I'd like a different title for 3.4.4
[TBray]
"predictability"? "consistency"?
[Ian]
Some suggested alternative titles for section 3.4.4:
1. Resource persistence and representation consistency
2. Consistency
NW: I think should be moved to 3.5 instead of 3.4.x
TB: Another case is use of namespace name for different things
over time. Leave moby dick example unless you can cover all the
bases with expanded scenario.
[Some agreement to move 3.4.4 to 3.5]
RF: Add 3.6 - future directions.
1. IRIs
2. Things that are not administrative hierarchies (e.g.,
freenet, [29]edonkey2000)
3. Dereferenceable URNs; see DDDS work.
[29] http://www.edonkey2000.com/
[DanC]
[$1\47] Mealling, M., "Dynamic Delegation Discovery System
(DDDS) Part
One: The Comprehensive DDDS", RFC 3401, October 2002.
--
[30]http://www.ietf.org/internet-drafts/draft-connolly-w3c-acce
ssible-registries-00.txt
[30] http://www.ietf.org/internet-drafts/draft-connolly-w3c-accessible-registries-00.txt
[Ian]
TB: Anything in 3.4.4 (or three generally) that at the current
time clashes with either TBL or RF view of what a resource is?
RF: This text mixes up resource metadata and representation of
the resource. Odd to see consistency of representations mixed
with consistency of metadata; perhaps create a subsection for
each. Consistency of both is a good thing.
TBL: Fine by me to say that 2 URIs can identify the same
resource.
[Chris]
how do you know - only by dereferencing and comparing the
resources?
[Ian]
[Schedule]
TB: If people are basically ok with section 4, we are within
spitting distance of a coherent publishable document. How do we
get to last call?
DO: Question of scope of arch doc: Whether to include more on
sem web and web services or not.
[TBray]
what TimBL said
[Ian]
TBL: I think we should go ahead with last call if we are happy
with what we have.
[DanC]
I think there's an attainable WD target in the near term. maybe
that's so obvious that it's boring.
[Chris]
but still worth stating
[Ian]
TBL: We have got a subset. I think that DO is right that our
scope includes Web Services, etc., but I don't think we save
time by not publishing a last call.
TB: I think that we need to take this through last call to get
people to read seriously and have a stake in the ground. I
can't imagine that it would be good to leave it in WD status..
[Zakim]
Chris, you wanted to talk about loaded questions
[Ian]
CL: I agree we should take it to first last call. Might take a
subset of the doc to Rec and work on rest separately.
DO: Why did we ask the AC what they want?
CL: Communication (what questions we face, tradeoffs we are
considering making, awareness of our work)
DO: Some people brought up the issue of "last call". Have we
closed all of our issues?
PC: I agree with DO; I think that there are a fair number of AC
reps who want the arch doc to talk about web services and
semantic web. If we decide that we have to put that info in the
future directions sections, then I expect we'll get a bunch of
comments.We'd need to indicate limits of doc in status section.
Process Doc is a leading example of how to handle an evolving
document (publish so often and cut off issues list)
[DanC]
I won't be party to any decision to go to "first last call". if
"last call" is treated like crying wolf, it'll further lose
value.
[Ian]
PC: the Adv. Board batches the effort. I'd like to go forward
with a first last call, but bring to the AC's attention that we
haven't gotten as far as some AC reps might like.
[Zakim]
DanC, you wanted to noodle on last call before... what? before
we ask the AC who said they're not interested in a document of
this scope? and to say "I won't be party to any decision to go
to "first last call". if "last call" is treated like crying
wolf, it'll further lose value."
[Ian]
DC: I think we have clearly conflicting advice. I'd like to
declare victory at an early opportunity. If we go to last call,
we should be ready to go to the next step. Not sure whether
next step should be CR or PR. We might be promising to "hold
still" on the backward-looking part of the document.
[Chris]
first last call means we have no guarantee that we get to cr;
clearly if all review is positive then we go to cr, but lots of
review often means lots of feedback, often for the first time
[Ian]
DC: I would have hoped the AC would say -publish early publish
often; but that's not the advice we got.
RF: The section of interactions will have (even in skeletal
form), something on http, web services, and sem web. How those
categories impact the notion of interaction. I am on hook to
finish this section for next week.
TBL: I don't see how sem web part of interaction...
TB: Most of current arch doc result of 10 years experience.
[DanC]
quite.
[Ian]
TB: Not getting around the fact that as soon as we move to sem
web and web services, our experience will be very different.
Will be qualitatively different from what we have.
[DanC]
"quite" re semweb/web-svcs being newer
[Ian]
TB: We should get to a point where we think we've gotten to a
point where we are happy with what we've written about how the
thing works today; we owe that to the community.
[DanC]
where was tbray during the AC meeting? 1/2 ;-)
[Ian]
TBL: The Process Doc doesn't address this situation -
half-completed document clashes with dfn of last call. One
possibility is to say, e.g., "last call on arch doc, part I.
"We'll be working on parts I and II, but think last call on
part I reasonable.
[Zakim]
Chris, you wanted to agree about the 'from experience' part but
we don't have all that down yet
[Ian]
CL: Line through old / new stuff not that clear. People have
been doing some aspects of web services for a long time. There
is stuff that's not in the arch doc where we have experience
but we haven't had time to work on it.
[DanC]
(btw... I'm hoping the I18N WG splits the charmod spec
likewise; did we ask them to do that? have we gotten a reply?)
[Ian]
PC: Some TB text might be good rationale to take back to AC;
why we are taking to last call now.
[Chris]
we did ask them and they did not reply
actually I believe they said no unoffiially
[Ian]
PC: There are folks in Web Services area who want TAG's help in
that area; would like to get us involved in that area sooner
rather than later.
[Chris]
so we need to fget an official answer
[Ian]
PC: We need to respond to AC's signal
SW: We have a WSARCH WG; I am not conscious of any issues that
have been fed to us from that WG.
PC: We have had direct requests from other wgs in that activity
(e.g., wsdl).
IJ: Issue 37, not to mention SOAP/GET
PC: If the TAG decides that it wants to go to LC, has a mandate
to respond to the AC, set expectations about material we will
cover and how.
[Zakim]
tim_mit, you wanted to say that there is a lot of arch work
already done in sw area which could be pointed to.
[Ian]
TBL: Owl/RDF Core groups have done a bunch of architectural
stuff.
DO: I observe that we've had a couple of issues with web
services groups; if we reacted quickly to questions from these
groups we'd get even more questions.
[DO mentions target resource attribute]
DO: People that are in these communities aren't looking for TAG
help on current issues in this area; we haven't expressed too
much interest of being in those areas.
IJ to TBL: Send me data on arch info related to sem web if
you'd like included in references section.
[Returning to schedule issue]
TB: I think that going to LC/CR/PR is good on a document. If we
don't do that sometime, then we won't benefit. If we have
consensus that we would lke to get to LC sooner rather than
later, then we should tell the AC and see if they are ok with
that.
[Ian]
Straw poll - July last call on arch doc part I?
1. Yes: TB, DC, NW, CL, IJ, TBL, SW, PC, DO
2. Abstain: RF
[Roy]
I will be travelling almost all of June 19-July 24
[Ian]
DC: Anyone want to take an action to reset expections within
the AC?
[DaveO]
I'll concur. I think we wasted time asking the AC.
[Ian]
DO: If we really wanted to go to last call end of July, we
should have told the AC that. We should have set clearer
expectations at the AC meeting; explained to them the down
sides. I think the question we asked them missed the mark; we
didn't get back information that we found useful.
TB: That may be true, but until we went through the call today,
I don't think we knew.
[DanC]
yes, I think that's life... hindsight is 20-20.
[Ian]
SW: Folks, please make progress on your action items before our
next teleconf.
Action DO/PC: Send draft of AC announcement to tag@w3.org.
3. Not addressed
3.1 Findings
See also: [31]findings.
[31] http://www.w3.org/2001/tag/findings
Next steps for draft findings:
* [32]Client handling of MIME headers; see [33]summary of comments.
* [34]URIs, Addressability, and the use of HTTP GET and POST; see
[35]summary of comments. See also [36]comments from Larry
Masinter.
* [37]How should the problem of identifying ID semantics in XML
languages be addressed in the absence of a DTD?
[32] http://www.w3.org/2001/tag/doc/mime-respect.html
[33] http://lists.w3.org/Archives/Public/www-tag/2003May/0099.html
[34] http://www.w3.org/2001/tag/doc/whenToUseGet-20030509.html
[35] http://lists.w3.org/Archives/Public/www-tag/2003May/0099.html
[36] http://lists.w3.org/Archives/Public/www-tag/2003May/0104.html
[37] http://www.w3.org/2001/tag/doc/xmlIDSemantics-32.html
3.2 New issues?
3.3 Issues that have associated action items
* [38]rdfmsQnameUriMapping-6
+ Action DC 2003/02/06: Propose TAG response to XML Schema
desideratum ([39]RQ-23).
* [40]whenToUseGet-7
+ Next step for [41]revised draft finding?
* [42]namespaceDocument-8
+ Action TB 2003/04/07: Prepare RDDL Note. Include in status
section that there is TAG consensus that RDDL is a suitable
format for representations of an XML namespace. Clean up
messy section 4 of RDDL draft and investigate and publish a
canonical mapping to RDF. See TB's [43]1 June version.
+ Action PC 2003/04/07: Prepare finding to answer this issue,
pointing to the RDDL Note. See [44]comments from Paul
regarding TB theses.
+ Refer to draft TAG [45]opinion from Tim Brayon the use of
URNs for namespace names.
o RF: Folks assume that because the specs say so, URNs
will be persisitent. But persistence is a function of
institutional commitment and frequency of use.
* [46]uriMediaType-9
+ IANA appears to have responded to the spirit of this draft
(see [47]email from Chris Lilley).What's required to close
this issue?
+ Action CL 2003/05/05: Propose CL's three changes to
registration process to Ned Freed. [What forum?]
* [48]URIEquivalence-15
+ SW proposal: Track RFC2396bis where [49]Tim Bray text has
been integrated. Comment within the IETF process. Move this
issue to pending state.
* [50]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 [51]message from Larry Masinter w.r.t. Web services.
* [52]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. Due first week of March.
* [53]xlinkScope-23
+ Status report?
+ See [54]draft, and [55]SW message to CG chairs.
* [56]contentTypeOverride-24
+ Next step on finding "[57]Client handling of MIME headers"
+ [58]Speech Recognition Grammar Specification Version 1.0,
section [59]2.2.2 External Reference by URI
* [60]contentPresentation-26
+ Action CL 2003/02/06: Create a draft finding in this space.
Due 3 March.
* [61]IRIEverywhere-27
+ Action CL 2003/04/07: Revised position statement on use of
IRIs. CL says to expect this by 21 April.
+ Action TBL 2003/04/28: Explain how existing specifications
that handle IRIs are inconsistent. [62]TBL draft not yet
available on www-tag.
+ See TB's[63]proposed step forward on IRI 27.
* [64]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.
* [65]binaryXML-30
+ Action TB 2003/02/17: Write to www-tag with his thoughts on
adding to survey.
+ Next steps to finding? See [66]summary from Chris.
* [67]metadataInURI-31
+ Action SW 2003/02/06: Draft finding for this one. See [68]SW
proposal
+ See also [69]TB email on Apple Music Store and use of URI
schemes instead of headers
* [70]xmlIDSemantics-32
+ See [71]Chris Lilley draft finding.
Action NW 2003/05/05: Point Core WG to CL finding once made
public.
* [72]xmlFunctions-34
+ Action TBL 2003/02/06: State the issue with a reference to
XML Core work. See [73]email from TimBL capturing some of the
issues.
* [74]siteData-36
+ Action TBL 2003/02/24 : Summarize siteData-36
* [75]abstractComponentRefs-37
+ See [76]issue description from David Orchard. Next steps?
[38] http://www.w3.org/2001/tag/open-summary.html#rdfmsQnameUriMapping-6
[39] http://www.w3.org/TR/2003/WD-xmlschema-11-req-20030121/#N400183
[40] http://www.w3.org/2001/tag/ilist.html#whenToUseGet-7
[41] http://www.w3.org/2001/tag/doc/get7-20020610.html
[42] http://www.w3.org/2001/tag/open-summary.html#namespaceDocument-8
[43] http://www.tbray.org/tag/rddl/rddl3.html
[44] http://lists.w3.org/Archives/Member/tag/2003Apr/0046.html
[45] http://lists.w3.org/Archives/Public/www-tag/2003Jun/0003.html
[46] http://www.w3.org/2001/tag/open-summary.html#uriMediaType-9
[47] http://lists.w3.org/Archives/Public/www-tag/2003Feb/0302.html
[48] http://www.w3.org/2001/tag/open-summary.html#URIEquivalence-15
[49] http://www.textuality.com/tag/uri-comp-4
[50] http://www.w3.org/2001/tag/open-summary.html#HTTPSubstrate-16
[51] http://lists.w3.org/Archives/Public/www-tag/2003Feb/0208.html
[52] http://www.w3.org/2001/tag/open-summary.html#errorHandling-20
[53] http://www.w3.org/2001/tag/ilist.html#xlinkScope-23
[54] http://lists.w3.org/Archives/Member/tag/2003Mar/0094.html
[55] http://lists.w3.org/Archives/Member/tag/2003Mar/0104
[56] http://www.w3.org/2001/tag/open-summary.html#contentTypeOverride-24
[57] http://www.w3.org/2001/tag/doc/mime-respect.html
[58] http://www.w3.org/TR/speech-grammar/
[59] http://www.w3.org/TR/speech-grammar/#S2.2.2
[60] http://www.w3.org/2001/tag/open-summary.html#contentPresentation-26
[61] http://www.w3.org/2001/tag/open-summary.html#IRIEverywhere-27
[62] http://lists.w3.org/Archives/Member/tag/2003Apr/0074.html
[63] http://lists.w3.org/Archives/Public/www-tag/2003Apr/0090.html
[64] http://www.w3.org/2001/tag/ilist#fragmentInXML-28
[65] http://www.w3.org/2001/tag/open-summary.html#binaryXML-30
[66] http://lists.w3.org/Archives/Public/www-tag/2003Feb/0224.html
[67] http://www.w3.org/2001/tag/open-summary.html#metadataInURI-31
[68] http://lists.w3.org/Archives/Member/tag/2003May/0050.html
[69] http://lists.w3.org/Archives/Public/www-tag/2003Apr/0151.html
[70] http://www.w3.org/2001/tag/ilist#xmlIDSemantics-32
[71] http://www.w3.org/2001/tag/doc/xmlIDSemantics-32.html
[72] http://www.w3.org/2001/tag/ilist#xmlFunctions-34
[73] http://lists.w3.org/Archives/Public/www-tag/2003Feb/0309.html
[74] http://www.w3.org/2001/tag/ilist.html#siteData-36
[75] http://www.w3.org/2003/06/24-tag-summary.html#abstractComponentRefs-37
[76] http://lists.w3.org/Archives/Public/www-tag/2003Apr/0089.html
4. Other actions
* Action IJ 2003/02/06: Modify issues list to show that
actions/pending are orthogonal to decisions. IJ and PLH making
substantial progress on this; hope to have something to show in
May.
_________________________________________________________________
Ian Jacobs for Stuart Williams and TimBL
Last modified: $Date: 2003/06/10 14:39:32 $
--
Ian Jacobs (ij@w3.org) http://www.w3.org/People/Jacobs
Tel: +1 718 260-9447
Received on Tuesday, 10 June 2003 11:28:53 UTC