- From: Ian B. Jacobs <ij@w3.org>
- Date: Mon, 28 Oct 2002 19:34:12 -0500
- To: www-tag@w3.org
Hello,
Minutes from the 28 Oct 2002 TAG teleconf are available
as HTML [1] and as text below.
- Ian
[1] http://www.w3.org/2002/10/28-tag-summary
Note: HTML minutes may not be available immediately due
to some mirroring slowness.
--
Ian Jacobs (ij@w3.org) http://www.w3.org/People/Jacobs
Tel: +1 718 260-9447
========================================================
W3C | TAG | Previous: 21 Oct teleconf | Next: 4 Nov
Mintes 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?
* Completed Action IJ and PC: Include information
from IJ's summary of process issues (TAG-only)
from AB regarding TAG charter. Also, clarify
meaning of "short-term resolutions" in charter.
IJ to integrate in written summary of TAG
activity.
* Completed Action IJ: Request different time slot
to improve proximity to TAG ftf meeting. TAG slot
now 14:00-15:00 on 19 Nov.
* Action TB: Reformulate issue 28 Oct; we will
decide then whether to add to the issues list.
See original issue: Potential TAG issue in re
consistency, Schema, etc. Done (tag-only).
1.3 Meeting planning
TAG presentation at AC meeting
TAG slot now 14:00-15:00 on 19 Nov.
* Completed Action IJ: Draft written summary of TAG
activity in last six months for AC. The report
will include an assessment of TAG's work,
process, as discussed at TAG ftf meeting. The
report will also include observations on process
issues raised by AC on original TAG charter.
[Done]
SW: Silence on this will be taken as assent.
IJ: Deadline for comments is 4 November.
DC: I'm ok to delegate this to PC and IJ.
* Action SW, TB, DO: Send slides for AC discussion
to TAG for review by 11 November. Review to take
place primarily by email.
TAG face-to-face meeting
* Agenda items? See proposal from Tim Bray
(TAG-only)
* DC: Regrets for first half of meeting due to
travel schedule.
* Action TB: Invite Jonathan to the meeting
(afternoon) to discuss RDDL.
2. Technical
* 2.1 New issues
* 2.2 Findings versioning
* 2.3 Arch Doc comments
* 2.4 xlinkScope-23
* 2.5 Postponed
2.1 New issues
2.1.1 Use of fragment identifiers in XML
* Action DC 2002/09/26: Describe this issue in more
detail for the TAG
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:
+ Action DC 2002/08/30: Write a draft Internet
Draft based on this finding (Deadline 11n
Nov). This action probably subsumes the
action on TBL to get a reply from the IETF
on the TAG finding.
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?
+ 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/10/29 00:15:29 $
Received on Monday, 28 October 2002 19:34:15 UTC