W3C | TAG | Previous: 15 Sep teleconf | Next: 6-8 Oct 2003 ftf meeting

Minutes of 29 September 2003 TAG teleconference

Nearby: IRC log | Teleconference details · issues list (handling new issues)· www-tag archive

1. Administrative

  1. Roll call: SW (Chair), TBL, DC, TB, NW, DO, RF, PC, IJ (Scribe). Regrets: CL.
  2. Accepted the minutes of the 15 Sep teleconf
  3. Accept this agenda
  4. Next meeting: 6-8 Oct ftf meeting in Bristol

1.1 TAG participation in Tech Plenary 2004 (1-5 March 2004, France)

Pros: Interaction with other groups, welcome new TAG participants. Cons: Competing meeetings.

  1. There was clear support for some sort of TAG involvement at the Tech Plenary.
  2. There was some support, but also some opposition to the TAG organizing a ftf meeting during that week due to conflicting schedules.
[Ian]
SW: Should we meet? Should we interact with other groups?
DC: Yes, please, let's meet.
DO: We could meet with WSDL WG to talk about issue 37
[DanC]
meeting with WSDL folks seems cool.
[Ian]
DO: Yes, let's meet too.
PC: I'm against meeting then. I'll be busy for at least two days since Chair. One of my groups may even meet on the weekend. Also lots of last call docs will be around; likely to be heavily booked.
NW: I'm also overbooked during that time.
[DaveO]
what is our quorum for meeting?
[Ian]
PC: I'd prefer to do what we did last year - to meet at an alternate site before the TP so that people running for election could either be notified during the ballot period when the TAG would be meeting.
[DanC]
I prefer to have consensus to meet. I'd rather not meet over anybody's objection Regrets are one thing. objections are another.
[Ian]
If no TAG teleconf, who won't come to France: TB
Who would be at risk: DO, SW
SW: Then I will let TP organizers know that the TAG does not expect to hold a ftf meeting during that time. However, I'd like to discuss (over the next couple of weeks) what the TAG's contributions could be to the tech plenary day.
[Ian]
[PaulC shows draft agenda of when some groups are scheduled to meet]

DO: I would much rather meet in France with a subset of the TAG (large majority) than to have more trips.

[Norm]
For the record, I don't object to meeting in Cannes. It'll be awkward if we do, but that's fair.
[Ian]
PC: I'd like to encourage the TAG to participate in the organization of the tech plenary itself. I won't be on the organization committee for the TP this year.
NW: I don't object to TAG meeting ftf during that week. But I'm booked solid for now.
[DaveO]
One of the reasons I wanted to meet was because WSDL will be there and we have an issue that would probably be helped by meeting together for a few hours
[Ian]
SW: I think last year more people had more conflicting meeting schedules last year.
RF: This would be the first meeting after the election, right?
SW: Yes.
RF: The idea was to have departing participants also participate in transitional meeting.
SW: I therefore plan to set expectations that we'd like to meet, but some hurdles.
PC: We can postpone until our ftf meeting...

1.2 TAG update to AC for Nov 2003 AC meeting

See previous highlights (Member-only).

Action SW: Draft summary based on monthly reports for TAG.

1.3 Bristol FTF Agenda

  1. Primarily focused on Arch Doc, TAG findings.
  2. 9h - 17h M, T. (Not sure for W).
  3. Meeting page

[Ian]

SW: I've not yet done a detailed agenda page. But the meeting will focus on what's required to go to last call. If we get done early enough, we'll work on findings and have time to do todos.
TBL: I hope to be able to join remotely for part of the meeting.
SW: We expect to have audio; I'll check about video this week.
TBL: I'd be willing to visit an HP facility in Cambridge (MA).
[DC has sent regrets]
[paulc]
Thanks to SW for all the meeting logistical arrangements.
[Zakim]
DanC, you wanted to ask where issue namespaceDocument-8 is w.r.t. critical-path for last call and ftf agenda
[Ian]
DC: Was namespace-8 critical path for last call?
TBray: PC is creating finding + sound bite for web arch.
DC: If I can't read materials now, I may argue for not making any decisions on this issue at the face-to-face meeting. My position on issue 8 is that if we do nothing, that's acceptable. There are a lot of somethings that are not ok to me. If we have some spec that doesn't have a clear mapping to RDF, that would be a step backward.

SW: Look forward to seeing those in England next week.

2. Technical

2.1 Architecture Document

IJ presented some of the bigger changes in the 26 Sep 2003 Editor's Draft. Then the TAG walked through the review comments about which the editor had questions.

[Ian]

SW: Can we approve publication of 26 Sep 2003 Editor's Draft (with today's modifications) as a TR page draft?
[TBray]
grr you don't need both quotes and <code> for URIs in stories
[DanC]
quite, TBray
[Ian]
---
Abstract rewrite
DC: Abstract too long, but nothing critical IMO.
TBray: I'm ok with the abstract (just a couple of stylistic nits)
[DanC]
abstract is too long for my tastes, but I don't see anything technically incorrect
[TBray]
words "to be" after the colon in 3rd para of abstract are grammatically strained, will suggest something smoother
[Ian]
IJ: I think people would like something more concrete about what info space and info system are.
DC: Though I used to not care between info space and info system, I have a mild preference for talking about info space over info system.
TBL: I think we're going to have to make a bigger distinction between HTTP Web and other systems.
[Ian]
IJ: #1 in review comments is closed I think.
#2: SW - I think that this is a linguistic misunderstanding, should be "per URI scheme"
[TBray]
The endnote is wrong
[Ian]
DC: TOo much detail - "The browser uses its configuration2 to determine how to locate the identified information, which might be via a cache of prior retrieval actions, by contacting an intermediary (e.g., a proxy server), or by direct access to the server identified by the URI."
SW: I propose to delete footnote 2.
TBray: yes.
DC: No need to talk about browser config in the intro.
RF: I'm ok with not talking about browser config in the intro. I don't want to give the impression that the browser makes some decisions, dont' just look at URI spec (e.g., can look at cache).
[DanC]
hmm... yeah... where to talk about browser config and caches? not the intro, but ... hmm.
[Ian]
SW: The right place for this is in the interactions section. The expansion should be in that section.
DC: Sounds plausible.
RF: Sure.
DC: I don't want to queue up a bunch of stuff before publishing.
#3) Proposed to add reference to RFC2396 in endnote 3.
#4) Cause/effect backwards in describing "link".
[Stuart]
http://lists.w3.org/Archives/Public/www-tag/2003Sep/0128.html
[Ian]
"When a representation of one resource refers to another resource with a URI, a link is formed between the two resources."
SW: That suggests that the presence of a reference that causes the link to form, as opposed to "There exists a link, therefore there's a URI ref in a representation."
RF: I agree with Stuart. But there's an issue if you have several representations, some of which have links and some of which don't. I don't believe strongly in either view.
TBray: I'm much happier saying that the link is formed by presence of URI ref.
TBL: Rather : "When there is a URI ref in a representation, we often call that a link."
[DaveO]
I'm happy with SW's or TBL's wording. I like the coupling of links with representations rather than resources.
[Ian]
TBL: In the use of the Web for global hypertext, the use of a URI ref in a representation is called a link.
DC: So this shouldn't be introduced in this section...
TBL: I'm ok to start off with talking about most popular case rather than an abstration.
DC: You don't get network effects without any links.
RF: The link is one directional, but the relationship is bi-directional.
[DanC]
changing "formed" to "represented" might help
[TBray]
Agree with DanC
[DanC]
"formed" has a before/after feel to it. odd.
[timbl]
agree with danc
[Stuart]
Yes that would work for me
[Ian]
DC: "This represents a link between the two resources."
[DanC]
When a representation of one resource refers to another resource with a URI reference, this represents a link between the two resources."
[Ian]
IJ: What about s/URI/URI ref here?
DC: Could work.
TBray: I disagree about using URI ref here.
[DanC]
When a representation of one resource refers to another resource with a URI, this represents a link between the two resources.
[Ian]
TBray: The representation *logically* includes a URI.
#5) 2.4.1 Secondary Resources...
[TBray]
#5 in http://lists.w3.org/Archives/Public/www-tag/2003Sep/0186.html
[DanC]
s/the/a/ in "the URI for the secondary resource"
[Ian]
SW: This implies that you need to know the media type.
DC: No, it doesn't. It says "if you know it."
Text in question in 26 Sep draft: "The syntax and semantics of fragment identifiers are defined by the set of representations that might result from a retrieval action on the primary resource. Fragment identifier semantics differ among format specifications. The presence of a fragment identifier in a URI does not imply that a retrieval action will take place."
TBray: I've flagged this in a bunch of drafts. I think that the first sentence is either incomprehensible or wrong. I think that the syntax and semantics are defined by the relevant documentation, and interpreted in the context of the representation that you get.
[Roy]
defined --> determined ?
[Ian]
TBL: I think the first sentence is a bit perverse for the following reason - Depending by the format .... The set of things that the frag id could identify are defined by the set of different representations you get. On the other hand, if the semantics are different, then we have a bug.
[Zakim]
DanC, you wanted to agree that 2.4.1 is not right. can we just make an editor's note and move on? our target is a decision to publish, not substantive technical discussion, yes?
[Ian]
TBL: I would support deleting the first sentence and leaving and editor's note in its place.
[DanC]
+1 delete "The syntax and semantics of fragment identifiers are ..."
[Ian]
TBray: +1 to delete
[Roy]
I would just change "defined" to "determined"
[Ian]
TBL: I don't think you solve the problem that way. There's an implication that one representation suffices; you need to know a set.
RF: You do need to know the set.
TBL: No, I only need to know the one I got.
TBray: That's right.
RF: In that context, maybe. But in the RDF context, you need to know the set of references.
TBray: The architectural intent is that the semantic of the identifier be consistent. But in the microscale is that the interpretation depends on the representation you get.
#6) "For schemes that do specify the use of fragment identifiers..."
People are satisfied with deleted.
#7) Good Practice Note: Content Negotiation With Fragments.
IJ: I didn't change back to previous draft.
"Good practice: Content negotiation with fragments"
s/and who use/who use/
DC: I second the point made by Larry in email that "authorities" is [scribe missed]. Talking about "the owner" of a URI [DC didn't get to finish.]. The good practice note is not talking about HTTP space.
[Zakim]
DanC, you wanted to note that "Authorities responsible for minting a URI" is too narrow
[Ian]
DC: You can narrow the principle to HTTP URIs, but as stated, not narrowed to HTTP space.
TBL: In practice, I haven't seen people use fragids with msg ids.
RF: I disagree with LM's comments but for different reasons.
[timbl]
In practice we are talking largely about HTTP.
[Ian]
#8) 2.5.2
Leave as is.
Section 2.6: Two paras creating discomfort:
- Moby Dick.
- Ambiguity example.
SW: Ambiguity example closely tied to linguistic ambiguity. Mark this para with editor's note as needing attention.
TBL: I don't like the Moby Dick example since it's criticizing an English statement.
#10) 4.5 Binary and Textual Data Formats
SW: make forward reference more narrow to 4.10.6 (not all of 4.10)
#11) Present table of notes after TOC as three lists.
Done
#12) Choose a different icon (smaller) to indicate story. Roy seems to concur.
[Back on 4.4] Text is defined as being sequence of chars, not something that is marked "text/*".
TBL: Distinction between application is used to mark up text and applications where XML is used to mark up any kind of data. This connects to "text/". The argument for using "text/" is that when there's a lot of text content, show people the text content. Not necessarily the case for apps where most of the data is not text.
TBray: I've not seen discussion about changing the definition of things you can do in the "text" (MIME) tree.
[DanC]
(timbl is part of multiple we's)
[Ian]
TBL: We had already asked them NOT to change 3023 since it was to be included in a W3C spec.
TBray: And I got my ear chewed off when I forgot. We need to make up our minds - do we try to fix 3023 or not?
[TAG decides to return to Arch Doc rather than answer that question.]
SW: Any objections to publishing?
[Roy]
It's better than the last one, +1
[Ian]
Resolved: Request publication of TR draft.
IJ: I will make conservative edits before requesting publication for approximately 1 October.

2.1.1 RFC3023

[Ian]
DC: There's an IETF/W3C meeting in 10 days. I'd like to spend 10 minutes on RFC3023
[Roy]
Leave charset on text/xml; remove charset from application/*xml
[Ian]
TBray: 3023 has been out there for a while. I think that fixing it at this point is better than not fixing it. There seems to be rough consensus about what needs to be done: deprecate "text/" for XML formats.
DC: My preference is to have this come out of a W3C spec for an XML Mime type.
NW: I think the Core WG is trying to wrap up the blueberry spec.
DC: The MIME registry currently points to an IETF spec; would be more straightforward if it pointed to a W3C Rec.
TBL: Suboptimal to have the MIME registry point to two specs at two orgs, which undergo different processes.
TBray: Can we have a chat with editors of 3023.
DC: Sounds good.
TBL: I'd like to make changes in a W3C document.
The TAG did not do anything below.

2.1.2 Review of actions related to Architecture Document

Completed action items:

Open action items:

The following action items were follow-up from the 22 July face-to-face meeting in Vancouver:

2.2 Findings

See also TAG findings home page. If time permits, the TAG will review these.

2.2.1 Draft findings that require more discussion

2.2.2 Expected new findings

  1. contentPresentation-26: Action CL (and IJ from ftf meeting) 2003/06/02: Make available a draft finding on content/presentation. From 21 July ftf meeting, revision due 8 August.
  2. Action IJ 2003/06/09: Turn TB apple story into a finding.

2.3 Issues

The TAG does not expect to discuss these issues at this meeting.

2.3.1 Identifiers (URIEquivalence-15 , IRIEverywhere-27)

2.3.2 Qnames, fragments, and media types(rdfmsQnameUriMapping-6, fragmentInXML-28, abstractComponentRefs-37, putMediaType-38)

2.3.3 New and other Issues requested for discussion. (mixedUIXMLNamespace-33, RDFinXHTML-35, siteData-36 plus possible new issues)

Existing Issues:

2.3.4 Miscellaneous issues

3. Other actions

Ian Jacobs for Stuart Williams and TimBL
Last modified: $Date: 2003/09/29 22:22:28 $