W3C home > Mailing lists > Public > www-tag@w3.org > November 2002

[Minutes] 11 Nov 2002 TAG teleconf (IRIEverywhere-27, Arch Doc, xlinkScope-23)

From: Ian B. Jacobs <ij@w3.org>
Date: Mon, 11 Nov 2002 17:31:39 -0500
Message-ID: <3DD02FCB.1030709@w3.org>
To: www-tag@w3.org, Martin Duerst <duerst@w3.org>


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
    * Will TBL oversee and coordinate the three

  Comments on slide presentations:
   1. Keep them short. Each presentation less than 10
   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
        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.

	TB: I found a draft IRI 02, published today.
	Is that the one to look at?

	MD: Yes.

	NW: Should W3C docs refer to IRIs in the
	[Some sense that issues 15 and 17 bound at the
	TB: Martin, what's the 50k view of this issue?

	clear dependency, not the same issue though

	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
	MD: We've received a lot of comment on the
	draft through the years. Lately, comments have
	been "move on with this"

	one test case, in a question from RDFCore to
	XML Core, 14May2002

	MD: Yes, IRI should be used everywhere

	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

	MD: already in use, but underspecified

	DanC, you wanted to ask if the I18N WG is
	maintaining a test collection to go with the
	IRI draft

	MD: less likely to see in XLink rle attribute
	etc, but popular on web pages

	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

	PC: Relationship to charmod needs to be

	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

	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

	I prefer "you SHOULD use %7e; %7E is NOT

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

	yes, please split charmod in 3; did we (the
	TAG) request that, Chris? have you heard back?

	which is why I suggested splitting charmod
	into several pieces
	yes, we did request that and no, we have not
	heard back

	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?

	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

	MD: Current deployment is different - some
	places use uppercase.

	"canonical form"?

	hence my suggestion to decouple case
	insensitivity of hex escapes (which are not
	characters) from case insensitivity of

	Chris: that goes without saying

	but yes, drawback is an extra layer of
	processing, however light, beyond binary
	string comparison

	couldn't insist on upper or lower case for
	URis, but could conceivably for IRIs

	TBL: Will IRIs have the same role as URI

	Martin, anything which is important enough to
	go without saying had probably better be said

	TBL: Same space of identifiers, but just a
	syntax convention?

	But for IRIs, it isn't that important. It's
	important when converting from IRI to URI,

	TBL: What is being proposed fundamentally:
	where do IRIs fit in?

	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.

	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.

	%7e is 3 characters in a IRI but 1 character
	in a URI

	er... %7E is three chars in the URI spec so

	[One model of URIs is that this is just a
	syntax issue: whether you use hex escapes or
	other character representation in the string.]

	If possible, IRI and URI should be as similar
	as possible, except for the larger repertoire
	of characters that can be used in IRI

	[Comparison of URIs is character-by-character.
	Question of whether "%" as part of "%7e" is a
	character, or whether "%7e" is the character.]

	the URI http://x/%7E has 12 characters in it.

	cool! namespaces says compare *on characters*
	so declare hex escapers as not characters.
	like ncrs in xml

	TBL, DC read the URI spec in a way that says
	that "%" is a character; since in that spec
	characters are ASCII.

	ok, but hex escapers have not, yet, been so

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


	TB: We should say that IRIs are a good idea.


	TimBray: propose IRIs are a good idea

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

	yes, that is: the space of resource
	identifiers should/can/does use the repository
	of Unicode characters.

	(but he did say "when converting from IRI to
	URI" which implies hexification)

	TB: I think these are things we could do today
	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

	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.

	I think value space and lex space are IRI, but
	a mapping to URIs is given by a pointer to
	XLink has the main part of the conversion from
	IRI to URI, but not the details

	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.

	no URIs, or no HTTP URIs?

	http://www.w3.org/TR/xmlschema-2/#anyURI ...

	is file:///C/My Documents a URI?

	is anyURI architecturally broken because of
	lack of clarity as to whether it's a URI or

	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

	"An anyURI value can be absolute or relative,
	and may have an optional fragment identifier
	(i.e., it may be a URI Reference)."

	TBL: I am against the TAG spending time on
	something fluffy.

	all URIs are IRIs

	illegal, equivalent, or NOT RECOMMENDED.

	TBL: Until we clarify these issues, we should
	not emphasize their use yet.

	IRI is not really 'fluffy'. It just needs to
	make some decisions and ship.

	MD Agree on the case thing.

	MD: Earlier URI specs talked about
	equivalence, but practice went in other

	phpht. can't find a specification of anyURI
	lexical->value mapping.

	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

	IRIs are already in HTML 4. XHTML 1, XLink,
	RDF 1.0x, and XML Schema

	CL: existing Recs say the same stuff

	DC: XML Schema cites XLink

	This ID is taking stuff from existing Recs so
	that future Recs can all point to one place

	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.

	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

	TBL: I think we should write the whole lot
	based on a clean IRI proposal.

	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.

	TBL: we should write u the issue once there is
	a final IRI spec

	DC: What's the estimate for building a test
	collection? TB has some cases, I have a few.

	DanC, you wanted to say that a test collection
	is top on my wish-list for this stuff

	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.

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

	DC: What should the namespaces 1.x spec say?
	TB: Not appropriate for namespaces 1.x to go
	to IRIs today.

	TimBL, I note that three of your questions are
	about URI to IRI mapping, wheras the data flow
	is the other way

	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
	TB: I would expect software not to notice.
	SW: This topic on our agenda Monday morning
	(at the ftf meeting)

	hmm... morning of the ftf... I gotta find a
	proxy for my position on this then.

	IETF Proposed Standard good enough for W3C
	specs to reference?

	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.

	that current approach is what I prefer.

	My question was, are the guarantees which the
	IRI spec gives mentioned in the spec?
	Guarantees of consistency etc?

	Tim, the spec doesn't give any guarantees. You
	need implementations for that.

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

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

	[Agreement that terminology shouldn't
	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

	7 Nov 2002 Arch Doc is good enough for me to
	publish on TR page. Enough of an improvement
	that I endorse publication.

	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

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?


	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
	[Some discussion on communication with other
	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
	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.

	www-html-editors but not in archives. Norm has
	a recipt though

	indeed... can't find it in

	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.

	For the HTML WG,
	Steven Pemberton
	Message sent 26 sep 2002 to www-tag

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

	So that date pretty much ensures that HTML WG
	will not use the results, if any, of the march

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

	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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:55:55 UTC