W3C | TAG | Previous: 21 Oct teleconf | Next: 4 Nov

Minutes of 28 October 2002 TAG teleconference

Nearby: Teleconference details · issues list · www-tag archive

Note: The Chair does not expect the agenda to change after close of business (Boston time) Thursday of this week.

1. Administrative

  1. Roll call: SW (Chair), DC, NW, DO, CL, TB, RF, IJ (scribe). Regrets: PC, TBL.
  2. Accepted 21 Oct minutes
  3. Accepted this agenda
  4. Next meeting: 4 November. Regrets: DO, CL.

1.2 Completed actions?

1.3 Meeting planning

TAG presentation at AC meeting

TAG slot now 14:00-15:00 on 19 Nov.

TAG face-to-face meeting

2. Technical

2.1 New issues

2.1.1 Use of fragment identifiers in XML

CL: The fragments refer to elements.

DC: Unclear from text of SVG spec (indicates that might be circle element or circle abstraction).

CL: Please don't use SVG frags as an example of using a URI + frag to refer to an abstraction (circle).

2.1.2 Potential TAG issue re consistency XQuery/XSchema from Tim Bray.

See Potential TAG issue re consistency XQuery/XSchema. Postponed to next week.

2.1.3 IRIs everywhere

IRIs everywhere (including XML namespaces) from Jonathan Marsh. Relation to URIEquivalence-15?

NW: The Core WG has drafts that say URI; we are thinking of s/URI/IRI. There has been a request that the TAG issue a finding that we move towards IRIs.

<Ian> CL, DC: I agree that this is an issue.

<Zakim> DanCon, you wanted to ask about WD update and to agree, this is an issue. I've lost plenty of sleep over it.

<Ian> SW: Is this a separate issue from URIEquivalence-15?

<Ian> CL: Yes.

<Ian> DC: Seems the same to me.

<Chris> Its a separate issue to URIEquivalence; it clearly affects the latter, but is not identical to it

<Ian> DC: The test case that comes up is URI with andré in it (with e-accent-aigue). In one RDF doc you include real character, in another, escaped version. The RDF core WG says these are different. We want to make sure XML Namespaces WG is doing the same thing (they are).

<Ian> CL: I agree with DC but it's not the whole story. It's related to URIEquivalence-15 but has other parts. I think we should track this as another issue.

<Ian> [CL gives example of a schema, you can have a space between list of URIs, but IRIs allow spaces.]

<DanCon> yes, that example belongs in the TAG test suite. We do have a test suite, don't we? 1/2 ;-)

<Chris> if IRIs allow escaped spaces, is that the same as an escaped space between two parts of a space-separated list?

Resolved: Add this as issue IRIEverywhere-27.

<Ian>Action NW: Ask Core WG their opinion on haste required for this issue.

<Chris> the 'copy and paste' ma have helped get consensus but is not a good long termstrategy

<Chris> A TAG test suite might be a good idea, in fact

<Ian> IJ: Should we say "URI means interntionalized URIs" in the arch doc?

<Ian> [Lots of no's]

<Ian> RF: IRIs are not URIs; they are an intermediate step towards URIs.

<Ian> DC: Who wishes to own this issue?

<Ian> NW: I can own this issue.

<DanCon> go Norm!

<Ian> SW: I think a summary of URI Equivalence would be helpful.

<Ian> Action DC: Resend redraft of arch doc section 2.2.1 on URIEquivalence-15.

<Ian> go DanC!

<DanCon> I sent it during that magic dead spot between when the agenda goes out on thursday and when the meeting happens on monday.

2.2 Findings

See also: findings.

  1. Findings in progress:
    1. deepLinking-25
      1. TB 2002/09/09: Revise "Deep Linking" in light of 9 Sep minutes. No status update.

Action SW 2002/09/09: Discuss with IJ versioning of findings. Pending. SW and IJ have discussed latest accepted v. latest draft.

<Ian> IJ: I wrote a proposal. SW read it.

<Ian> Action IJ: Send versioning proposal to the TAG.

2.3 Architecture document

See the Architecture document

IJ: There will be a new TR page draft before the AC meeting. I expect to publish a new (public) draft for the TAG tomorrow. This draft incorporates decisions from the ftf meeting and what we get done today.

  1. Action RF 2002/09/25: Propose a rewrite of a principle (rationale -> principle -> constraint) to see whether the TAG prefers this approach. It was suggested that the example be about HTTP/REST, as part of section 4.

    RF: I have sent URI spec to the IETF; now I can get to this.

  2. Completed Action TBL 2002/09/25: Propose text on information hiding. (From 24-25 Sep TAG ftf: "The principle of information-hiding is contrary to global identifiers....Shall we put in the document something about information hiding/independent design of orthogonal specs? You should should not be able to write an xpath to peek into http headers....") [Done]. IJ to integrate this text into next draft.
  3. 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).
  4. Action NW 2002/09/25: Write some text for a section on namespaces (docs at namespace URIs, use of RDDL-like thing).

    NW: For later this week.

2.3.1 Walk-through of remaining review comments (Done TAG-only)

<Ian> From Graham Klyne

<Ian> Why use the term "agent" instead of "program"?

<Ian> CL: I think it's fine to stick with "agent" (e.g., User Agent Guidelines). This is not an "intelligent agent" (artificial intelligence), but not an AI 'autonomous agent'.

<Ian> DC: I think of an agent as a program communicates. People talk about these things as agents.

<Ian> TB: We also speak of HTTP "user agent headers".

<Ian> Resolved: No s/agent/program.

<Ian> RF: The standard is "Internet Media Type", which was changed 7 years ago.

<Chris> yay!

<Ian> (not "content type")

<Ian> IJ: Any interest in distinguishing types from packaging?

<Ian> RF: HTTP does not encapsulate MIME objects.

<DanCon> google says 2,290,000 hits on internet media type. 1,100,000 on MIME type

<Ian> IJ: Use 2045 as the primary reference for MIME?

<Ian> RF: Whichever is the current one...

<Ian> 2045: Bodies, 2046: Media types

<Ian> IJ: I'll use the right spec/term.

<Ian>Agreement to mention "MIME" parenthetically (somewhere in the spec; not necessarily in the Intro).

<Chris> say "colloquially, MIME"

<Ian> DC: Make sure that "MIME" refers to appropriate thing.

<Ian> a) Regarding "All important resources SHOULD be identified by an absolute URI reference."

<Ian> DC: This comment out of date since we are s/absolute URI ref/URI

<Ian> [RF on URI spec: BNF still contains absolute URI reference; I expect pushback on this. It's a massive change.]

<Chris> 1.5.1 case insensitivity - yes, that should be a MUST NOT

<DanCon> pushback is on on the BNF; it's on the change to "URI" that Roy plans to do in the next Internet Draft.

<Roy> expect pushback on later changes for absURIref --> URI

<Ian> b) Graham thinks #3 and #7 are good practice, not principles.

<Ian> IJ: I suggest that we hold on this until RF does redraft in terms of contraints.

<Ian> TB: I think these are arguably principles. We don't have a procedures for deciding. Until we decide, I don't think we should move around.

<Ian> Agree to no change for now.

<DanCon> I think 3/7 are principles, but we haven't explained how/why

<Ian> c) In #6, Graham suggests s/equivalent/about the same thing. [See also editor's note at end of 2.2.5.]

<Ian> IJ: The comment is that "equivalence" is too strong a term.

<Ian> TB: I can see s/equivalent/consistent. I can also see providing some examples (e.g., myyahoo).

<Chris> examples of wrong stuff, and 'surprising but right' would be good

<Ian> SW: I think 2396 uses "consistent".

<DanCon> there's a weather example in 2.6 that's relevant.

<Ian> TB: I could also see leaving "equivalent". Equivalent is not a binary condition.

<Ian> RF: I don't like the term "equivalent" because people may think of byte or description equivalence. If you have a resource that is "my favorite new Web trick", it's hard to distinguish what's equivalent between multiple new Web tricks.

<Ian> CL: Does this come into when to use redirection?

<Chris> 'your weather"#temperature

<Chris> I do that,and get temp in Antibes

<Chris> someone else does it and gets temp in Ottawa

<Ian> IJ: I understand 2.2.5 to be about multiple representations of the same resource.

<Ian> TB: Consistency is the bottom line; but we want more than that.

<Chris> if it did a 302, I could keep using the same uri but I could also refer someone in Ottawa to the temperature in Antibes

<Ian> RF: My white paper uses term "equivalent", but it's less confusing in that context (since about variables, not formats).

<Ian> RF: I usually use term "sameness of resource" in this context.

<DanCon> hmm... "sameness" is a nice informal word.

<Ian> TB: I'm beginning to think that this confusion of multiple representations is just another example of ambiguity problem.

<Ian> IJ: I'm happy to include an example of PNG and GIF representations and that it would be ambiguous if they were clearly different.

<Ian> RF: There's no ambiguity there. There's not ambiguity in terms of the system; just hard for authors.

<Ian> TB: I propose that we lose this principle as an independent principle and move to the section on importance of unambiguity of resources.

<DanCon> ooh; yes, stick it in that bucket.

<Ian>IJ will try to work this into the arch doc this way.

<Ian> 1.5 Summary of good practice notes

<Ian> a) Graham suggests that #1 should be MUST NOT and a principle.

<Chris> 1.5.1 case insensitivity - yes, that should be a MUST NOT

<Ian> TB: Won't we have something out of this IRI issue?

<Chris> yes - that, exactly

<Ian> IJ: Is this harmful to the Web or only to oneself?

<Ian> DC: Seems like good practice to me to not rely on "Hello" v. "hello".

<Ian> TB: We are zeroing in on the IRI debate. Seems that if we are to have a blanket system, this is merely a special case.

<Ian> RF, DC, TB: This is not a princple.

<Chris> I would like the IRI spec to actually state that the correct transform was to lower case hex and upper case hex was WRONG

<Ian> Action IJ: Include link to IRI issue from this point; leave as good practice note.

<Ian> a) Question of use of "media type" v. "content type".

<Ian> RF: "media type" is the whole thing.

<Ian> [No change]

<Ian> b) About: "Representations, when transferred by a Web protocol, are often accompanied by metadata, usually based on [RFC2046]."

<Ian> Graham writes: "RFC2046 defines some specific MIME content types:do you mean metadata in this limited sense, or the more general sense of (say) Content-language? I think RFC2045 may be a more appropriate citation here."

<Ian> RF: I don't see the need for "usually based on [RFC2046]". The metadata is distinct from the packaging format.

<Ian> TB: But de facto, this is usually based on 2046.

<Ian> RF: But HTTP is not based on 2046, except in loose sense of shared properties.

<Ian> RF proposed: "Representations, when transferred by a Web protocol, are often accompanied by metadata."

<Ian> Agreed to: "Representations, when transferred by a Web protocol, are often accompanied by metadata in the message (for example, HTTP headers)."

* DanCon abstains, if that's recorded as a decision

<Ian> Daniel Dardailler comments:

<Ian> Advice to editor: In intro, delete "small and nonexclusive" after protocols.

<Ian> b) DD doesn't like identifiers/formats/protocols split. Thinks formats subsumes protocols.

<Ian> IJ: Is there any discussion on this (e.g., design issues)?

<Ian> DC: I think that this is an interesting point. I don't know that I could convince DD.

<Ian> SW: Is this a religious issue?

<Ian> DC: Or arbitrary...

<Ian> TB: Observe the reality of the Web: there are format and protocol specs. It's a taxonomy that is coherent and matches reality.

<Ian> DC: Also consistent with the way that groups organize and the way people do the work.

<Chris> the model is not the territory - the best model depends on why you are asking the question

<Ian> TB: Say we haven't seen any convincing arguments to the contrary.

<Chris> but separating protocols fromformats seems very justified

<Ian> [Agreement to keep 3-way split.]

<Ian> Question: Does media type *entirely* govern the handling of fragment identifiers?

<Ian> DC: Is media type exclusive of the charset?

<Ian> CL: The media type tells you how to determine what the charset is.

<Ian> DC: Media type metadata value might include charset (as in HTTP).

<Ian> Action for editor: Delete "entirely".

<Ian> IJ: Do we need to flesh out what we mean by media type?

<Ian> TB: No.

<Ian> About: "Representation retrieval is safe: Agents do not incur obligations by retrieving a representation.

<Ian> DD writes: "Could use more details on the meaning of safe and obligation in this context."

<Ian> DC: More details available in finding. We could move more of finding into the arch doc.

<Ian> IJ: Should we change "Safe retrieval: Agents DO NOT incur obligations by retrieving a representation" to "MUST NOT"?

<Ian> RF: This is not a decision of the agent.

<Ian> CL, DC, RF: No change.

* DanCon has just about exhausted his ability to pay attention at this level

<Ian> About: 'Editor's note: Need to say something about difference between assertions about a resource and assertions about a representation. E.g., do not use the same URI to refer to the resource "Moby Dick" and to the particular representation of that resource, or do not use the same URI to refer to a person and to that person's mailbox.'

<Ian> DC: The minutes of the ftf meeting reflect this. I think you should write this up; it would take more than a sentence to write this up. Keep the editor's note for now. This is a piece of httpRange-14.

<Ian> [Agreement not to create new issue; see httpRange-14]

<Ian> Comment from Danny Ayers

<Ian> "I suggest a change in the wording to "Unregistered URI schemes SHOULD NOT be used on the public Internet"."

<Ian> IJ: We say "Unregistered URI schemes MUST NOT be used on the public Internet."

<DanCon> yeah, should not is probably good enough. whatever.

<Ian> TB: You could make a case for the term "use". Are tests in your lab really production use?

<Ian> CL: We could use the word "experiment."

<Ian> Action editor: Clarify that this means "real world use."

<Ian> Chris Lilley: Replacement text re: circle or spline

<Ian> No change for now; Connolly to raise an issue on this for SVG. That's all for today.

<DanCon> thanks for assembling the list, Ian

<Ian> IJ: I expect to have next draft of the Arch Doc tomorrow.

2.4 xlinkScope-23

xlinkScope-23

  1. Action SW 2002/10/21: Starting from email from SW to TAG develop a summary of technical discussion and send to www-tag. Include more rationale for original TAG email to HTML WG.
  2. Coordination with XML CG? See Notes from XML CG call 10 Oct 2002 (Member-only)

<Ian> SW: I put more history, rationale; would like feedback on that. I'd like to use this document to have discussion with HTML WG.

<Ian> DC: The history section is responsive to my request.

<Ian> SW: Who owns this one; seems like activity in different fora. I'd be happy to publish this summary; would like some feedback on my representation on TAG participant opinions is accurate. Please send email to me on that topic. I expect to circulate this on Weds.

2.5 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.
    2. Action NW 2002/09/25: Write some text for an Arch Doc section on namespaces (docs at namespace URIs, use of RDDL-like thing).
  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 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.
  6. Status of discussions with WSA WG about SOAP/WSDL/GET/Query strings?
Ian Jacobs, for TimBL
Last modified: $Date: 2002/10/29 21:27:15 $