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

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

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

2. Technical

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-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.

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:
  5. 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 $