W3C | TAG | Previous:19 Aug | Next: 30 Aug

Minutes of 26 August 2002 TAG teleconference

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

1. Administrative

  1. Roll call: NW (Chair), IJ (Scribe), DC, DO, TB, RF. Regrets: TBL, SW, PC. Absent: CL
  2. Accepted 19 Aug minutes
  3. Accepted this agenda
  4. Next meeting: 30 August. 2 September meeting canceled.

1.2 Completed actions

2. Technical

2.1 Architecture document

Comments on 26 August draft. See, in particular, comments from TB. IJ will fix typos listed in that email.

[Ian]

Resolved: Move following to 1.3 (limits of the doc): " Some of these principles may conflict with current practice, and so education and outreach will be required to improve on that practice. Other principles may fill in gaps in published specifications or may call attention to known weaknesses in those specifications."

TB: About "The FTP scheme is for ftp file names (including DNS domain names)", I suggest instead "FTP-accessible data".

DC: I think mostly for file names. I'd rather keep the part people are familiar with.
[No change]

TB: I think we need a paragraph saying that RFC2396 defines something called a URI Reference. I think we need to ack the term "URI reference" just before 2.1.
Resolved: Accept proposal from TB to ack the term "URI reference."

TB: "2.1 para beginning "Some resources do not have URIs". First of all I don't agree, second what's the practical effect even if it's true, third
denumerable means you *can't* give one to every real number. Lose the paragraph, it adds no value"
DC: Maybe a footnote.
RF: I don't believe that URIs are equivalent to integer numbers; they are equivalent to real numbers.
TB: The space of URIs is countable.
DC: See Of Infinite Sets in "A Crash Course in the Mathematics".
Resolved: Move "Some resources do not have URIs. URIs are denumerable, which means there are enough to give one to every real number without collisions, for example." to footnote.

Action IJ and NW: Work on this footnote text.

Propose to delete "Open Say something here à la what Tim Bray said: "Designers SHOULD NOT build a world of resources that cannot be identified by URI."?"
TB: I retract comment that some interactions not through representations.
RF: You POST and PUT through representations.
DC: Not clear that a POST does.
RF: There's a representation of the information you're sending. I didn't say representation of resource, but representation of a form (for example). I'm comfortable with "One interacts with a resource through representations of the resource. But there's more to it than that (e.g., control data in a request).
[No change for now]
TB: Propose to delete " A representation may be full fidelity, i.e. a complete description, or it may be partial, i.e. describes some aspect of the resource. "
IJ: I think there may be a place for something like this regarding fragments.

No clear action; IJ may delete current text.

TB: We haven't defined what a media type is. Are you guaranteed to know what it is?
TB: "2.2.1, 1st para, last sentence. Need introductory words in that a representation of a resource is often (usually? always?) accompanied by
supplementary information defined per MIME [reference] called its media-type, and then proceed as written."
TB: s/recursive/successive application of specifications.
NW: Yes, "successive"

Resolved: Change "recursive" to "successive".

[DanC]
I'm no longer following at speed; I don't mind Tim Bray and Ian going over these comments like this, but please don't let the record indicate that I've endorsed all these changes.
[Ian]
IJ: Did I miss anything in the example in 2.2.1?
TB: Seemed ok.

TB: The following sentence needs a lot of work "Each valid use of an absolute URI reference unambiguously identifies one resource."
TB: "following all the other relevant protocol specifications" is underspecified.
DC: Simplest to say "Each absolute URI reference unambiguously identifies one resource."
DC, TB: Yes.
Resolved: Change that principle (remove "valid") to "Each absolute URI reference unambiguously identifies one resource."

2.3.1. Absolute URI references and context-sensitivity

TB: I think this text is clearly wrong. I think publishing "file:/etc/hosts" on the Web is clearly wrong.
RF: Why is that?
TB: You could make the arg that the resource is the list of hosts on your computer.
DC: I think our arch doc should answer this question.
RF: Roy has a use case (documentation from Apple). Use the news URL as an example (e.g., that points to a group); it doesn't refer to the group in the universe of net news, but the group as viewed by your news server.
DC: I disagree. If you publish a news URI in the public Internet, you should expect it to be used in various contexts.
RF: Not all newsgroups are global.
TB:
  1. URIs have varying degrees of context-sensitivity
  2. You need to think carefully about the degree of context-sensitivity when you publish a URI.

IJ: Then add "3. An absolute URI reference SHOULD denote the same resource or concept independent of the context(s) in which the identifier is used.

RF: The principle is that they should always refer to the same resource.
Action IJ: Tweak this text to reflect TB and RF comments.
Resolved. Move "Open: issue deepLinking-25: What to say in defense of principle that deep linking is not an illegal act?" to 2.2
[DanC]
[overall, from the level of TimBray's comments, even though I haven't read the 19Aug draft carefully, I gather we've reached the 'make it a /TR/ WD' point]
[Ian]
TB: 3.2-3.5 The MVC paradigm is a currently-fashionable way of thinking about UI software engineering. I happen to think it's highly overrated
and unproven in practice, but that's not the point, the point is that the architecture of the Web doesn't depend on it in the slightest, so it
has no place in this document. The Web Arch does not depend on the MVC in any way. Delete it.
RF: How about separation of content and presentation?
TB: I agree with that. A statement that "To the extend you can, you win when you separate rendering/style from content."
DO: Is content v. presentation specific to Web arch?
TB: I think we need this as a web arch principle. Don't be absolute in separation of content/presentation. That's an ideal. See my post on www-tag on this topic.
DC: Content v. Presentation may not be specific to Web, but it's certainly what WGs should be thinking about.
NW: I am favorable to a principle about presentation v. structure.
[Roy]
BTW, I delete all messages cross-posted to other www mailing lists without reading.
[Ian]
Resolved: Leave MVC for now. There is some sentiment that this should be deleted. Need to hear from CL.
IJ: Is this enough to publish as a first public WD?
DC: I think so.
TB: I think it's good enough (with some more editorial polishing)
DO: I can work with IJ this week to incorporate more REST material.
TB: What publication schedule logistics are we talking about?
[DanC]
DaveO, is the text on REST handy somewhere?

DO: Short version. Long version.

[ian_]
TB: I would support publishing as is with a week's worth of editorial polishing.
IJ Proposal for this week:
  1. Allow new text until Weds 12pm ET this week.
  2. IJ will produce new draft for TAG by Weds afternoon ET.
  3. The TAG can comment until Thursday evening ET.
  4. IJ will delete new portions about which there are objections.
  5. IJ will request publication as first public WD on Friday.
RF: In my opinion, this draft describes about 20% of Web arch.
DC: Yes, somewhere in that ballpark.
DC: Can the chair be in the critical path on the decision to publish?
NW: I will agree to stand in the critical path.
Action DC: Get another w3m member to approve short name (since first public WD): webarch
Action IJ: Talk to Janet about press release issue.
Resolved: Next meeting meeting Friday 30 Aug at 3pm ET. Will attend: DC, DO, NW, TB, IJ. Probable regrets from RF. No meeting 2 September. Following meeting 9 September.

Open actions:

  1. 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. Awaiting reply.
  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.2 RFC3023Charset-21

  1. Chris sent information to www-tag. What is necessary to close issue RFC3023Charset-21?

Action IJ: Work CL language into "TAG Finding: Internet Media Type registration, consistency of use". Ping PC to let him know (since he has some text to change as well).

2.3xlinkScope-23

What is the priority of xlinkScope-23?

[ian_]

TB: Becoming an issue since HTML WG talking about an hlink attrib (is this correct?) even though xlink:href available.
NW: Related - what's the right way to do xlink? with xlink:href or what HTML WG wants to do?
TB: What are the conditions under which xlink should be used? Should we define? Should we enforce? SVG did, SMIL didn't, HTML getting ready not to.
DC: When you point from one point of an svg doc to another, do you point to an element or to the circle it describes?
[Zakim]
DanC, you wanted to mention the SVG XLink issue that I saw, via Prescod: pointing to circles vs pointing to elements that describe circles
[ian_]
NW: I think that DC's issue is new. What is the priority of this issue?
TB: High priority as soon as hlink gets published?: Other rec track docs making the choice about how to implement linking primitives?
IJ: See also theCSS3 hyperlinking spec.
NW, TB: Yes, this is part of the same issue.
DO: I'm not convinced this is high-priority. XLink hasn't thrived; it seems that there are more important issues we could be working on.
DC: But it costs W3C a lot to wonder whether to use XLink.
NW: Should we try to do something before hlink draft made public?
TB: In current XHTML 2.0, proposal to have an href attribute on every element (in the body).
[NW and TB expect to talk about this offline.]
NW: Proposal is that publication of the hlink spec is a gating factor; no further action until that's published.

2.4 augmentedInfoset-22

See Request from Tim Bray to decide issue augmentedInfoset-22 (disposition = closed). Pushback from Simon St. Laurent.

  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. DanC has sent email; awaiting reply from XML Scheme WG.

[ian_]

DC: I didn't get a reply saying "We're confused."
TB: Did PSVI API get into the DOM charter?
IJ: Yes, from 3.2 Out of scope: "post-schema-validation infoset (PSVI), An object model for accessing and modifying the PSVI."
TB: So no group within W3C is mandated (at this time) to do further work on describing the PSVI.
DC: The Schema WG is doing a 1.1 version of the spec that certainly talks about the PSVI.
TB: I learned that while there are linkages between xquery and xml schema, they are non-normative; you can implement xquery with other schema languages; so I don't see an arch issue at the moment. I submitted a large comment to the xquery process that there does remain too much intermingling with xml schema that could easily go away. If they tell me to go away, I will come back to the TAG.
DC: I've also had the query designers say "It's that way in xml schema, so we have to do it that way."
TB: I will reraise as an arch issue if unnecessary linkage from query to schema remains.
Resolved: Close augmentedInfoset-22 as phrased. We may have to reopen it at some point.
Action IJ: Update issues list.

2.5 New issue: contentPresentation-26

See, in particular, email from Sean Palmer on separation of content and presentation.

[ian_]

DC: It would be sufficient for me to say "See WAI for information about separation of content / presentation"
TB: Seems like more of the same of what I posted earlier. I suggest we raise a formal issue.
[Norm]
Issue: structureStyle-26?
No, structurePresentation is probably better
[ian_]
structurePresentation-26 ok by me.
[DanC]
google seems to know it as "Separation of form and content"
[Roy]
Day Software's marketing line: "Everything is Content" ;-)
[Norm]
contentPresentation-26
[ian_]
Resolved: Accept issue contentPresentation-26.
Action IJ: Announce issue. Point to TB's text as draft of finding.

Another issue: Use of frags in SVG v. in XML

RF: Hearsay that SVG refers to an object, not an element.
NW: frag id meaning is determined by media type.
RF: I like thinking of element as representation and object as resource.

Action DC: Describe this issue in more detail for the TAG.

Postponed

  1. httpRange-14: Need to make progress here to advance in Arch Document.
  2. Internet Media Type registration, consistency of use.
  3. deepLinking-25
  4. uriMediaType-9: Status of negotiation with IETF? See message from DanC.
  5. 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?
  6. Status of discussions with WSA WG about SOAP/WSDL/GET/Query strings?
Ian Jacobs, for TimBL
Last modified: $Date: 2002/08/26 22:24:47 $