W3C | TAG | Previous:12 Aug | Next: 26 Aug

Minutes from 19 August 2002 TAG teleconference

Nearby: Teleconference details · issues list · www-tag archive

1. Administrative (15min)

  1. Confirm scribe and Chair (SW)
  2. Roll call: DC, TB, NW, SW, PC, RF, IJ. Regrets: CL, DO, TBL
  3. Accepted 12 Aug minutes
  4. Accepted this agenda
  5. Next meeting: 26 Aug. Regrets SW, TBL. NW to Chair.

1.1 Completed actions

  1. Action IJ 2002/08/12: Indicate that issue URIMediaType-9 is not indicated as closed.
  2. Action IJ 2002/0812: Revise arch document to account for URI 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. Done.

1.2 Face-to-face meeting

[Ian]

DC: Feedback from our first public WD.
IJ: I'm likely to be available on Monday before the ftf meeting.
SW: I'm also likely to be available.
PC: Don't know yet.
TB: I will be available a couple of hours on Monday afternoon
PC: I suggest .5 day on outstanding issues we haven't touched on in a while. (prioritized)
[DanC]
spend some time "in quadrant II". 1/2 ;-)
[Ian]
PC: One day on doc, .5 day on various issues.
[DanC]
(QII = important, not urgent)
[Ian]
SW: Any public events we need to prepare for? (e.g., AC meeting in Nov, or tech plenary...?)

2. Technical (60min)

2.1 Review of arch doc comments

On 13 Aug Arch Doc

  1. Architecture document
    1. Completed Action DC 2002/08/12: Ask www-tag for volunteers to work with TAG (and possibly IETF) on HTTP URI stuff; CRISP. [This action supersedes the previous action: Ask IESG when IETF decided not to use HTTP URIs to name protocols.] Sent. In progress.
    2. Action TBL: 2002/07/15: Create a table of URI properties.
    3. Action IJ 2002/07/08: Produce WD of Arch Doc. Harvest from DanC's URI FAQ. Deadline 30 August.
  2. Internet Media Type registration, consistency of use.

See summary of comments from SW.

Writing style

[Ian]

Whether to have principles up front (conclusions first, then justify them), or have the primary document be the slightly fattier form, with principles in a single-page checklist as well.
TB: To the extend that we can dare to do less, we increase our chances of succeeding. While I like the idea of successive elaboration, at the end of the day, I would be really happy just to get the principles right. I would argue for: Statement of principles and supporting examples.
IJ: that sounds like what we have today: Principles and examples.
TB: A couple of places could be trimmed.
PC: Need to agree that we are all talking about the same audience. I agree with TB first: coverage first. I suggest something in the introduction to state clearly who audience is.
DC: We definitely owe w3c WG participants something they can read.
TB: I think that we can all agree to that.
[Agreed]
IJ: I expect to drop context into the document later (not sure what context, but this would be normal).
TB: Less is more in this document.
DC: How testable do we expect the assertions of this document to be?

DC to IJ: Please try both approaches:

  1. Principles up front
  2. Principles in a checklist
TB: Interested by version that is "just the facts" with fuller-bodied version as a separate document.

Deep linking

See email from Len

[DanC]
"do nothing; leave the 'Open: ...'" <- OK by me.
[Ian]
TB: I think the placeholder is fine. When we address the issue, if we choose to say nothing, that'll be fine.
IJ: I think all the issues are in the document as placeholders.
Resolved: Leave the placeholder in place until we address the issue.
[Norm]
I'd be quite happy with Tim's text, actually: http://lists.w3.org/Archives/Public/www-tag/2002Jul/0118.html

Redefining URI terminology

See suggested rewrite from DanC.

[Ian]
SW: I have pushed back against the redefinition of the terms.
TB: Two issues here that stand out:
  1. What are the terms we use?
  2. Range of absolute URI References with frag ids
DC: I think rename(URI Ref, URI) is pleasing, but I can live without. But I like the approach I took in my proposal.
TB to RF: Any news on RFC2396?
RF: The next time I get a free two hours, a lot of things will change. See information about URIs.
SW: I liked DC's material up until the point "To summarize..."
[DanC]
er... "conventional..." more like "standardized"
[Ian]
Proposed:
  1. Stick to existing terminology (URI, URI reference).
  2. Use the term "absolute URI Reference"; semantically consistent with RFC2396. We would like RF to add a BNF term for this.
RF: On range question, I disagree that URI refs with frag ids refer to resources.
Resolved: Stick to existing terminology (URI, URI reference). Use the term "absolute URI Reference"; semantically consistent with RFC2396. We would like RF to add a BNF term for this. Work DC's language into the arch doc.
[Roy]
I meant that I think all important resources should have a URI sans fragment id

Range of absolute URI references with fragment identifiers

[Ian]
TB: I would be sympathetic to people providing fragment-free URIs for important resources. Too fuzzy when you have fragments.: One reason is fragment-within-a-fragment
DC: What about an RDF property or a color?
TB: I can appreciate why it's convenient from impl point of view with fragments. But you do pay a price.
[Zakim]
DanC, you wanted to give up on s/absolute URI reference/URI/, but to advocate the style I used and to ask about the case of a type or a property or a color
[Ian]
DC: So it's ok to you that something be both a document and a color?
RF: GSM gateway, robots on the Web.
DC: These are also documents. You can GET the representation of them.
RF: You have to come up with a rational model why a POST to the document moves the vehicle.
NW: We've had this conversation a lot of times before. Didn't we have consensus (other than with TBL) that HTTP URIs could point to things other than docs. How do we move forward on this?
[Ian]
SW: We have this assertion from TBL that HTTP URIs can only identify documents. But we have lots of evidence of HTTP URIs as namespace URIs.
DC: I have asked TBL, who says that namespaces are documents.
SW: Another counter-example - TAG finding that we encourage IANA to use HTTP URIs to name internet media types.
DC: Yes, that's an interesting one.
[ian_]
IJ: I wonder whether we can pursue the path TB pointed to: You can use URI Refs with frag ids to point to resources; but you pay a price.
SW: If I want to point to part of a resource, need to "promote" the identifier to a full URI.
[DanC]
naming a part of foo#bar isn't the only way to name parts of foo. you can say that blat is part of foo.
[ian_]
IJ: Can I note say that http://www.example.org/#a refers to blah and www.example.org/#b refers to part of that? They don't have to be syntactically related.
RF: I have discomfort of thinking of these things identified by Abs URI Refs with frag ids as first-class objects of the arch document.
TB: Should we just call out the ambiguous status of things with #?
DC: Seems to me that if you're making up some kind of term in a dictionary, you give the dictionary a name and a URI to a term within it.
(same with elements in a namespace, colors in a Pantone set).
SW: I'm concluding that there's a level of comfort calling things you identify with a URI + frag id a "resource"
DC: The substantive issue seems to relate to how to state the arch principle. "All important resources should be identified with a ....? "
RF: I think all important resources should be identified by a URI. But I can't force people.
TB: I'd agree with RF if "SHOULD" is invoked.
[ian_]
TB: I am for "SHOULD" and "URI".
IJ: I am hearing:
  1. MAY use absolute URI reference (with frag) to refer to resources
  2. SHOULD use URI to refer to important resources.
IJ: What's the "difference" that makes URIs for resources better than URI references with frag ids for resources?
[DanC]
Only URIs work with stuff like access control, proxies, redirection.
[ian_]
RF: You can say that "If the only thing you are using the URI for is naming, then there is no difference. It's only when you want to interact with the resource that the difference comes into play. Intermediaries within the architecture can't affect the interpretation of the frag id when accessed."
TB: another reason - since the interpretation of the fragment is decreed to be a function of the media type of the representaiton that you get, you're not 100% sure that you can handle it.
DC: I don't think that the media type affects the meaning of the URI reference.
TB: If there is a frag id, the agent cannot count on retrieving the representation (even if one is available) because correct handling of the frag id is a function of the media type.
DC: If it's without a hash, it's the same thing. RF's distinction cuts both ways.
TB: Maybe we should give up until we can come up with something compelling to say.
IJ: I am interested in the idea that spelling doesn't matter if the only operation is comparison of URI thingies.

Rewrite of section 1.2

See proposal from DanC.

[Discussion of sizes of sets of infinities: aleph, beth, ...]
DC: there are more reals than integers.
RF, SW, TB: Support for DC's language.
DC: Ok to strike the footnote.
NW: I favor striking it as well.
DC: I am not sure how to keep "valid use" in the document. I can live with dropping it but would rather not drop it from the planet.
[Norm]
Ian, I suggest you just leave "Each valid use..." in S1.2 after Dan's text.

Comments from Paul Cotton on CSS

See PC's comments.

[ian_]
Strong support for PC's suggestion.
TB: I suggest we drop the model view controller paradigm. The only embodiment of this theory in its pure form is the java swing toolkit. I think MVC is controversial, not inherently related to Web architecture, and should be excised.
[DanC]
gee... I've seen lots of deployment of MVC. all modern word processors and graphics programs use it, no?
[ian_]
TB: I plan to send this as a written comment.
[TBray]
No, I don't agree that much modern software is really MVC inside; last time I checked popular web browsers aren't.

Other editorial

[PaulC]
Ian: Did you get my editorial comments on the Arch Doc?

IJ: No, not yet.

[ian_]
http://lists.w3.org/Archives/Public/www-tag/2002Aug/0152.html
[25] http://lists.w3.org/Archives/Public/www-tag/2002Aug/0198.html
SW: Following pointer v. GET v. PUT/POST.
RF: We use "dereference' to emphasize that can be PUT or GET.
DC: If you are going to post to something, you don't get the something on your end. The value stored in a pointer is the address of the other thing.
RF: What about redirect?
IJ: I hear RF saying that dereference means "use URI to interact with a representation" and saying "get a representation" is something else.
DC: Let's say "access a resource with a URI" (across put/post/get).
IJ: I hear support for both (a) something that works across put/post/get and also (a) something for the case of GET (e.g., retrieve a representation).
Action SW and IJ: Work on some language for this.
------------------------------------
Remove Childist remark request from Misha Wolf [32].
Resolved: Agreed.
-----------------------------------------------
Request for section on architecting URIs from Steven Livingstone
DC: There is an arch principle that WGs need to know: you can use HTTP URis in a persistent fashion. Some people don't believe this is possible...
PC: Some price to pay (e.g., confusion about date space). There is a non-normative reference in the text to a TBL document.
[DanC]
Nope, no [Cool] in the body of http://www.w3.org/2001/tag/2002/0813-archdoc
[ian_]
Action IJ: Put back [Cool] in persistence section.

2.2 Postponed

  1. httpRange-14: Need to make progress here to advance in Arch Document.

    IJ: We seem to be making progress on the arch doc despite this issue. TB, is your sense this issue could go away?
    TB: No opinion.

  2. RFC3023Charset-21:
    1. Chris sent information to www-tag. What is necessary to close this issue?
  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. See more comments from Martin.
    1. What should a finding look like for this?
  4. xlinkScope-23
    1. Priority of this?
  5. Status of discussions with WSA WG about SOAP/WSDL/GET/Query strings?
  6. augmentedInfoset-22:
  7. 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.
  8. uriMediaType-9: Status of negotiation with IETF? See message from DanC.

2.3 New issues?

Ian Jacobs, for TimBL
Last modified: $Date: 2002/08/20 15:01:34 $