- From: Ian B. Jacobs <ij@w3.org>
- Date: Tue, 09 Jul 2002 20:07:22 -0400
- To: www-tag@w3.org
Hello,
Minutes [1] available as HTML and text below.
- Ian
[1] http://www.w3.org/2002/07/08-tag-summary
--
Ian Jacobs (ij@w3.org) http://www.w3.org/People/Jacobs
Tel: +1 718 260-9447
W3C | TAG | Previous: 1 Jul | Next: 15 July | IRC log
Minutes of 8 July 2002 TAG teleconference
Nearby: issues list · www-tag archive
1. Administrative
1. Roll call. TB, SW (Chair), DC, NW, IJ, CL, DO,
PC. Regrets: TBL, RF
2. Accepted this agenda.
3. Next meeting: 15 July. Regrets: CL
4. Accepted 1 July minutes
5. Accepted summary of TAG activity in June
6. Confirmed status of completed actions
7. Quorum rules
8. Prioritization of issues
1.2 Completed actions
1. Action IJ: Publish architecture document, asking
in particular for input on issue httpRange-14.
Done.
2. Action SW: Respond to XMLP WG on behalf of TAG.
Done.
3. Action IJ: Integrate/combine one-page summaries
(into architecture document)
1.3 Quorum rules for the TAG
The TAG charter does not include quorum requirements.
The TAG agreed at this meeting not to institute
quorum requirements, to use common sense when making
decisions when few people are at a meeting.
1.4 Prioritzation of issues
The TAG began to discuss prioritization of its
issues, when the topic shifted to expectations of a
timeline for publishing the draft Architecture
Document as a W3C Working Draft. There was general
agreement that the TAG should do this as soon as
possible (and certainly before resolving all the
issues on its issues list). The TAG set a goal of
further fleshing out this document and publishing a
first Working Draft by mid-August, with a drop-dead
date of 30 August.
Action IJ: Find out whether the W3C Comm Team expects
to have a publishing moratorium in August.
2. Technical
* 2.1Architecture document
* 2.2 Internet Media Type registration, consistency
of use
* 2.3 Consistency of formatting property names,
values, and semantics
* 2.4 Are we done with whenToUseGet-7?
* 2.5 augmentedInfoset-22
* 2.6 Postponed
See also: findings.
2.1 Architecture document
1. ACTION TBL 2002/05/05: Negotiate more of IJ time
for arch doc
2. ACTION RF 2002/06/24: Write a paragraph on
technical and political aspects of URIs and URI
References.
Review of some portions of the 1 July architecture
document. The following notes have been reordered
somewhat to map to arch doc sections.
Section 1.1 URI schemes
[Ian]
TB: What do we do to make 1.1 work? Some of
the things in the list under schemes are
duplicates. Bullet one would apply to all URIs
if we took RF's wording. Are other people
happy with 1.1?
DC: I think the list is interesting, but I'm
not satisfied that it works.
SW: I'd like to mention 1.1 scheme-agnostic.
What about a table of schemes and properties?
Section 1.1.1 is about persistence, also a
property in the table. Should we have prose
for each of the properties we identified?
IJ: I think scheme properties are a useful
entry point for other issues we encounter
later on.
Parallel actions TB, DC: Propose text for section
1.1.
Section 1.1.2 Central registries
[Ian]
CL: I have a problem with 1.1.2 (central
registries). Centralized registries of
formatting properties is also useful. As is
the W3C /TR page.
DC: /TR is not a centralized registry. It's
not necessary for every party who does Web
business to consult /TR to continue in life.
/TR is not central to the operation of the
Web.
CL: So what about browsers making up HTML?
TB: There's a qualitative difference between
DNS and /TR.
DC: There is a central registry for MIME
types.
CL: You don't have to look up IANA registry
each time as a user.
TB: But browser developer needs to have
hard-coded.
CL: Is the definition "You looked up once in
one place" or "You have to look up each time."
Having single points of failure is something
else.
DC: As written, the text doesn't make the case
why central registries are bad. There are at
least two: URI schemes, list of MIME types. I
would still claim these are exceptions.
CL: Is 1.1.2 for the whole document or just
1.1?
DC: I think in context. We like anyone to be
able to make up names. But there are
exceptions (e.g., DNS).
CL: Then we should say that 1.1.2 only applies
to naming.
DC: But naming is the only place where central
registries would come up.
CL: Why is 1.4 part of section 1, not formats?
SW: Part of a URI reference.
DC: Good point, though. Maybe it could move to
2 (with link to it from chapter 1)
TB: On central registries - I think we are
telling spec writers "Don't assume a central
registry at W3C must be required in order for
your spec to work." Given that principle, DNS
is arguably unfortunate, but we're stuck with
it. I think DNS different from getting a MIME
type definition (since everyone does this all
the time). I think that the intent of 1.1.2 is
fine. I support the principle as stated and I
think it applies to issues outside of URIs.
Applies to protocols and formats as well.
Section 1.1.1 Social expectations for URI persistence
SW: Just before 1.1.2, we do some URN-bashing.
What should we say about IETF efforts to make
URNs dereferenceable?
DC: This came up under Media type rubrique. I
hope this is still on todo list. Michael
Mealing has made points about IETF decisions
regarding single points of failure. I was not
aware of that decision. I would like to track
down how decisions are made in that area. Two
points
1. TBL was out of line saying on the list that
URNs are not dereferenceable.
TB: But in fact URNs are *not*
dereferenceable.
2. Michael and Tim Bray seem to agree (on the
list) to the fact that we should use
dereferenceable URIs, whatever scheme.
TB: I think we agreed that dereferenceability
is a useful characteristic and that it's a
good thing to call that out.
DC: My issue with URNs is that they just
recreate HTTP. HTTP has administrative
hierarchy, and you get to do whatever you want
in your HTTP space. As far as I can tell, URN
technology doesn't change that - login, then
search, then one TCP transaction. There should
be an arch principle on not reinventing the
wheel. Process question - how can TAG and IETF
parties communicate better?
TB: Principle - Persistence is a matter of
policy, not technology. Nothing in HTTP
prevents you from managing your space well.
Perhaps we should just drop URN reference
unless we take up DC's point that harmful to
reinvent wheel.
NW: I think we'd be hard pressed to argue that
URN is a new scheme.
TB: Please add a boxed principle: "Persistence
is a key characteristice in URI design."
DC: A comment I made on the phone with IJ - a
lot comes down to "economics". Value to having
name agreed by people. If it changes, then the
value goes down.
TB: We say "there are strong social
expectations..."
DC: The document doesn't say what the
expectations are.
DC: Two decisions were made in the IETF
pertaining to URNs:
1. DDNS documents proposed standard; I tracked
down
2. Decision not to use HTTP URIs to name
protocols. I don't know where that decision
was made.
Action DC: Ask Michael Mealing when IETF
decided not to use HTTP URis to name
protocols.
Section 2: Formats
[Ian]
CL: Not sure what I would write in Section
2... Section 2 is the big bleeding piece for
me.
TB: I think the meat is in section 2. All it
needs is to invest time to wrap text around
each issue. Seems mostly editorial. You could
build short sections for 2, as done for
current 1.4.1. I think we have consensus on
format properties as well.
CL: You can put a list of alternatives around
issues as well.
Action CL: Write up some text for section 2. Deadline
30 July.
Additional principles
[Ian]
DC: One principle I've heard about formats is
to separate presentation from structure is an
arch principle as well.
2.2 Internet Media Type registration, consistency of use
1. ACTION DC: research the bug in the svg diagram.
Done.
TB, CL: Remove. PC: Neutral.
DC: I'm happy to do without TBL since Martin said
I18N folks would do something with it if TAG
doesn't.
2. ACTION NW 2002/06/24: Produce PNG version of
image as well. Done.
Resolved: Remove diagram from finding.
[TBray]
The finding is not done due to issue
RFC3023Charset-21.
[Ian]
Current text:
"If so, the IETF registration forms MUST be
part of the language specification, and SHOULD
be part of the specification starting at
Candidate Recommendation status (or Last Call
if the Working Group plans to have sufficient
implementation experience to bypass Candidate
Recommendation). "
DC: IETF area directors didn't say you had to
have the mime type in registry before you
could use it.
[DaveO]
hmm.. seeming less and less like an
architectural principle and more like w3c
process issue.
[Ian]
IJ: The text must be in spec, but isn't
required to be registered.
DC: Area directors said "Don't want to put in
the registry until it goes to Rec." They
prefer to just have internet draft published
every 6 months. They would rather your type
not be in registry but not in internet draft
index.
CL: What can we point to when people tell us
we are doing it wrong?
TB: I agree with DO's point that this is a
process issue. Let's rewrite finding to say
that registration process must proceed in
parallel with w3c process, and documents must
be readily available from w3c specs.
DC: Water down more: Registration information
is relevant and needs to be reviewed along
with everything else in your spec.
IJ: Please note current best practice as we
understand it.
TB: if we write a strong arch principle saying
"You have to get this work done" then that is
enough for the Director to stand on.
PC: I think we need a cookbook for chairs on
what to do.
DO: I'd rather us spend more time on arch
principles and our issues list.
[TBray]
Particularly given that the TAG has
substantial consensus... it's irritating that
we have to keep investing time on this. If we
want a cookbook, how do we get it?
[Ian]
DC: I agree that this is process, but who do
we hand this to?
PC: Our finding should say "here lie
alligators" if uncertain process.
Action PC: Propose alternative wording for finding.
Action CL: Send copy of information sent to tag
regarding RFC3023 to www-tag.
2.3 Consistency of formatting property names, values, and
semantics
NW: I see Håkon's reply only now (due to email
problem).
CL: CSS WG wanted previous good behavior
mentioned in the finding.
DC: HWL's message suggested a central regisry.
Are we saying "no thanks" to that suggestion?
TB: Our finding is correct. Hakon suggested
writing down a process. I don't think this
changes the finding.
CL: In other words, we don't care how you get
it right as long as you do?
DC: Works for me.
NW: I will make another stab that mentions
good behavior and presumably we can call it
done at that point.
2.4 Are we done with whenToUseGet-7?
ACTION DC 2002/06/10: Send note to WSA WG
expressing concern about normative binding for
GET. Done.
SW: Are we done with issue whenToUseGet-7?
DC: Not to my satisfaction. I haven't seen
message to or reply from WSA WG.
DO: In my court. I've had discussions with
various people. I'm still working on what
possibly we should try to say to them.
Certainly dealing with SOAP 1.2 is an issue
before WSDL. I think we should go to them with
something more refined.
TB: I think that the news is good, however,
notably on WSDL front. It's now on their
radar.: My understanding is that they will
build machinery to handle it.
1. Status of discussions with WSA WG about
SOAP/WSDL/GET/Query strings?
+ ACTION 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 24 Jun TAG teleconf.
Open.
2.5 augmentedInfoset-22
1. ACTION DC 2002/06/17: Talk to XML Schema WG
about PSVI. Report to tag, who expects to
decide whether to add as an issue next week.
Done (email to Schema WG).
DC: I don't think we should close until we've
heard back from them.
NW: Schema WG tried to consider DC message at
meeting 2 weeks ago. I don't think it was
clear what we were asking them.
DC: They need to tell me how they are
confused. Please mark as open Tim's action
regarding communication with IETF about media
type names as URIs (issue URIMediaType-9). See
message from DanC.
2.6 Postponed
1. Qnames as identifiers
1. Action NW 2002/06/24: Follow up on Rick
Jelliffe comments/proposal.
2. httpRange-14: Need to make progress here to
advance in Arch Document.
3. 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.
New issues?
1. Bad practice: Overriding HTTP content-type with a
URI reference.See email from TBL.
2. "Deep linking illegal" bad practice? See email
from Tim Bray.
________________________________________________
Ian Jacobs, for TimBL
Last modified: $Date: 2002/07/09 23:50:01 $
Received on Tuesday, 9 July 2002 20:10:22 UTC