- From: Ian B. Jacobs <ij@w3.org>
- Date: Mon, 11 Nov 2002 17:31:39 -0500
- To: www-tag@w3.org, Martin Duerst <duerst@w3.org>
Hello,
The minutes of the 11 Nov 2002 TAG teleconference are available
as HTML [1] and as text below.
- Ian
[1] http://www.w3.org/2002/11/11-tag-summary
--
Ian Jacobs (ij@w3.org) http://www.w3.org/People/Jacobs
Tel: +1 718 260-9447
==============================================================
W3C | TAG | Previous: 4 Nov teleconf | Next: 18 Nov
face-to-face meeting
Minutes of 11 Nov 2002 TAG teleconference
Nearby: IRC log | Teleconference details ? issues
list ? www-tag archive
1. Administrative
1. Roll call: SW (Chair), TBL, TB, DC, CL, PC, IJ
(scribe), Martin Duerst (partly) NW (partly), DO
(partly), Regrets: RF
2. Accepted 4 Nov minutes
3. Accepted this agenda
4. Next meeting: 18 Nov face-to-face meeting.
1.1 Completed actions
* IJ: Add fragmentInXML-28 to issues list.
* IJ: Send this policy to www-tag and make
available from/on findings page. (Done)
1.1 Meeting planning
Don't forget to register for the AC meeting and
related events; please see the 18 Nov face-to-face
meeting page for more information.
TAG presentation at AC meeting
* Action SW, TB, DO: Send slides for AC discussion
to TAG for review. Deadline 11 November. Review
to take place primarily by email. Done (see tag
archive).
* Will TBL oversee and coordinate the three
presentations?
Comments on slide presentations:
1. Keep them short. Each presentation less than 10
minutes.
2. Include links to relevant materials.
3. Link to code examples.
Action IJ:
1. Publish HTML slides submitted by SW, TB, DO. TAG
should comment on draft slide presentations on
the TAG mailing list.
2. Submit three items to the Comm Team for the AC:
TAG summary, SW's summary of XLink, Arch Doc.
TAG face-to-face meeting
* No regrets except from RF. DC will arrive in the
afternoon. MD will be present in the morning.
* Agenda items for four parts of the day. See 18
Nov face-to-face meeting page.
2. Technical
* 2.1 IRIEverywhere-27
* 2.1 Architecture Document
* 2.3 xlinkScope-23
* 2.4 Postponed
2.1 IRIEverywhere-27
1. IRIEverywhere-27
1. See reply from Paul Grosso asking the TAG to
address this issue quickly.
Completed action IJ: Invite Martin Duerst to
the 11 Nov meeting.
2. Status of URIEquivalence-15. Relation to
Character Model of the Web (chapter 4)? See text
from TimBL on URI canonicalization and email from
Martin in particular. See more comments from
Martin.
1. CL 2002/08/30: Ask Martin Duerst for
suggestions for good practice regarding URI
canonicalization issues, such as %7E v. &7e
and suggested use of lower case. At 16 Sep
meeting, CL reports pending; action to send
URI to message to TAG.
[Ian]
TB: I found a draft IRI 02, published today.
Is that the one to look at?
MD: Yes.
[Ian]
NW: Should W3C docs refer to IRIs in the
future?
[Some sense that issues 15 and 17 bound at the
hip]
TB: Martin, what's the 50k view of this issue?
[Chris]
clear dependency, not the same issue though
[Ian]
MD: IRIs in concept have been around as far
back as 1995 and 1996. We have been actively
lately on a draft. Area director at IETF said
that when we think it's ready to go to last
call, he will issue a last call in the IESG as
well.
MD: We've received a lot of comment on the
draft through the years. Lately, comments have
been "move on with this"
[DanC]
one test case, in a question from RDFCore to
XML Core, 14May2002
http://lists.w3.org/Archives/Public/xml-names-
editor/2002May/0003.html
[Chris]
MD: Yes, IRI should be used everywhere
[Ian]
MD: My position (and that of the I18N WG, I
think) is expressed by the Character Model
spec : you should use IRIs basically
everywhere. I personally think that in
practice, IRIs will pop up in practice more
readily.
[Chris]
MD: already in use, but underspecified
[Zakim]
DanC, you wanted to ask if the I18N WG is
maintaining a test collection to go with the
IRI draft
[Chris]
MD: less likely to see in XLink rle attribute
etc, but popular on web pages
[Ian]
MD: There is a test collection (currently 1
test). We also have a "test" for bidi. I tried
to have a lot of examples; if you see places
where more examples would be helpful, please
tell us. The one example helped get consensus
between Mozilla, Opera and Microsoft
TB: General remarks:
1. Whether IRIs are a good idea or not, I have
a concern about the instability of the
current IRI spec. So process issue about
pointing to the spec.
2. Software needs to know whether it's dealing
with an IRI or URI.
3. I still have major heartburn about the case
issue; examples are so non-sensible
(uppercase E7 diff from lowercase e7 gives
me heartburn).
4. There are parts of the IRI spec that I just
didn't understand. There may be additional
work required to reveal some unspoken
assumptions.
PC: Relationship to charmod needs to be
explicit.
[DanC]
yeah, I'm getting to the point where my
technical concerns are addressed, and the
dominant issue is process: what to cite as an
IRI spec? [and please split charmod in 3
parts]
[Ian]
CL: There are a number of ways to deal with
the case-sensitivity of hex escapes:
1. allow %7e and %7E, say they are exactly
equivalent, but no implication that hello
and Hello are equivalent
2. allow both, say they are different (yuk)
3. only allow %7e, %7E is invalid
[DanC]
I prefer "you SHOULD use %7e; %7E is NOT
RECOMMENDED"
[Ian]
MD: On relationship to Charmod: At some point,
some pieces of the IRI draft were in Charmod
(e.g., conversion procedure). But we decided
to separate the specs; Charmod points to IRI
draft. Charmod says "W3C specs should/must use
IRIs where URIs would be used". For Xpointer,
separate issue about encoding/decoding using
UTF-8. Charmod can't advance without the RFC.
[There are several people who suggest
splitting charmod; moving forward one reason.]
[DanC]
yes, please split charmod in 3; did we (the
TAG) request that, Chris? have you heard back?
[Chris]
which is why I suggested splitting charmod
into several pieces
yes, we did request that and no, we have not
heard back
[Ian]
MD: We think this is a URI issue first (case
of hex escapes); once decided for URIs, do the
same thing for IRIs. On the clarity of the IRI
spec, please don't hesitate to send comments.
TB: Could the IRI draft assert that in hex
escaping, lowercase must always be used?
[DanC]
that seems silly, TBray; you're going to
pretend there are no URIs/IRIs that use
upper-case %7E?
or that all of them are wrong
[Ian]
MD: Current deployment is different - some
places use uppercase.
[DanC]
?
"canonical form"?
[Chris]
hence my suggestion to decouple case
insensitivity of hex escapes (which are not
characters) from case insensitivity of
characters
[MJDuerst]
Chris: that goes without saying
[Chris]
but yes, drawback is an extra layer of
processing, however light, beyond binary
string comparison
[TBray]
couldn't insist on upper or lower case for
URis, but could conceivably for IRIs
[Ian]
TBL: Will IRIs have the same role as URI
references?
[Chris]
Martin, anything which is important enough to
go without saying had probably better be said
;-)
[Ian]
TBL: Same space of identifiers, but just a
syntax convention?
[MJDuerst]
But for IRIs, it isn't that important. It's
important when converting from IRI to URI,
[Ian]
TBL: What is being proposed fundamentally:
where do IRIs fit in?
[Zakim]
Timbl, you wanted to wonder All
non-canonical-utf8 URIs are notvalid URIs?
UTF-8 equivalent URIs are consisered
equivalent? Or are IRIs just like URIrefs -
strings for indirectly
... giving a URI in an actual document.
[Ian]
CL: Maybe we should just propose that the IRI
editors get on with it. When I proposed that
%7e and %7E be made equivalent, I was not
proposing that the Unicode characters "e" and
"E" be treated as equivalent.
[timbl2]
%7e is 3 characters in a IRI but 1 character
in a URI
[DanC]
er... %7E is three chars in the URI spec so
far
[Ian]
[One model of URIs is that this is just a
syntax issue: whether you use hex escapes or
other character representation in the string.]
[MJDuerst]
If possible, IRI and URI should be as similar
as possible, except for the larger repertoire
of characters that can be used in IRI
[Ian]
[Comparison of URIs is character-by-character.
Question of whether "%" as part of "%7e" is a
character, or whether "%7e" is the character.]
[DanC]
the URI http://x/%7E has 12 characters in it.
[Chris]
cool! namespaces says compare *on characters*
so declare hex escapers as not characters.
like ncrs in xml
[Ian]
TBL, DC read the URI spec in a way that says
that "%" is a character; since in that spec
characters are ASCII.
[DanC]
ok, but hex escapers have not, yet, been so
declared.
[Ian]
TBL: There are a number of ways to go from
here. I think that even if you define
equivalence in the IRI spec, you need to have
a warning in the URI spec.
MD: You could also say that when you convert
from IRI to URI you always use lowercase for
hex escapes.
[Martin didn't say "for hex escapes" but the
scribe thinks that he meant that.]
[Chris]
seconded
[Ian]
TB: We should say that IRIs are a good idea.
[MJDuerst]
yes.
[Chris]
TimBray: propose IRIs are a good idea
[Ian]
TB: We should not tell W3C WGs to use IRIs
until they are baked. In the arch doc we
should say "Don't hex escape things that don't
need escaping. Use lowercase when you do."
[DanC]
yes, that is: the space of resource
identifiers should/can/does use the repository
of Unicode characters.
[Chris]
(but he did say "when converting from IRI to
URI" which implies hexification)
[Ian]
TB: I think these are things we could do today
usefully.
DC: I am comfortable with the idea of agreeing
having more than 90-something characters to
choose from to build an identifier. Character
space of URIs should be Unicode. When you are
naming resources, you should not be limited to
a set of 90-something characters to build your
identifier.
[Ian]
SW: Will we get help from Schema datatypes?
DC: The schema type is anyURI. Its lexical
space is unconstrained. There might be a thing
or two (e.g., spaces).
MD: Only a problem if you make a list type.
DC: But you can have a list of strings, so
dealt with.
[MJDuerst]
I think value space and lex space are IRI, but
a mapping to URIs is given by a pointer to
XLink
XLink has the main part of the conversion from
IRI to URI, but not the details
[Ian]
DC: In HTTP, you need to escape spaces. There
are no URIs with spaces in them.
TBL: So anyURI is already an IRI-like thing.
[Chris]
no URIs, or no HTTP URIs?
[DanC]
reading
http://www.w3.org/TR/xmlschema-2/#anyURI ...
[Chris]
is file:///C/My Documents a URI?
[TBray]
is anyURI architecturally broken because of
lack of clarity as to whether it's a URI or
IRI?
[Ian]
MD: Some specs already referring to
preliminary versions of IRI spec. I think that
we shouldn't tell WGs to delete their refs and
replace them later; just to upgrade when
appropriate.
[DanC]
"An anyURI value can be absolute or relative,
and may have an optional fragment identifier
(i.e., it may be a URI Reference)."
[Ian]
TBL: I am against the TAG spending time on
something fluffy.
[Chris]
all URIs are IRIs
[DanC]
illegal, equivalent, or NOT RECOMMENDED.
[Ian]
TBL: Until we clarify these issues, we should
not emphasize their use yet.
[Chris]
IRI is not really 'fluffy'. It just needs to
make some decisions and ship.
[Stuart]
MD Agree on the case thing.
[Ian]
MD: Earlier URI specs talked about
equivalence, but practice went in other
directions.
[DanC]
phpht. can't find a specification of anyURI
lexical->value mapping.
[Chris]
DC:any breakage is not recent
TBL: should we work on "URI are broken"
CL: No, I18N WG is on it
TBL: No, they are not, Martin just said so
Stuart: next steps?
TB: Universe of resource identifiers should be
unicode characters. Say 'we approve of IRI
work'. Should *not* say to WGs to drop URI and
gofor IRI because IRI is not final yet
PC: Important what TAG says, we should be
careful what we are stating or seen to state
TB: Do not suggestthatall specs should be
using IRI now
MD: For href,XLink already uses the
[DanC]
IRIs are already in HTML 4. XHTML 1, XLink,
RDF 1.0x, and XML Schema
[Chris]
CL: existing Recs say the same stuff
[Ian]
DC: XML Schema cites XLink
[Chris]
This ID is taking stuff from existing Recs so
that future Recs can all point to one place
[Ian]
TB: We could assert in the arch doc that it
must be crystal clear when referring to
resource ids whether you are talking about
URIs or something else. "When prescribing
resource identifiers, a spec MUST be clear
about whether it's talking about URIs or
something else; don't make software guess."
TBL: A lot of people will think that IRIs are
different from URIs.
[Chris]
TBL: Confusion similar to URIrefs, people with
think IRI is different to URI. Specs should
use the IRI production.: Specs should use the
IRI production
[Ian]
TBL: I think we should write the whole lot
based on a clean IRI proposal.
[Zakim]
Timbl, you wanted to propose we encorage
Martin in doing URIs and and move on, and ask
to know when there is a well-define
relationship between the URI and IRI.
[Chris]
TBL: we should write u the issue once there is
a final IRI spec
[Ian]
DC: What's the estimate for building a test
collection? TB has some cases, I have a few.
[Zakim]
DanC, you wanted to say that a test collection
is top on my wish-list for this stuff
[Ian]
MD: Test cases are on the top of my list.
DC: It would take me about 4 months; need to
get consensus around test cases.
Consensus-building takes time.
[timbl2]
How many of the following are true? For every
IRI there is a corresponding URI? For every
URI there existys a single IRI? All URIs
before this spec are still valid after this
spec? If two URIs are ASCIIchar for char
identical then the equivalent IRIs are uniced
char for char compatible? etc etc etc...
[Ian]
DC: What should the namespaces 1.x spec say?
TB: Not appropriate for namespaces 1.x to go
to IRIs today.
[Chris]
TimBL, I note that three of your questions are
about URI to IRI mapping, wheras the data flow
is the other way
[Ian]
DC: But software is perfectly happy today with
IRIs (in my experience).
TB: I don't think it's ok for namespaces 1.x
to point to Unicode today; I think it's
appropriate *today* to point to RFC2396.
DC: So what should software do when it gets an
IRI?
TB: I would expect software not to notice.
SW: This topic on our agenda Monday morning
(at the ftf meeting)
[DanC]
hmm... morning of the ftf... I gotta find a
proxy for my position on this then.
[Chris]
IETF Proposed Standard good enough for W3C
specs to reference?
[Ian]
MD: I can attend ftf meeting Monday morning to
talk about this. I'd like the TAG to tell us
how to address the case issue.
CL: Can't you just pick one approach?
MD: Current approach is that uppercase and
lowercase are different in escapes, and SHOULD
convert to lowercase.
[DanC]
that current approach is what I prefer.
[timbl2]
My question was, are the guarantees which the
IRI spec gives mentioned in the spec?
Guarantees of consistency etc?
[MJDuerst]
Tim, the spec doesn't give any guarantees. You
need implementations for that.
[DanC]
"consistency etc" leaves a lot of room.
2.2 Architecture Document
See also: findings.
1. Findings in progress:
1. deepLinking-25
1. TB 2002/09/09: Revise "Deep Linking" in
light of 9 Sep minutes. Status of
finding?
2. 7 Nov 2002 Arch Doc
1. Continued action CL 2002/09/25: Redraft
section 3, incorporating CL's existing text
and TB's structural proposal (see minutes of
25 Sep ftf meeting on formats).
2. Completed action NW 2002/09/25: Write some
text for a section on namespaces (docs at
namespace URIs, use of RDDL-like thing).
Done
3. Continued action DC 2002/11/04: Review
"Meaning" to see if there's any part of
self-describing Web for the arch doc.
4. Completed action IJ 2002/11/04: Incorporate
DC and IJ comments about URIEquivalence-15
into next arch doc draft. Done in 7 Nov
draft.
[Ian]
IJ: To get arch doc to TR page, can we resolve
big issues here, then I will incorporate and
get ok's from two TAG participants. What needs
to be done? I haven't had a chance to read
comments yet. I'm up against a publication
moratorium this week and have meetings on
Weds.
SW: On URI terminology, can we commit to
consistency on what RFC2396 becomes?
IJ: I wouldn't want to commit to something
that doesn't exist yet.
CL, DC: Agreed; we need to see it first.
[Ian]
[Agreement that terminology shouldn't
diverge.]
SW: I can live without such a statement, then.
DC: RF has released an internet draft of the
URI spec with the non-controversial changes.
He is working on the next draft, where we will
have to defend our position.: I wouldn't
emphasize reading this draft (if you're only
going to read this spec once).
TB: I can commit to reading it and providing
feedback.
[DanC]
7 Nov 2002 Arch Doc is good enough for me to
publish on TR page. Enough of an improvement
that I endorse publication.
[Ian]
PC: +1
DC: Please be conservative about changes.
IJ: I may insert editors notes.
CL: I will send my edits (for my action item)
for the *next* publication
The TAG agrees that IJ should prepare a draft for the
TR page and should get ok from two TAG
participants in order to publish. TB
volunteers.
2.3 xlinkScope-23
1. xlinkScope-23
1. See summary from SW.
2. Coordination with XML CG? See Notes from XML
CG call 10 Oct 2002 (Member-only)
3. Start formulating a finding?
[Ian]
PC: I have some concerns that we aren't in the
center of discussion on this item. We haven't
yet received comments back on what we sent to
the HTML WG. Are we going to engage with the
HTML WG?
[Some discussion on communication with other
groups.]
TBL: I think that HTML WG thinks they've made
their point.
SW: I have sent email on two occasions to the
HTML WG but not have not gotten a reply from
Steven.
DC: We've not invited the HTML WG to
participate on www-tag.
SW: A message was sent to the HTML WG list,
but didn't reach the archive.
[Chris]
www-html-editors but not in archives. Norm has
a recipt though
[DanC]
indeed... can't find it in
http://lists.w3.org/Archives/Public/www-html-e
ditor/
[Ian]
TB: I think we've done the right thing. I
presume that they're busy.
PC: As far as I'm concerned, there's no point
that this be on our ftf agenda since we've had
no feedback.
DC: We don't have a message from Steven on
behalf of the WG.
SW: Yes, we do. The first message was on
behalf of the WG; I have asked for
confirmation from Steven that this is still
their reply.
CL: I think the HTML WG owes us a response
since we sent a request to their list.
[timbl2]
For the HTML WG,
Steven Pemberton
Chair
Message sent 26 sep 2002 to www-tag
[Ian]
CL: There are also other WGs we should be
discussing this with. HTML wg is not the only
client of hypermedia linking
PC: I'm concerned that more of a plan isn't in
place for how to take this question forward.:
One answer is to wait until the Tech Plenary.
CL: I expect the Tech Plenary to produce a
plan, not the technical solution, however.
That's a long way off (March 2003).
[Chris]
So that date pretty much ensures that HTML WG
will not use the results, if any, of the march
meeting
[Ian]
TBL: I think the TAG has a duty to solve this
issue; I don't think that discussion has been
moved out of the TAG.
TB: I know that several of us have put a lot
of work into discussion on www-tag. I
sympathize with PC's concern, and agree with
TBL that new technical arguments have been
brought forward and consensus not yet
achieved. I think SW has done the right thing
asking the HTML WG where we stand.
SW: Does the TAG hold the same opinion as
formulated at the ftf meeting? I've had no
commentary yet on the summary.
TB: Mimasa pointed HTML WG to the summary on
28 Oct; no commentary from them yet. Thus, I
think we should not drop this, but should not
proceed far in the face of no new info from
the HTML WG.
SW: Should we spend time on this at the ftf
meeting?
TB: SW's summary is cogent.
DC: But contains no proposal.
TBL: TAG could comment on some arguments that
SW has summarized. Some are not strong
arguments and we could comment on those.
[DanC]
gee... it's only a 1-day ftf; if somebody
wants xlink23 on there, I'd like that somebody
to make a proposal.
2.4 Postponed
1. namespaceDocument-8
1. Action TB 2002/09/24: Revise the RDDL
document to use RDF rather than XLink. Goal
of publication as W3C Note. Done.
2. contentPresentation-26
1. Action CL 2002/09/24: Draft text on the
principle of separation of content and
presentation for the Arch Doc.
3. rdfmsQnameUriMapping-6
1. The Schema WG is making progress; they will
get back to us when they're done. See XML
Schema thread on this topic.
4. uriMediaType-9:
+ Action DC 2002/08/30: Write a draft Internet
Draft based on this finding (Deadline 11
Nov). This action probably subsumes the
action on TBL to get a reply from the IETF
on the TAG finding.
5. Status of discussions with WSA WG about
SOAP/WSDL/GET/Query strings?
+ DO 2002/06/24: Contact WSDL WG about this
issue (bindings, query strings and schemas)
to ensure that it's on their radar. See
discussions from 9 Sep TAG teleconf.
________________________________________________
Ian Jacobs, for TimBL
Last modified: $Date: 2002/11/11 22:27:34 $
Received on Monday, 11 November 2002 17:31:43 UTC