- From: Ian B. Jacobs <ij@w3.org>
- Date: Mon, 12 Aug 2002 17:28:56 -0400
- To: www-tag@w3.org
Hello,
Minutes from the 12 August TAG teleconference are
available as HTML and as text below.
- Ian
[1] http://www.w3.org/2002/08/12-tag-summary
--
Ian Jacobs (ij@w3.org) http://www.w3.org/People/Jacobs
Tel: +1 718 260-9447
========================================================
[1]W3C [2]| TAG | Previous:[3]29 Jul | Next: 19 Aug
[1] http://www.w3.org/
[2] http://www.w3.org/2001/tag/
[3] http://www.w3.org/2002/07/29-tag-summary
Minutes of 12 August 2002 TAG teleconference
Nearby: [4]Teleconference details · [5]issues list · [6]www-tag
archive
[4] http://www.w3.org/2001/tag/group/#remote
[5] http://www.w3.org/2001/tag/ilist
[6] http://lists.w3.org/Archives/Public/www-tag/
1. Administrative
1. Roll call: TBL, SW, DC, PC, RF, TB, IJ. Regrets: DO, CL, NW
2. Accepted [7]29 July minutes
3. Accepted this [8]agenda
4. Next meeting: 19 Aug. Regrets: PC, DO, TBL (2 weeks). SW to
chair
on 19 August.
[7] http://www.w3.org/2002/07/29-tag-summary
[8] http://www.w3.org/2002/08/12-tag
2. Technical
1. [9]Architecture document
2. [10]Postponed
2.1 Architecture Document
* Action TBL: 2002/07/15: Create a table of URI properties. Not
done.
* Action DC 2002/07/08: Ask IESG when IETF decided not to use HTTP
URis to name protocols.
[Ian]
DC: I have not asked the IESG yet. Not awaiting reply. I was
going to ask the IESG. There's an ICANN PSO that W3C is party
to (through Martin and Danny). I asked whether that would
be a
conduit. I got a response from Martin. But the ICANN PSO may
not be useful here. I am starting to include that the
straightforward way to ask the IETF a question is through an
internet draft.
TB: Wouldn't have to be long. Could just reaffirm that (1)
important things should be part of the web (2) should have
dereferenceable URIs (3) I* should host these things.
DC: Could publish finding [11]Mapping between URIs and
Internet
Media Types as an Internet Draft. It reads:
"The TAG requests that IANA, the authority which
adminsters the
registry of Internet media types, be committed to providing
persistent and dereferencable URIs that return a document
containing human ..." I would rather someone volunteer to
do an
internet draft instead of me asking the IESG. Issue is
what to
do with incoming mail.
RF: What about "crisp" mailing list: [12]Cross Registry
Information Service Protocol (crisp)?
TBL: So the action could be phrased in response to that.
TB: I think we should not let this issue fade away. We should
do whatever it takes so that the IETF knows we think this
belongs in Web space.
TBL: Slight revision: (1) Put on the Web (2) Use HTTP to
do so.
[DC makes a comment about how much time he thinks this will
take: about 4 months.]
DC: The people here think that LDAP is the way to solve the
problem. In general, the IETF is pretty happy with the idea
that every new thing needs a new protocol. "If you're not
serving up hypertext docs, you need a new port number, a new
way to marshall arguments, etc." I agree with TB that this is
worth doing, but it's a big hill. I think the IETF doesn't
believe that anything that does GET should use HTTP.
TBL: So how do we proceed?
DC: Maybe I can ask for volunteers on www-tag.
TBL, TB: Good idea.
TBL: Is the CRISP list the appropriate forum?
RF: Don't know. I haven't read; don't know how open they
are to
new ideas. You can send to the applications area.
DC: This was a proposed WG when RF first notified us. Now
it's
a WG....
Action DC: Ask www-tag for volunteers to work with TAG (and
possibly IETF) on HTTP URI stuff; CRISP
Action IJ: Indicate that issue URIMediaType-9 is not
indicated
as closed.
[11] http://www.w3.org/2001/tag/2002/01-uriMediaType-9
[12] http://www.ietf.org/html.charters/crisp-charter.html
On the [13]9 August draft of the Architecture Document
[13] http://www.w3.org/2001/tag/2002/0805-archdoc
* Action IJ 2002/07/08: Produce WD of Arch Doc. Harvest from
[14]DanC's URI FAQ. Deadline 30 August
[14] http://www.w3.org/2001/tag/doc/ures14.html
[Ian]
IJ: I made available (quietly) a new draft, but this is not
related to the action item (due at the end fo the month).
Making progress, but I have a fair amount to do.
TB: First principle in arch document should be "important
things should have URIs".
[TBray]
first principle in arch doc *is* Use URIs: All important
resources SHOULD be identified by a URI.
[Ian]
DC: The table could come in handy here: If you have a
protocol
that p(short-string) -> document, you should use existing
stuff. Create a table of patterns that we use to solve
problems.
[DanCon]
is the square-boxy thingy supposed to be a definition or
something? "Valid use of URI" is described, but not
defined, by
that box in chapter 1
[Ian]
IJ: Things in boxes are principles. I still have stuff to
do in
this document.
TB: I think we can usefully ask for input from people before
publishing first public WD.
IJ: I need to do things like link from open issues to issues
list, etc.
[DanCon]
"The representations of a resource". hmm..
[Ian]
TB: Also,
IJ: If you can think of top 3 things where *most people* have
been confused.
DC: Don't forget to include where there has been consensus!
TB: Not sure that httpRange-14 has a big impact on the
document.
TBL: It did in a past version. Involved s/resource/document.
TB: I think that those comments would be out of sync with
current draft.
[DanCon]
"All important resources SHOULD be identified by a URI."
hmm...
SHOULD is for agents... which agent SHOULD do something here?
[Ian]
IJ: Please note that document starts with generalities,
and URI
references are touched on up front, and then expanded on
later.
DC: One approach is to say "URIs include things with #
marks".
But it's hard to refer to RFC2396 and do that.
RF: The basic problem with treating frag is as being
equivalent
with URIs is that you can't do certain things.
(e.g., have a third-party monitor).
DC: I rebutted that argument before. Doesn't have to do with
whether there's a "#".
RF: Has to do with whether it's a resource.
DC: I don't believe so. First box should read
"...identified by
an absolute URI reference"
TBL: Remove "absolute"; relative is a shortcut. "All
important
resources should have an absolute URI reference."
[DanCon]
[15]http://www.w3.org/2001/tag/doc/ures14.html
[15] http://www.w3.org/2001/tag/doc/ures14.html
[Ian]
TB: Make sure that people understand that the abs reference
must exist; you may use relative refs operationally.
[DanCon]
"each valid use of a URI reference unambiguously
identifies one
resource."
[Ian]
DC: I would need to see something up front (in
organizatoin of
current document) that says "I'm lying to you." (Since
URI refs
not mentioned yet.)
[DanCon]
"A resource is part of the Web when it is identified by a
URI."
<- hmm... this suggests resources that haven't been named
with
URIs aren't part of the web.
[TBray]
Indeed they're not
[DanCon]
?
[ian_]
TB: We need more carefully written thoughtful opinions before
we can discuss this.
[timmit]
(I wonder about Universal Item Identifier III = uriref with a
new name)
[Roy]
"URI Reference" is a protocol element containing a
reference to
a resource.
If we want a new name for URI with fragment, I welcome
suggestions.
It was originall called a document address.
[timmit]
Yes - problem is: The "reference" bit is means "strng as
actually occirs in referring document' and also "thing with a
hash". Overloading.
[ian_]
IJ: I suspect it's possible to fix URI -> URI Ref up
front and
still start with generalities, and attack specifics of
URI refs
later in the doc.
[DanCon]
from my FAQ: Is
[16]http://example/aPath/myDoc.html#section2 a
URI?
[16] http://example/aPath/myDoc.html#section2
[ian_]
TB: This is a URI Reference, by definition.
[DanCon]
does [17]http://example/aPath/myDoc.html#section2 refer to a
resource?
[17] http://example/aPath/myDoc.html#section2
[ian_]
IJ: I thought the model was: URIs refer to resources, URI
Refs
do if the format allows.
RF: The HTTP spec in particular needs specific
requirements on
the URI syntax that the frag id doesn't not fall within. It
doesn't matter to me if we say either:
a) URI -> Rsource, frag is indirect.
b) URIs, URI refs- > Resources.
TBL: RDF has used the word "resource" for an item. Might be
easier to change in RDF world.
[timmit]
rdf:Resource = new:Item
[DanCon]
timbl: we could say that
[18]http://example/aPath/myDoc.html#section2 refers to,
say, an
item, rather than a resources.
[18] http://example/aPath/myDoc.html#section2
[ian_]
Proposal: Resources (URI) and Items (URI References).
[timmit]
../foo is not a URI.
[ian_]
TB: Everything that is important should have an absolute URI
reference.
[timmit]
Tim: everything should be id'd by an UII.
[ian_]
TB: "Absolute URI Reference"
[Roy]
TB said Everything should be identifiable by a URI reference.
[ian_]
DC: "Absolute URI Reference" is not in [19]RFC2396.
[19] http://www.ietf.org/rfc/rfc2396.txt
[timmit]
URI reference is like qname - a way to refer to a URI
UII reference is like qname - a way to refer to a UII
[DanCon]
struggling with terminology... that's what this group is here
for, no?
[ian_]
TB Summarizing:
a) Absolute URI ref for everything (includes resources and
items)
b) OPerationally may have relative URI ref.
[Roy]
absURI#frag == "indirect resource"?
[timmit]
Non-relative URI reference == new: UII.
[ian_]
DC: I think we need a term for X = absURI [# fragid]
IJ: I can call for suggestions on that term.
TB: In RFC2396, terms, call it a non-relative URI reference.
[Roy]
On uri@w3.org, please.
[ian_]
RF: I'm perfectly open to the notion of saying the URI
includes
"#frag". I keep getting shot down when I've tried in the past
(since W3C not involved in the discussion). I don't want
another IRI. I don't want more than one definition of a
protocol element. I don't want developers to have to read 14
specs. I am open to new terms; need to do this this week.
[DanCon]
Roy, I sent a request for a standardized term for
'absolute URI
reference' several years ago.
[ian_]
IJ: What is the significant difference between a resource and
an item.
[Roy]
DC, right -- that's already on the issue list.
[DanCon]
hmm... why not GET a mailbox to get its state?
[ian_]
TB: I am for a new term. Can we argue a little about the
term?
What about "resource" and "resource component". You need a
resource to get a component.
DC: the thing you called component is the more general term.
[DanCon]
resource and protocol resource... I could go with that.
[ian_]
DC: I would rather use "resource" for with frag id, and
create
another term for the special case (no frag id)
RF: A resource is something that you can return to multiple
times. The proposed meaning is inconsistent with my model.
DC: Is the number "2" a resource?
RF: Yes. If you have an identifier for it as a resource, you
need to be able to return to it.
TB: What does the "#" have to do with it?
RF: These things are "resourceful", but I'm not sure we can
define a consistent set of specs if 1/2 the world says with
frag refers to a resource and without does not.
TB: I would take the view that a rseource is anything
that has
identify (2396) and there is a special class identified by
things identified by URIs with no fragments.
DC: "Protocol resource" works for me.
TB: We are saying that both URIs and URI references identify
resources.
IJ: I hear URIs pointing to a thing of class=resource,
subclass="protocol resource." What not "network resource"?
TBL: UUIDs and similar are not networked necessarily.
IJ: Why would I use one class or the other?
DC: I don't know; I"d have to look at the spec.
[DanCon]
"There's a universe of resources; important ones should be
identified by absolute URI references" <- I can buy that.
[Roy]
identified --> identifiable by URI references.
[ian_]
Why identifiable?
[Roy]
because then it is okay to be relative
[ian_]
Ok.
[DanCon]
?
hmm... ok.
[TBray]
2 has lots of representations :)
[ian_]
TBL: Outside of HTTP, no ambiguity between URI ref/URI
anyway.
RF: It's easier for me if I don't have to call the things I
identify with URI refs "resources." So: "All important
resources should have identifiers."
TBL: What we want is to define URI to be (1) frag id optional
and is (2) not relative. And URI ref would be URI | relative
thingy.
Proposal:
1. Define URI to be what we want.
2. Say we hope to get 2396 changed
[DanCon]
old:AbsoluteURIReference = new:URI
old:URIReference = new:URIReference
[ian_]
DC: Specs that were careful put "URI reference" in their
specs.
We're not changing that term.
RF: I think the HTTP spec was careful to say Absolute URI.
Action IJ: Revise document to account for this proposal; send
out announcement to www-tag in 24 hours. Make it clear
that we
may not respond to all feedback. Say that we are not
committing
to respond, but not to worry; open action items won't just be
dropped.
2.2 Postponed
1. [20]httpRange-14: Need to make progress here to advance in Arch
Document.
2. [21]Internet Media Type registration, consistency of use.
+ Action PC [22]2002/07/08: Propose alternative cautionary
wording for finding regarding IANA registration. Refer to
"[23]How to Register a Media Type with IANA (for the IETF
tree) ". Pending.
3. RFC3023Charset-21:
1. Chris sent [24]information to www-tag. What is necessary to
close this issue?
4. Status of [25]URIEquivalence-15. Relation to Character Model of
the Web (chapter 4)? See text from TimBL on [26]URI
canonicalization and [27]email from Martin in particular.
See more
[28]comments from Martin.
1. What should a finding look like for this?
5. 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 [29]discussions from 24 Jun TAG teleconf.
6. [30]xlinkScope-23
1. Priority of this?
7. [31]augmentedInfoset-22:
+ [32]Request from Tim Bray to decide this issue
(disposition =
closed). Pushback from Simon St. Laurent.
+ 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. DanC has sent email; awaiting reply
from XML
Scheme WG.
8. [33]deepLinking-25
1. Action PC 2002/07/22: Ask Henrik Frystyk Nielsen to provide
us with a precis of the ruling. Done: awaiting reply from
Henrik.
9. [34]uriMediaType-9: Status of negotiation with IETF? See
[35]message from DanC.
+ Action TBL: Get a reply from the IETF on the TAG finding.
[20] http://www.w3.org/2001/tag/ilist#httpRange-14
[21] http://www.w3.org/2001/tag/2002/0129-mime
[22] http://www.w3.org/2002/07/08-tag-summary#media-types
[23] http://www.w3.org/2002/06/registering-mediatype
[24] http://lists.w3.org/Archives/Public/www-tag/2002Jul/0323.html
[25] http://www.w3.org/2001/tag/ilist#URIEquivalence-15
[26] http://www.w3.org/DesignIssues/Axioms.html#canonicalization
[27] http://lists.w3.org/Archives/Public/www-tag/2002May/0161
[28] http://lists.w3.org/Archives/Public/www-tag/2002Jul/0275.html
[29] http://www.w3.org/2002/06/24-tag-summary.html#wsa-get
[30] http://www.w3.org/2001/tag/ilist#xlinkScope-23
[31] http://www.w3.org/2001/tag/ilist#augmentedInfoset-22
[32] http://lists.w3.org/Archives/Public/www-tag/2002Jul/0159.html
[33] http://www.w3.org/2001/tag/ilist.html#deepLinking-25
[34] http://www.w3.org/2001/tag/ilist#uriMediaType-9
[35] http://lists.w3.org/Archives/Member/tag/2002Jun/0095.html
2.3 New issues?
_________________________________________________________________
Ian Jacobs, for TimBL
Last modified: $Date: 2002/08/12 21:27:16 $
Received on Monday, 12 August 2002 17:32:13 UTC