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
- Roll call: SW (Chair), TBL, TB, DC, CL, PC, IJ (scribe), Martin Duerst
(partly) NW (partly), DO (partly), Regrets: RF
- Accepted 4 Nov minutes
- Accepted this agenda
- Next meeting: 18 Nov face-to-face
meeting.
1.1 Completed actions
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:
- Keep them short. Each presentation less than 10 minutes.
- Include links to relevant materials.
- Link to code examples.
Action IJ:
- Publish HTML slides submitted by SW, TB, DO. TAG should comment on
draft slide presentations on the TAG mailing list.
- 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
- IRIEverywhere-27
- See reply
from Paul Grosso asking the TAG to address this issue quickly.
Completed action IJ: Invite Martin
Duerst to the 11 Nov meeting.
- 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.
- 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:
- 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.
- Software needs to know whether it's dealing with an IRI or
URI.
- I still have major heartburn about the case issue; examples are
so non-sensible (uppercase E7 diff from lowercase e7 gives me
heartburn).
- 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:
- allow %7e and %7E, say they are exactly equivalent, but no
implication that hello and Hello are equivalent
- allow both, say they are different (yuk)
- 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.
See also: findings.
- Findings in progress:
- deepLinking-25
- TB 2002/09/09: Revise "Deep
Linking" in light of 9 Sep
minutes. Status of finding?
- 7 Nov
2002 Arch Doc
- 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).
- Completed action NW 2002/09/25: Write some text for a section on
namespaces (docs at namespace URIs, use of RDDL-like thing). Done
- Continued action DC 2002/11/04: Review "Meaning" to
see if there's any part of self-describing Web for the arch doc.
- 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.
- xlinkScope-23
- See summary
from SW.
- Coordination with XML CG? See Notes
from XML CG call 10 Oct 2002 (Member-only)
- 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-editor/
- [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.
- namespaceDocument-8
- Action TB 2002/09/24: Revise the RDDL document to use RDF rather
than XLink. Goal of publication as W3C Note. Done.
- contentPresentation-26
- Action CL 2002/09/24: Draft text on the principle of separation of
content and presentation for the Arch Doc.
- rdfmsQnameUriMapping-6
- The Schema WG is making progress; they will get back to us when
they're done. See XML
Schema thread on this topic.
- 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.
- Status of discussions with WSA WG about SOAP/WSDL/GET/Query strings?
Ian Jacobs, for TimBL
Last modified: $Date: 2002/11/11 22:27:34 $