- From: Ian B. Jacobs <ij@w3.org>
- Date: 12 May 2003 18:36:30 -0400
- To: www-tag@w3.org
Hello,
Minutes from the 12 May 2003 TAG teleconference
with the Voice WG are available as HTML [1] and
as text below.
Corrections welcome. Thank you,
_ Ian
[1] http://www.w3.org/2003/05/12-tag-summary.html
===============================================
Minutes of 12 May 2003 TAG teleconference
Nearby: [4]IRC log |[5]Teleconference details · [6]issues list ·
[7]www-tag archive
[4] http://www.w3.org/2003/05/12-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 (45min)
1. Roll call: From TAG: SW (Chair), TBL, DC, TB, RF, CL, PC, NW, IJ.
For discussion with Voice WG, DO present. From Voice WG: Scott
McGlashan, Jerry Carter, Brad Porter, Dan Burnett, David Burke,
Max Froumentin
2. Accepted [8]5 May teleconference minutes
3. Accepted this [9]agenda
4. Next meeting: 2 June [19 June people at AC meeting, 26 May is a
holiday in UK/US/Canada].
[8] http://www.w3.org/2003/05/05-tag-summary.html
[9] http://www.w3.org/2003/05/05-tag.html
1.1 Meeting planning
* TAG virtual meetings 2 and 19 June (no meeting 16 June). See
[10]comments from Stuart.
[10] http://lists.w3.org/Archives/Member/tag/2003May/0009.html
SW: I think we should focus on the arch doc at the 2 June meeting.
PC: There are two kinds of analysis we could do in walking through the
document. Things that people don't agree with.
1.2 W3C Track Presentation
* Action PC 2003/04/14: Propose TAG's [11]WWW2003 track report to
TAG.
[11] http://www2003.org/t_www.htm
The TAG expects to discuss the report by email.
1.3 TAG report at AC meeting
1. [12]Suggestions for TAG presentation at May AC Meeting from DO and
PC
2. Action DO, CL: Present TAG's AC meeting report to TAG.
[12] http://lists.w3.org/Archives/Member/tag/2003Apr/0027.html
The TAG expects to discuss the presentation/slides by email.
[Ian]
See [13]comments from David to TAG
CL: Important issues that are slowing us down
[On httpRange-14]
SW: TimBL and RF have you made progress on your discussions on
httpRange-14?
RF: Haven't discussed since Irvine face to face meeting. I've
been working on RFC2396, focusing on being able to answer
questions there.
[On IRI spec]
RF: At IETF meeting, I thought that we had made a decision. But
Martin re-opened it in light of TAG discussion.
PC: I think the TAG should report the collateral work that's
going on (e.g., working with IETF)
RF: Definitely We are updating the primary specs of the Web in
response to some of the issues that have been raised/addressed.
We removed registered name production from the syntax in
RFC2396. All of the names we were using were DNS anyway. That
was interfering with IRIs ability to know SCRIBE MISSED]. ]
That was an obstacle to IRI-URI-IRI conversion.
TBL: The TAG's primary issue (remaining) has to do with the
namespaces spec.
CL: Other issues holding us up: Comparison of URIs.
PC: IRI-Everywhere precedence: RFC2396, IRI spec, then other
specs can then refer to it. Dependencies among specs seems to
be a good thing to bring up.
CL: Before RFC2396, add IDNS. First half of slides would be to:
[13] http://lists.w3.org/Archives/Member/tag/2003May/0029.html
1. introduce TAG
2. TAG generalities
3. New issues since last 6 months.
4. Issues closed, declined, or pending since last 6 months.
PC: What about RDDL progress?
TB: I'm behind on this. What needs to happen is (1) TB needs to
clean up document. (2) PC needs to write up finding.
[timbl_]
I commend Tim Bray on his blog on iTunes and WWW architecture.
[Ian]
TB: Issue of how to turn RDDL into RDF needs to be solved. If I
commit to do this by the end of this month...
PC: Agreement to publication of RDDL as Note, then ask AC what
to do. Report to AC that we are behind schedule. I'd suggest
adding namespaceDocument-8 to list of issues to discuss; ask
for feedback from AC on what to do with a RDDL Note. Important
question for me is: "How to proceed with RDDL Note? What model
to use?"
SW: Another piece of work we've stalled on is xlinkScope-23.
TB: Reminder, we agreed that, since sufficient interest, that
we would agree to revisit the issue and express our technical
opinion again.
IJ: I read recent XHTML 2.0 draft, section 12.1 on linking. No
HLink; just a comment about the HTML WG following work in this
area.
PC: I think we'd be delinquent not to have xlink-23 on our
list. "Further work pending ....." So for me important issues
are: IRI, HTTPRange, namespace 8, xlinkScope-23. I am concerned
about asking question of last call to AC....
TBL: I'm concerned about the question regarding last call.
E.g., I feel that we address everything that's happened, not
restraining ourselves to things that happened 2 years before we
started. Reasonable to ask us to publish what we the TAG have
now. But I don't want us to be constrained to just old stuff;
people are asking us all the time how Web Services fit with the
Web Architecture; we need to address that. If we talk about a
service-oriented Web and a REST-oriented Web, to talk about one
without the other is crazy. The document should at least make
the distinction. Sem Web / Web Services are not out-of-scope.
The issue of httpRange-14 cannot be resolved without
considering the Semantic Web. I don't think we will have done
the world a favor if we publish something that doesn't take
into account Sem Web / Web Services.
RF: I have no problem with that; it's easier for me if we are
talking about the future Web as well. Then I can bring it all
together in the description.
PC: We could produce a last call document this fall, but it
would largely be focused on Web today, and weak in other areas.
We could ask the AC whether we could take that to Rec with such
a weakness, or should rather fix before we go to Rec.
CL: Right, to what extent is it modular?
IJ: I agree with PC in that, like the Process Doc, it may be a
rolling document. I think we should think about reporting less
to the AC now, and in June addressing the question of last call
in more detail.
2. Technical (45min)
1. [14]contentTypeOverride-24
2.1 [15]contentTypeOverride-24
The TAG and Voice Browser Working Group are meeting this week to
discuss this issue.
* [16]contentTypeOverride-24
+ See finding "[17]Client handling of MIME headers"
+ Completed action IJ: Send email to the Voice Browser WG
+ About: [18]Speech Recognition Grammar Specification (SRGS)
Version 1.0, section [19]2.2.2 External Reference by URI
[16] http://www.w3.org/2001/tag/open-summary.html#contentTypeOverride-24
[17] http://www.w3.org/2001/tag/doc/mime-respect.html
[18] http://www.w3.org/TR/speech-grammar/
[19] http://www.w3.org/TR/speech-grammar/#S2.2.2
[Ian]
SM: I'd like to give the background of how the Voice WG got to
where it is. See also [20]background email from SM
[History: Those present agree to leave history out of public
record.]
Now looking at:
[21]http://lists.w3.org/Archives/Public/www-voice/2003JanMar/00
62.html
SM: There are cases where there's a mismatch between the "type"
attribute value and the server config. See also precedence in
SMIL spec.
[Question of whether SVG does the same thing]
SM: Question of proper server configurations
[20] http://lists.w3.org/Archives/Member/tag/2003May/0012.html
[21] http://lists.w3.org/Archives/Public/www-voice/2003JanMar/0062.html
[Chris]
or perhaps, standardisable server config so authoring tools can
help out
[Ian]
SM: We modified the spec in a not-yet-published draft to say
that (1) the protocol override only takes place when the media
type returned by the server is not recognized by the grammar
processor as a recognized grammar type. We'd like architectural
consistency, but need to address real-world server
misconfigurations.
TBL: What about the type application/xml?
SM: That means nothing to a grammar processor.
TB: Is there a registered mime type?
SM: We are in the process of registering three "+xml" types..
TB: It seems to me to fair to say that this problem is not
unique to this activity. Hints appear as far back as HTML. Is
there some way in which this problem is unique to your
application?
SM: I think you are right, this is a general problem. One thing
that is special is that the grammar processor is not
necessarily a user agent; it can be a background process.
CL: So there may not be a way to consult the user.......
SM: Right, consulting the user may not make a lot of sense.
{Scribe missed comment from Jerry Carter here}
TB to RF: I have heard people say that disregarding media types
may have substantial security implications. I think the finding
should say more about the security issues.
RF: The way that systems work for filtering content through
enterprises: processing meta information and processing
content. You can either take the approach that meta information
is advisory, or that where the meta information disagrees with
the information in the message is a trust breach. Thus, there
are issues of trust and efficiency.
SM: What components enforce this policy [when there's a
mismatch between representation and metadata that was
declared]?
[timbl]
(RF: .... and so when there is a mismatch you can block the
data)
[Ian]
RF: That's simply a possibility the software can take to avoid
trust issues. The processor could also examine all content and
throw away bad stuff. If you don't tell the system what you're
doing with the information, you run into issues of whether the
content is to processed as part of your grammar. The user agent
that's following the reference can distinguish the two, but
intermediaries can't.
BP: To see whether I get this, let's consider example of proxy.
Suppose Flash content has security breach. You want to disable
entry of flash content into the network. You don't want someone
to be able to put up a Web page that references flash content
and that overrides the security filter. The place where people
in the middle can't do anything is by using HTTPS.
CL: Suppose you have a document with Japanese mislabeled as
text/plain, and an intermediary does the wrong thing with it
due to misinterpretation of mime type.
TB: [On dealing with poorly configured Web servers] I
understand the problem, but I'm nervous about what you want to
do.
1. This application (voice browser) is not unique in having this
problem
2. Efficiency gains by being able to dispatch reliably on media
type (rather than look into content) is huge [especially for
busy servers]. Thus, potential efficiency losses are pretty
severe.
3. There is a new rubric of software (Web services security)
where there will be a high volume of messages exchanged.
TB: To work properly, this will rely on servers labeling things
in a standards-conformant way. I don't think there's much
benefit for working around a few misconfigured servers.
SM: I think, in an ideal world, we'd like this. Whose authority
do you take, the author or the server manager?
[Zakim]
timbl, you wanted to mention another example of security
breach, in which a file is made which is valid under two
grammars. and to say that on a larger scale allowing override
is architecturally a very bad precedent.
[Ian]
TBL: The Web architecture says whose the authority over the
URI. A combination of host manager and author. There's a
private arrangement between the two. The "publisher"
(combination of two) is authoritative. It's damaging to change
that. To go this way, in the long term, is damaging because it
undermines the URI as a singleton. You would end up needing a
pair everywhere. We have to defend this fundamental arch
principles.
[timbl]
1) it is early days now - new mime types to become known with
time. it will get better. 2) One can do stuff in the meantime -
dispatching on XML namespace is architecturally very sound.
[Ian]
TBL: After a while, people will fix their servers to serve the
right media type, if not immediately. So the question is: How
can we fix the short term problem?
[Chris]
out of the box servers know about PNG (after7 years!) but not
svg, yet ...
[TBray]
Apache 2 out of the box has SVG I think
[Chris]
cool
[Ian]
TBL: It is sound to look at the toplevel namespace.
SM: That's where the authority of the author is encoded.
[Chris]
authority of author (ns decls) as opposed to server
[Ian]
SM: I'm not talking about general snooping; just a real
representation of the author's intention.
TBL: But it connects completely if you can get your host to
send a .xml as "application/xml"; in that case it's ok to peak
into it.
TB: Even though it's less efficient. Don't start up an xml
parser for every xml message that comes through.
[Zakim]
Chris, you wanted to say this is the passive labelling vs
active processing model dilemma and to talk instead about how
unstandardised control of labelling metadata is the real issue.
[Ian]
CL: There is no standardized way for author to locally set up
server for a particular representation. If there were a
standardized way to do this (here's my data and my metadata),
then authoring tools could do the right thing. A kind of
standardized ".htaccess" file.
[Chris]
we seem to be agreeing its ok to peek at ns in application/xml
to figure out what it is
[Ian]
TBL: Looking at namespace is possible short-term solution. Can
be used for new applications, and also small apps that don't
want to register mime type.
[Chris]
that relates to xmlfunctions-34
[Ian]
BP: I see a general trend in this conversation - not just
whether protocol designation is authoritative relative to
client, but also whether object itself is authoritative (v.
server message).
TBL: The Web architecture is not designed that way - the
content type is authoritative.
SM: Whose authority is definitive?
DC: The client can't distinguish through bits the author v. the
server manager. In many cases, the conflict is not observable.
If you say plain text at the top, and the document is xml, then
that is also plain text. The server is right by definition; you
can't detect the conflict on the client-side in the general
case.
JC: If you use other protocols, you won't get content type.
There's a reality that you will need a backup in some cases.
Whether you want to extend that to case where mime type is
perceived as invalid is the open question.
[Zakim]
TBray, you wanted to agree with TimBL that it's inappropriate
for user-agents to peek&guess
[Ian]
TB: Previously damaging behavior was by one browser that peeked
inside HTML, overriding MIME type. There are improperly
configured servers. I think that if you look at the finding, it
says that what's not ok is to silently work around the
unexpected media type.
PC: So how does the client complain?
TB: Can you preface to the person listing that there's a config
problem?
BP: In the voice xml case, the user is not necessarily in
control of the configuration of their client. Another point: by
saying that the protocol designation is authoritative, we are
implying that application/xml is only ok for general case; but
each vocab that has it's own processing model should have its
own more specific type.
TBL: I disagree a little; e.g., test applications.
[DaveO]
One problem with looking at the namespace name is it doesn't
cover cases where the top element isn't the "owning" element,
i.e., an xslt style sheet that is an xhtml template and the
xslt is embedded within.
[Ian]
TBL: I think that there will be a lot of software that
dispatches on namespace.
TB: You only do that when you don't have a usable media type.
Dispatching on namespace is more expensive than dispatching on
mime type.
IJ: What are scenarios where the user don't have any input
opportunities?
BP: Voice browser we implement doesn't have personal profile
for caller. There are cookies for a given call (some config
possible on a per-call basis), but not configuration across
multiple calls. So problem of persistence across sessions.
[Issues of processing, jumping out of dialog, then back in]
JC: I'd like to go back to dispatch discussion. I agree that
dispatch on namespace is more costly. We are trying to
introduce a level between server media type and namespace that
is supplied by the author.
TBL: I don't think we should not ask the user to guide
correction. Are we talking about guessing across XML or
guessing about something that is not XML.
[Zakim]
timbl, you wanted to say asking the user is not an option we
should waste our time over IMHO.
[DanC]
TimBL said he didn't want to discuss it, not the he didn't want
it to happen (user correction)
[Ian]
JC: In deployed systems, we see 2 cases: either XML v. plain
text OR raw octet stream v. proprietary grammar format.
[Brad]
want to acknowledge JC's earlier comments that breaking call
flow to ask this question is not easy UI task for voice
environment
[Ian]
[TBL suggests a security hack whereby content means one thing
to one person and something else to another.]
[E.g., when parsed per one spec, looks like a pizza order. When
parsed by a more sophisticated parser, knows you are ordering a
pizza + 20 years of life insurance.]
TBL: You are not being consistent about one published meaning
of the document.
TB: Seems like we have shared appreciation of the issues
(safer, sounder, more efficient to rely on media types). But I
think the finding sets the right tone.
SM: The spec attempts to provide a last resort fallback. How do
you deal with the conflict in a voice-only scenario; you don't
really have the opportunity to ask the user how to proceed.
DC: People do things that are counter to specs. As a rule, we
don't change the specs to accommodate this. Why should W3C
accommodate this, unless we think they're doing something good?
[Ian]
IJ: I'd like to point out in finding that SMIL gets it wrong.
And in general, I am listening here to figure out how the
finding will evolve in light of this discussion.
CL: One reason SMIL did this was due to newness of spec.
RF: I don't agree with that at all. At apache, people send us
their mime types; we update the core list regularly. We update
with stuff that's been registered. People say "We haven't
gotten around to registering our MIME type."
[Chris]
and registration is hard. See five-year email archive about
trying to register some types:
http://www.geocrawler.com/archives/3/319/1994/
[Ian]
SM: Registration process is challenging in practice. Big issue
was that we had to continue to apply pressure on registration
folks.
SW: In 2.2.2 (speech grammar), para 2, could you explain to us
again the expected behavior.
[DC excused]
SW: I am confused by the exception sentences. Latest version is
different -
SM reads new text for that section in [22]Voice WG internal
draft.]
JC: Intent is that the media type in the document should take
precedent over introspection.
SM: The essence is that the use of the type attribute should be
considered a last resort.
TBL: The phrase "when the information is unusable to the user
agent" is not well-defined. Something may be unusable for one
agent but not another. When you introduce a new format for your
grammar, it allows agents to get confused. If you produce
another specification (e.g., SG17) and serve it as an SG17
document, and somebody points to your document and says it's an
SG2 document. It works when you test with your software, but
some clients can't use it.
[Scribe didn't get entire scenario]
TBL: Grammar may have picked it up from a trust resource, and
done the wrong thing as a result.
IJ: I haven't understood whether this is really a UI issue. I
don't understand the scenarios enough.
SM: Fine to pop up a prompt when it's your browser, but
different when it's not your user agent in a voice only case
(which would destroy the intent of the voice-only interaction).
BP: Consider also automated systems, where there are no user
interface components.
TBL: My understanding of the way these things will work, is,
e.g., browsing Web site over cell phone, picking up new
information. Don't ask technical questions of user.
BP: Do people really understand what "REPOST FORM DATA" really
means?
SW: Even with override, the actual entity returned could not be
a piece of voice grammar. What would happen then? In that case,
it would generate an exception event (for the AUTHOR to
handle). E.g., the author can terminate the call.
SW: Why would that not also be a sensible way of handling this
case? Is it just a question of frequency of likely occurrences?
JC: In intermediate cases, yes.
SM: Authors control documents but not often can't control the
mime types that are being fed out.
IJ: Is combination of (1) error-handling mechanism and (2)
application/xml sufficient for short term?
BP: Problem with error-handling mechanism is that it stops
processing. We'd rather have processing continue when the
grammar engine can use the content.
SW: The more failure is tolerated in silence, the less one can
address the fact that the servers are not producing the proper
metadata. What we don't want to end up in, is a situation where
we move forward with SRGS and then feel we are blocked later
on.
SM: We recognize that what is proposed is not perfectly in line
with Web arch, but the WG thinks it's a reasonable compromise.
SW: Difference between what apps do and what you write in
specs.
CL: But hiding things doesn't improve interoperability.
IJ: Would it be possible to terminate transactions when
misconfiguration occurs? (This is one possible way to handle
the error. How the error is handled would depend on the
context/application.)
SM: Yes, that is a fallback scenario.
IJ: Send back diagnostics.
CL: Like an ATM - it just shuts down and says "Try another ATM"
SM: Almost all voice platforms would log the recasting as a
warning.
CL: Does the spec say anything about logging?
SM: I think we could add to the spec that there's an
expectation that system log it.
[22] http://lists.w3.org/Archives/Member/w3c-voice-wg/2003Apr/0136.html
[Chris]
expectation of logging clarifies the seriousness of the issue
different expectation of timeliness to fix, in a corporate
environment
[Ian]
IJ: proposal (1) use application/xml for early deployment. (2)
In the spec, say that when mismatch occurs, don't recover
silently from error. Depending on the application, an agent
might, for example, prompt the user for how to proceed, or, in
another (e.g., voice-only) setting, might terminate and log the
transaction mishap.
SM: Would it be permissible to continue without user
permission, but logging?
JC: The user and voice browser are separated by more distance;
user not interacting with the browser. The issue of how you
accept the message is in the domain of the browser maintainer.
Something like: "Browser must be configurable to either proceed
or return error."?
IJ: How does grammar processor talk to browser?
SM: Can happen in different ways.
IJ: Two pieces: (1) grammar processor must signal error (2)
browser needs to get user permission.
JC: But that interrupts call flow.
SM: I think that logging would be acceptable to Voice WG. I
think the Voice WG would accept a req to inform provider of
mismatch, even if agent allowed to proceed.
IJ: Next step?
SM: We'll discuss tomorrow at mtg. Depending on the meeting, we
can have another discussion.
SW: Perhaps at next meeting, poll TAG for individuals and when
they would meet.
2.2 Architecture document
No discussion this week.
See also: [23]findings.
1. [24]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
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 [25]message passing, a dual of
shared state.
[23] http://www.w3.org/2001/tag/findings
[24] http://www.w3.org/TR/2003/WD-webarch-20030326/
[25] http://lists.w3.org/Archives/Public/www-tag/2003Mar/0018.html
2.3 Issues that have associated action items
* [26]whenToUseGet-7
+ Completed action IJ 2003/05/05: Solicit review of [27]revised
draft finding, after taking into account comments from DC.
([28]Done)
* [29]uriMediaType-9
+ IANA appears to have responded to the spirit of this draft
(see [30]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?]
* [31]abstractComponentRefs-37
+ See [32]issue description from David Orchard
+ Next steps?
* [33]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.
+ Action PC 2003/04/07: Prepare finding to answer this issue,
pointing to the RDDL Note. See [34]comments from Paul
regarding TB theses.
+ Action TB 2003/04/28: Draft a TAG opinion on the use of URNs
for namespace names, for review by the TAG
o RF: Folks assume that because the specs say so, URNs
will be persistent. But persistence is a function of
institutional commitment and frequency of use.
* [35]xlinkScope-23
+ Status report?
+ See [36]draft, and [37]SW message to CG chairs.
* [38]IRIEverywhere-27
+ Completed action TB 2003/04/14: Draft a proposed step forward
on IRI 27. ([39]Done). In that [40]email, TB proposes to
close this issue.
+ 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. Progress: See [41]email to
TAG.
[42]URIEquivalence-15
+ SW proposal: Track RFC2396bis where [43]Tim Bray text has
been integrated. Comment within the IETF process. Move this
issue to pending state.
* [44]xmlIDSemantics-32
+ See [45]Chris Lilley draft finding.
Action NW 2003/05/05: Point Core WG to CL finding once made
public.
* [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.
Due 3 March.
* [52]rdfmsQnameUriMapping-6
+ Action DC 2003/02/06: Propose TAG response to XML Schema
desideratum ([53]RQ-23).
* [54]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 [55]message from Larry Masinter w.r.t. Web services.
* [56]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. Relation to [57]Client handling of MIME
headers?
* [58]metadataInURI-31
+ Action SW 2003/02/06: Draft finding for this one.
+ See also [59]TB email on Apple Music Store and use of URI
schemes instead of headers
* [60]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.
[26] http://www.w3.org/2001/tag/ilist.html#whenToUseGet-7
[27] http://www.w3.org/2001/tag/doc/get7-20020610.html
[28] http://lists.w3.org/Archives/Public/www-tag/2003May/0051.html
[29] http://www.w3.org/2001/tag/open-summary.html#uriMediaType-9
[30] http://lists.w3.org/Archives/Public/www-tag/2003Feb/0302.html
[31] http://www.w3.org/2003/05/24-tag-summary.html#abstractComponentRefs-37
[32] http://lists.w3.org/Archives/Public/www-tag/2003Apr/0089.html
[33] http://www.w3.org/2001/tag/open-summary.html#namespaceDocument-8
[34] http://lists.w3.org/Archives/Member/tag/2003Apr/0046.html
[35] http://www.w3.org/2001/tag/ilist.html#xlinkScope-23
[36] http://lists.w3.org/Archives/Member/tag/2003Mar/0094.html
[37] http://lists.w3.org/Archives/Member/tag/2003Mar/0104
[38] http://www.w3.org/2001/tag/open-summary.html#IRIEverywhere-27
[39] http://lists.w3.org/Archives/Public/www-tag/2003Apr/0090.html
[40] http://lists.w3.org/Archives/Public/www-tag/2003Apr/0090.html
[41] http://lists.w3.org/Archives/Member/tag/2003Apr/0074.html
[42] http://www.w3.org/2001/tag/open-summary.html#URIEquivalence-15
[43] http://www.textuality.com/tag/uri-comp-4
[44] http://www.w3.org/2001/tag/ilist#xmlIDSemantics-32
[45] http://www.w3.org/2001/tag/doc/xmlIDSemantics-32.html
[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#HTTPSubstrate-16
[55] http://lists.w3.org/Archives/Public/www-tag/2003Feb/0208.html
[56] http://www.w3.org/2001/tag/open-summary.html#errorHandling-20
[57] http://www.w3.org/2001/tag/doc/mime-respect.html
[58] http://www.w3.org/2001/tag/open-summary.html#metadataInURI-31
[59] http://lists.w3.org/Archives/Public/www-tag/2003Apr/0151.html
[60] 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 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/05/12 22:30:56 $
--
Ian Jacobs (ij@w3.org) http://www.w3.org/People/Jacobs
Tel: +1 718 260-9447
Received on Monday, 12 May 2003 18:36:35 UTC