W3C | TAG | Previous: 24 May teleconference | Next: 14 June

Minutes of 7 June 2004 TAG teleconference

Nearby: IRC log | Teleconference details · issues list (handling new issueswww-tag archive

1. Administrative

  1. Roll call. All present: SW (Chair), TBL, CL, PC, MJ, RF, DC, NW, IJ (Scribe).
  2. Resolved: Accepted the minutes of the 12-14 May F2F
  3. Resolved: Accepted the minutes of the 24 May teleconference
  4. Accepted this agenda
  5. Resolved: Next meeting: 14 June. Chair: NW. Regrets: SW, TBL, IJ.
  6. Action TBL 2004/05/12: Talk to TB and DO about editor role.

1.1 Future meetings

  1. 5 July 2004 TAG teleconference at risk. Regrets: PC
  2. Resolved to hold ftf meeting in Basel 5-7 October 2004. RF to follow up on meeting organization.
  3. August ftf meeting in Ottawa: PC will send hotel information to TAG; more info in IRC log.
  4. Discussion postponed: AC meeting rescheduled for 2-3 December. Does this affect whether to hold TAG ftf meeting in November?
  5. Regrets:
    1. SW: I'll be unavailable from 19 July to 9 Aug.
    2. PC: Regrets 28 June and 5 July.

    Action TAG: Send summer regrets to TAG list.: Send summer regrets to TAG list.

1.3 TAG Charter

Action IJ: Report back on next AB meeting to discuss TAG charter and relation to patent policy.

2. Technical

See also open actions by owner and open issues.

2.1 Possible New Issues

  1. XML 1.1 Question from XMLP-WG


[PC summarizing]
PC: Qnames in xschema broken by xml 1.1.
"broken"? an example scenario would help
PC: I propose that the tag adopt this as an issue and then push to xml activity.
A QName using an XML 1.1 character cannot be validated with Schema 1.0
PC: I suggest that the TAG not spend lots of time on this.
Characters in Names is the more general issue
NW: I agree that we should adopt an issue and hand it off to someone.
CL: I agree with PC's plan generally, and sending it to XML CG appropriate. I agree with NW that this is wider than schema.
DanC, you wanted to ask why this belongs on the TAG issues list, and shouldn't be handled by XML foo?
DC: How does this impact architecture?
xml is architectural
NW: I think that this goes beyond xml (e.g., n3)
TBL: n3 doesn't make reference to the bnf in the xml spec.
true, links *into* xml are affected
CL: I think this is of the same ilk as the xml id issue.
PC: XML CG likely to accept this issue from the TAG.
NW: Take an xml doc that contains a qname that has one of the new unicode characters in it (i.e., in xml 1.1, not in xml 1.0). Now try to put an xpointer in a document that uses a qname. Which version of qnames does it use for the local name part?
DC: Did people see this coming at PR?
PC: Yes.
NW: I think W3C made the right decision, but that some loose ends need to be tied down. I am for adopting the issue, then helping getting it fixed.
TBL: The way that xml 1.1 was presented was that it should only be used "when necessary."

NW: Necessary, e.g., if you want to create documents in Ethiopian language.

Suppport for new issue: RF, CL, NW, PC, TBL, MJ. Abstaining: DC, SW.

Resolved to accept new TAG issue xml11Names-46

Action NW: Write up the issue for the TAG. If there are no objections to formulation, forward to the XML CG on behalf of TAG.

2.2 httpRange-14 status

Action TBL/RF 2004/05/13: Write up a summary position to close httpRange-14, text for document.


RF: There is no proposed resolution on the uri mailing list that any two people can firmly agree to. See thread and another thread started by Larry Masinter.
SW: The title of RFC2396 concerns generic syntax...
RF: IANA requirements require a bit more than that. I also need to incorporate (into RFC2396bis) comments in and The latter needs to go into the RFC since it doesn't really make sense in an informational draft. Those are both cut-and-paste actions.: The spec has primarily been held up due to travel, not the definition. The spec won't progress with the current defn; I don't know what the change will be to enable progression.: Proposing concrete text would help.
DC: I was a bit surprised at direction of discussion.
RF: The issue looks resolvable; finding the right words is the problem. Lots of disagreement about definition of "resource". In my opinion, it seems that people are confused about what a resource is and what it can be. Not sure whether progress will be (1) clearer understanding or (2) less present definition. I don't see obstacles to consensus, but discussion has not converged.

No resolutions or new actions.

2.3 Web Architecture Document Last Call

IJ: Next editor's draft expected 8 June 2004.

No progress on these actions from 2004/05/14:

LC Issue kopecky5

Issue kopecky5


DC: I mailed him; see his 30 March response which includes a clarification.
IJ: I am planning on including similar text in tomorrow's draft and will endeavor to tie in his points re: qnames.
Resolved: Close DC's action for kopecky 5.

IJ: The relevant sentence I'm drafting: "One particularly useful mapping is to combine the namespace URI, a hash ("#"), and the local name, thus creating a URI for a secondary resource (the identified term)."

I would add "(assuming the namespace is flat)" somewhere, i.e., the mapping is only useful when the namespace is flat.
DC: Also mention the one that has more wrinkles - schema component designators.
PC leaves.

LC Issue stickler7

Issue stickler7

IJ: I believe that tomorrow's Editor's Draft will address stickler7.

LC Issue hawke3

Issue hawke3


IJ: I've incorporated his changes into the section on URI ownership. Specifically: "The generation of a fairly large random number or a checksum reduces the risk of URI overloading to a calculated small risk. A draft "uuid" scheme adopted this approach; one could also imagine a scheme based on md5 checksums."
DC: s/fairly//
DC: I propose to either (1) move to future directions or (2) strike the bits about uuid and md5
neither uuid nor mmdf are used because they do not prevent collisions
its future or non-adopted work, so does not conflict with tag to use only registered schemes
support moving to futre directions, unless we think its a failed approach
DC: I'd rather strike than move to future directions at this point.
RF: I'd remove it.
CL: I'd move to future directions.
support removing it also; not hearing that its likely future direction
RF: I don't consider these to be identifiers. md5, e.g., doesn't prevent collisions, but reduces risk. Given a document repository the size of the web, there is a guarantee that there are colliding docs on the web.
TBL: UUIDs have a delegated part.
RF: If properly constructed, yes.
rf also said that its fragile, any edit to the resource gives a new uuid
RF: If properly constructed, have same properties as mid syntax.
MJ: Large random numbers are unwieldly.
TBL: Large random numbers technically work, but raise social issues.
tim, yes, lots of things might be interesting in the fullness of time. meanwhile, nobody has done the homework to finish the uuid: scheme. Let's strike discussion of it, no?
IJ propose: delete second bullet and mention large numbers in third bullet; delete uuid and md5
Mario, that was my point exactly, its a theoretical example
TBL: Say "hypothetical"?
SW: Who would like to see the middle example on large numbers struck?
CL: strike
SW: strike
TBL: Concur
you'll have to tweak "the above approaches". Note that mid/cid also use domain names (the hierarchical part); the number part looks like a file name.
Action IJ: Remove the middle bullet from 2.3.

LC Issue hawke7

Issue hawke7


IJ: I note for hawke6 that we talked about at ftf and didn't adopt.
IJ: I've put SH's text in section 2.7.2: Assertion that Two URIs Identify the Same Resource. I believe some folks commented on this text at the ftf meeting.
TBL: In RDF, sameAs applies to resources.
<http://weather.example.org/stations/oaxaca#ws17a"> owl:sameAs <http://weather.example.com/rdfdump?region=oaxaca&station=ws17a>.
no, I can't endorse "Note also that to URIs that are sameAs one another ...
RF, SW: I don't follow this para.
TBL: I think that reviewer is saying: "If two URIs identify the same resource, that doesn't mean that you can use them interchangeably."
DC: Yes it does.
TBL: Suppose you use "#" in both of them; so they both refer to the same weather station. Sandro is saying that you can, e.g., put one or the other in an RDF statement. But if you dereference them you'll get different information back.
SW suggests a a response à la Pat Hayes: The two URIs denote the same resource but identify two different information resources?
TBL: We use "identify" in the arch doc, not "denote".
IJ: What about s/interchangeable/interchangeable for purposes other than identification/ ?
DC: I don't think this point is worth making (and furthermore, I don't believe it).
Any argument that says something would be true for URIs of one scheme that's false for URIs of another scheme makes me wince
DC: The resources are interchangeable, the URIs are spelled differently.
TBL: But it makes a difference which one you use. If SH intentionally didn't use a "#" in the second URI, then I don't understand his question.
Proposed: Ask SH for clarification - was "#" dropped by mistake in second URI?

Action TBL: Ask Sandro for clarification on whether second URI should have "#".

After the meeting, TBL fulfilled his action on IRC; the following is the relevant excerpt:
TBL: Sandro, I thought your comment was not about hashses but others thought it was.
Sandro Hawke: It is NOT about hashes at all. It's at the level of owl:sameAs, where hashes are irrelevant.
TBL: I thought it was that even though two URIs (say with hashes) identify the same thing, they deref to different resources, so it makes a difference which one you use in communication.
Sandro Hawke: Exactly

The TAG did not expect to discuss issues below this line.

Completed action items:

  1. Action IJ 2004/05/24/: Announce the closure of issue URIEquivalence-15. See proposal to drop this action.

Actions 2004/03/15 (due 25 March?) to review sections:

3. Status report on these findings

See also TAG findings

4. Other action items

Ian Jacobs for Stuart Williams and TimBL
Last modified: $Date: 2004/06/07 21:30:07 $