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
- Roll call: NW (Chair), IJ (Scribe), DC, DO, TB, RF. Regrets: TBL, SW,
PC. Absent: CL
- Accepted 19 Aug minutes
- Accepted this agenda
- Next meeting: 30 August. 2 September meeting canceled.
- Action IJ 2002/08/19: Put back [Cool] in persistence section of Arch
document. Remove comment about children and URIs.
- Action SW and IJ 2002/08/19: Work on some language regarding using URI
to interact v. specifically to GET. Though not done with SW and IJ, there
is language to this effect in the 26 August arch document.
2. Technical
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:
- URIs have varying degrees of context-sensitivity
- 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:
- Allow new text until Weds 12pm ET this week.
- IJ will produce new draft for TAG by Weds afternoon ET.
- The TAG can comment until Thursday evening ET.
- IJ will delete new portions about which there are objections.
- 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:
- 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.
- Action TBL: 2002/07/15: Create a table of URI properties.
- Action IJ 2002/07/08: Produce WD of Arch Doc. Harvest from DanC's URI FAQ.
Deadline 30 August.
- 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).
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.
See Request
from Tim Bray to decide issue augmentedInfoset-22 (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.
[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.
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.
- httpRange-14: Need to make
progress here to advance in Arch Document.
- Internet Media Type registration, consistency of
use.
- deepLinking-25
- uriMediaType-9:
Status of negotiation with IETF? See message
from DanC.
- Action TBL: Get a reply from the IETF on the TAG finding.
- 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?
Ian Jacobs, for TimBL
Last modified: $Date: 2002/08/26 22:24:47 $