- From: Ian B. Jacobs <ij@w3.org>
- Date: Mon, 06 Jan 2003 22:33:22 -0500
- To: www-tag@w3.org
Hello,
TAG minutes from the 6 Jan 2003 teleconf available as
HTML [1] and as text below.
- Ian
[1] http://www.w3.org/2003/01/06-tag-summary.html
==========================================================
W3C | TAG | Previous: 16 Dec teleconf | Next: 13 Jan
2003 teleconf
Agenda for 6 Jan 2003 TAG teleconference
Nearby: IRC log | Teleconference details ? issues list
? www-tag archive
Note: The Chair does not expect the agenda to change
after close of business (Boston time) Friday of this
week.
1. Administrative (30min)
1. Roll call: All present - TBL, SW (Chair), TB, DO,
PC, NW, RF, CL, DC, IJ (Scribe).
2. Accepted 16 Dec minutes
3. Accepted this agenda
4. Next meeting: 13 Jan 2003. (No regrets)
1.1 New Year's Resolutions (or what would we like to
accomplish in 2003?)
The following are some points suggested by TAG
participants:
1. TB: Finish deepLinking-25 by end of January.
2. PC: More evangelism of Architecture Principles.
CL: Once the Arch Doc reaches Rec, this will help
deployment.
3. TB: Take Arch Doc to last call by mid-2003. There
was agreement that further discussion on
scheduling should be done at the face-to-face
meeting (after the TAG election closes).
1.2 Meeting planning
* Next TAG ftf: 6-7 Feb 2003 in Irvine, CA (USA).
Regrets: NW. Arriving Thursday afternoon: TB.
Action IJ: Create meeting page.
* Call for agenda items.
2. Technical
* 2.1 httpRange-14
* 2.2 New issue: XInclude and content negotiation?
* 2.3 Draft email about next version of XML
* 2.4 namespaceDocument-8
* 2.5 Postponed
2.1 httpRange-14
Discussion of the state of the Architecture Document
led into discussion of issue httpRange-14 and
terminology; see below.
See new threads here and here.
[Ian]
TBL: I find there's a fundamental problem with
the doc without httpRange-14 resolved. It's
based on sand since I can't write axioms since
terms not well-defined. Sandro Hawke has
started working on text and came to the
conclusion that the doc is difficult to work
with with the doc in its current form.
PC: We need to evangelize the parts we already
agree to (e.g., interviews, speaking
opportunities).
CL: I agree that we shouldn't hold up
low-hanging fruit for thornier issues.
DC: I would be interested to find out more
about the food chain of information going to
webmasters, and get in the loop.
TB: I want to register my disagreement with TBL
on the state of the arch doc; I think it is
useful.: I am willing to invest some more
effort in httpRange-14, but we are chartered to
produce a Rec.
RF: I find the document hard to work with as
well. It's a compromise between two positions
that doesn't satisfy either. I think finding
the way to describe the terminology in a
precise way is the way forward. We need to
define the terminology associated with
resources in a precise and consistent manner. I
think httpRange-14 is a red herring.
TBL: httpRange-14 is about whether
network-available resources are a distinct
class. There is confusion between "things in
general" and "Things with information content",
which makes it difficult.
RF: I think it's necessary for us to agree to a
set of terms, otherwise the doc's kind of
pointless.
CL: I disagree. Some portions are independent.
RF: But we need to be able to say what is the
target of a GET.
CL: Why can't the HTTP spec say that?
[Agreement that glossary with well-defined
terms is important.]
[PaulC]
What are the top 5 terms in the Architecture
document that TimBL and Roy think need tighter
definitions?
[Ian]
IJ: I think ongoing input from all participants
will be key to getting to last call mid-year.
RF: I think discussion of last call should wait
until Feb meeting.: I think we need to write
down different perspectives on what the
terminology should be. I think that TimBL and
my positions will likely converge once written
down.: Until then, it's in our court to suggest
changes; TAG should not stop work while we do
this. Terms come from 5-6 sources; we should
not invent new terms. There's also descriptive
text needed to explain what we're talking
about.
[timMIT]
Top 5: Resource, Information Resource (aka
Document), URI, ...
[Ian]
RF: Nobody has sent me any text for RFC on
URIs.
After other discussion, we continued as follows.
[Ian]
SW: Should httpRange-14 remain on the
back-burner or should we give it more
attention?
TB: We have new input from Sandro Hawke.:
Sandro has also proposed some good language:
WebArch Ambiguity about Objects, PLUS Suggested
Major Replacement
TBL: I had produced a draft with language I
thought was consistent. That text has been
dropped. Text that distinguishes documents
(network available info) from other objects.
Those who work with Sem Web technology see this
as a problem.
[DanC]
where did that edit go? when did timbl do that?
[TBray]
there's a real issue here: whether the
architecture recognizes two classes of URIs
[TBray]
empirically there *are* two classes in
practical usage
[Ian]
TBL: It's a problem when you try to build
systems that model real-world objects.
[TBray]
But I see no gain & some loss in trying to
write the difference into the architecture
[Ian]
TBL: RF has said that this is RDF's problem; I
feel uncomfortable taking the group there
again.: Sandro has a different solution:
Identifiers always refer to documents. You must
distinguish the case when you are referring to
an abstract thing behind a document. This is
the only other consistent model I've seen.
CL: I heard TBL say we have lots of experience
with URIs for documents/data. I agree, and I
also agree that the sem web wants to point to
things not on the Web. I agree with Sandro that
the way to do that is to define a new way for
doing so. One solution is a new URI scheme
(e.g., "now" - not on the Web) This would
indicate that the URI is not dereferenceable. I
think we need a new mechanism to do new things,
and leave the old one for old things, for which
it works fine.
[DanC]
Stuart, pls phrase the question as "is there
sufficient new information to believe that
re-opening this issue for discussion would be
worthwhile?"
[Chris]
And most importantly that would leave the
*existing* way of pointing at network stuff
alone
[Ian]
TB: Sandro has convinced me that I disagree
with what CL said - defining a URI scheme for
things not on the Web will not be helpful. It
seems that the Web arch doesn't need to talk
about the empirical difference between resource
classes.
[Chris]
If you don't do that then you are saying that
SW cannot use URI for things not on the web
[Ian]
TB: Something can be used for naming and
orthogonally for dereferencing (e.g., namespace
names). It's a good thing to be able to decide
later. I still have trouble understanding what
breaks with this world view.
RF: If you define a new URI scheme, I can
create a proxy that GETs representations in
that URI space.
[TBray]
the notion that something should be *defined*
as non-dereferencable seems deeply broken to me
[Chris]
I accept Roy's proxy argument
[Ian]
RF: Given the way you can use existing
applications today, you can't make such
distinctions within URI space.
DO: I think we need to be more vigorous when we
start putting automated resource
representations at end of URis.
[Roy]
punt
[DanC]
it's not "at the back of the queue"; it's no
longer on the queue. We have decided we can
write the arch doc without it.
[TBray]
There are some resources which more or less
*are* their representation, e.g. cute-cat.jpg,
others clearly not, e.g. XML namespace names.
Does the architecture care?
[Ian]
TB: This is being taken up on www-tag (whether
we want it to be or not). I recommend that TBL
look at whether there's a way forward there.
2.2 New issue: XInclude and content negotiation
See "Architectural problems of the XInclude CR."
[TBray]
suggests that this is further evidence that
XInclude was a mistake
[Ian]
DC: I would like to see the WG's response
first; whether commenter is satisfied.
[Zakim]
TimMIT, you wanted to say that the issue is not
things which are not on the web, its things
which are not information objects on the web
(you can't get them by looking them up) but
... which you can get information *about* by
looking them up.
DanC, you wanted to ask if the WG has responded
to the XInclude comment yet
2.3 Draft email on what next version of XML might include
1. xmlProfiles-29
1. Completed action NW 2002/12/09: Write up a
first draft of the TAG position. See NW
proposal (TAG-only).
[Ian]
[DC reads portion of CL's objection.]
DC: Is XML Base excluded intentionally?
NW: Yes.
CL: XML IDs are not a dying thing.
NW: They are not dying quickly.
CL: I disagree with NW.
[DanC]
the way XPointer uses ID should die.
[Ian]
[Discussion of use of IDs]
[timMIT]
DanC< you queued yourself to say " the way
XPointer uses ID should die."
[Ian]
CL: Easier to declare that xml:id is of type
ID. If you want anything different, then use
DTDs or other validation mechanisms.
[TBray]
in fact for virtually all languages invented at
W3C and elsewhere, foo#bar points to <anything
id="bar">
[Ian]
CL: I'm not happy having a subset that says you
can't use DOM and XPointer.: I want to separate
validation and decoration.: These two concepts
were conflated in SGML; we could get this right
now.
[timMIT]
CL: There are two separte operations. one is
the parsing of the input to produce the
infoset. Another is a validation of the
document syntax. These were confused in SGML
and not quite sepraated in XML. This moves
toward fixing this.
[Ian]
TB: It's too late for xml:id. Every language
out there uses "id" to be of type ID.: You
could adopt James Clark's solution, or you
could bite the bullet and say that #id means
the element with the attribute "id"."
CL: Another way (also proposed by James) is to
say that xml:id is decoration.
TBL: Is this an implicit declaration in all
documents?
[TBray]
that's xml:idAttr and you say xml:idAttr="id"
[DaveO]
I'd like to make a "matrix" suggestion. What
are the solutions that we are talking about,
and what are there pros/cons?
[DanC]
Bray referred to the decoration idea as
"Clark's idattribute" I believe
[Ian]
CL: Two ways to do this - declare in namespace,
or do by decoration.: I note that content will
have to be changed anyway.
TB: All this aside, I think that NW's
formulation is correct. We've muddled along and
it doesn't cause practical problems.
[CL: It does.]
[Chris]
Grrrrrrr
[Ian]
TB: The risk of slippery slope for just one new
feature is horrendous.
[Chris]
It causes *immense* practical problems
GetElementByID is the single most used DOM call
[Norm]
I still assert that the two problems are
seperable and should be solved separately
[Chris]
I still assert that they are not orthogonal.
They are separable, but not totally orthogonal
[Ian]
DO: I am susceptible to both arguments: no new
features v. getting ids correct.
[Chris]
the axes are, like , 70 degrees apart not 90
[DanC]
your point that they're not orthogonal is well
made, Chris.
[Ian]
DO: In Web services, lots of "id" attributes
being defined over and over (and named "id").
[Chris]
I agree its well made but TimB does not ...
[Ian]
DO: I'd like us to keep the door open on this
particular feature creep.
[Norm]
I accept that they are not properly orthogonal.
But they are seperable. The problem exists
*now* independent of the subset.
[TBray]
rip the name "id" out of the users' hands I say
[Ian]
DO: I would love it if CL listed the various
options for dealing with ids.: I'd like to keep
the issue open to hear the pros and cons.
PC: I agree with DO.: I have to keep an open
mind for other reasons than DO.: I have some
concerns about wording in NW's proposed text
about where this work should take place. I
think we should make clear that the AC will be
deciding this.
NW: I hear that, but think we should suggest
something they should agree on. We can propose
two different issues.
[Chris]
a) subsetting XML
b) xml:id
[Ian]
NW: I suggest writing up another draft in TAG
space.
[DanC]
quick straw poll on which list to use?
[Ian]
TB: I'd rather this take place on www-tag.
[DanC]
I'm agnostic; light preference for www-tag
[Ian]
CL, PC: One more round on TAG list would be
better.
Action NW: Send another draft to tag@w3.org.
TBL: In an RDF document, there's not a defining
instance of an id. When something occurs in
more than one place, it's considered to be the
same thing.
[Zakim]
TimMIT, you wanted to note that graph-oriented
systems can't use xml's id because there is no
distinction between definition and use. XML
makes the assumption that one occrrence of
... the id is special.
[Ian]
TB: Why can't you have a new spec that defines
a subset?
NW: You could, but if you had a combined
document that only defined a subset, then I
think the people still using DTDs would be
cheated out of that useful body of work. And
that two parallel things going forward would be
confusing.
[Discussion about number of specs.]
TB: I disagree that if you do "grand
unification" you would also have to do "all of
1.1".
CL: There's another way to do this - define a
small version, and base 1.1 on that.
NW: That's what I had in mind.
CL: You include the subset by reference (in the
1.1 draft).
NW: The two points I want to make are (1) I
think that will be a lot of work and (2) I
would be uncomfortable *not* doing it.
[timMIT]
Sounds as though we have 3 useful tasks. 1)
subsetting 2) xml:ids 3) unification of specs
without changing anything else
[Ian]
TB: I am not comfortable with "MUST do all of
1.1." I am fine with two statements (1) big job
and (2) might be problematic if only include
subset.
2.4 namespaceDocument-8
1. namespaceDocument-8
1. Completed action NW 2002/11/18: Take a stab
at indicating pros and cons for the various
RDDL/RDF/Xlink designs arising from TB's RDDL
challenge. See NW summary of proposals.
1. RDDL Proposal from Tim Bray.
2. RDDL Proposal from Chris Wilper
3. RDDL Proposal from TBL
4. RDDL Proposal from Jonathan Borden
5. RDDL Proposal from Micah Dubinko
6. RDDL Proposal from Sandro Hawke
[Ian]
NW: They're all adequate. Just pick one. I
picked Jonathan's proposal.
RF: WHy do we need to pick one?
PC: What's http content negotiation all about?:
Why aren't image formats similar?
TBL: You need dominant image formats.
[Roy]
(i.e.. let the market decide which one
dominates)
[Ian]
PC: I am not sure that having a single format
is the right answer.
[TBray]
I am increasingly convinced that a single
format is desirable
[Roy]
I am increasingly convinced that I don't know
which is better.
[Ian]
TB: We can't say "you MUST use X" but it would
be a benefit to the community to bless one
format. Also, check out Sandro's suggestion....
[DanC]
Conneg and separate URIs are not exclusive! You
can do both.
[timMIT]
Big general discsuusion, old one, pros and
cons.
[Zakim]
TBray, you wanted to say I now like Sandro's
proposal
2.5 Postponed
1. Status of URIEquivalence-15, IRIEverywhere-27.
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. Action MD 2002/11/18: Write up text about
IRIEverywhere-27 for spec writers to include
in their spec.
2. Action CL 2002/11/18: Write up finding for
IRIEverywhere-27 (from TB and TBL, a/b/c), to
include MD's text.
CL: No progress. Update expected 13 Jan.
2. binaryXML-30
1. Action CL 2002/12/02: Write up problem
statement about binary XML; send to www-tag.
3. xlinkScope-23 (5 minutes)
1. Action SW 2002/11/18: Organize a
special-interest teleconf for discussion of
this issue on linking. Pending; see email
from SW (TAG-only).
2. Completed action SW 2002/12/09: Contact the
Hypertext Coordination group, Vincent Quint
chair, as part of organizing linking meeting.
4. fragmentInXML-28 : Use of fragment identifiers in
XML.
2.6 Findings in progress, architecture document
See also: findings.
1. Findings in progress:
1. deepLinking-25
1. Action TB 2002/09/09: Revise "Deep
Linking" in light of 9 Sep minutes.
2. URIEquivalence-15
1. TB's "How to Compare Uniform Resource
Identifiers" draft finding.
TB: I expect to have this done by end of
January.
DC: I expect to review this.
PC: More time required since there are
Microsoft engineers looking at this.
2. 6 Dec 2002 Editor's Draft of Arch Doc (new):
1. Action CL 2002/09/25: Redraft section 3 based
on resolutions of 18 Nov 2002 ftf meeting.
2. Complete review of TBs proposed principles
CP9, CP10 and CP11
_________________________________________________
Stuart Williams for TimBL
Last modified: $Date: 2003/01/07 03:25:55 $
--
Ian Jacobs (ij@w3.org) http://www.w3.org/People/Jacobs
Tel: +1 718 260-9447
Received on Monday, 6 January 2003 22:33:25 UTC