W3C | TAG | Previous:29 Jul | Next: 19 Aug
Minutes of 12 August 2002 TAG teleconference
Nearby: Teleconference details · issues list · www-tag archive
1. Administrative
- Roll call: TBL, SW, DC, PC, RF, TB, IJ. Regrets: DO, CL, NW
- Accepted 29 July minutes
- Accepted this agenda
- Next meeting: 19 Aug. Regrets: PC, DO, TBL (2 weeks). SW to chair on 19
August.
2. Technical
- Architecture document
- Postponed
- 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 conclude 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 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: 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.
On the 9 August draft of the
Architecture Document
- Action IJ 2002/07/08: Produce WD of Arch Doc. Harvest from DanC's URI FAQ.
Deadline 30 August
- [Ian]
- IJ: I made available (quietly) a new draft, but this is not related
to the action item (due at the end of 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 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]
- 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 originally called a document address.
- [timmit]
- Yes - problem is: The "reference" bit is means "strng as actually
occurs 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 http://example/aPath/myDoc.html#section2
a URI?
- [ian_]
- TB: This is a URI Reference, by definition.
- [DanCon]
- does http://example/aPath/myDoc.html#section2
refer to a resource?
- [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 does 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 http://example/aPath/myDoc.html#section2
refers to, say, an item, rather than a resources.
- [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 RFC2396.
- [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:
- Define URI to be what we want.
- 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.
- httpRange-14: Need to make
progress here to advance in Arch Document.
- Internet Media Type registration, consistency of
use.
- RFC3023Charset-21:
- Chris sent information
to www-tag. What is necessary to close this issue?
- 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.
- What should a finding look like for this?
- Status of discussions with WSA WG about SOAP/WSDL/GET/Query strings?
- xlinkScope-23
- Priority of this?
- augmentedInfoset-22:
- 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.
- deepLinking-25
- Action PC 2002/07/22: Ask Henrik Frystyk Nielsen to provide us with
a precis of the ruling. Done: awaiting reply from Henrik.
- uriMediaType-9:
Status of negotiation with IETF? See message
from DanC.
- Action TBL: Get a reply from the IETF on the TAG finding.
2.3 New issues?
Ian Jacobs, for TimBL
Last modified: $Date: 2002/08/15 13:47:06 $