TAG Weekly Teleconference
18 Oct 2004


Norm, TimBL, Chris, Stuart, Noah (parts), DanC, Roy, PaulC,


  1. Convene, take roll, review records and agenda
  2. TAG Charter
  3. 2.1 Review of 2nd Last Call Document
  4. On Generalizing Representations

See also: Agenda, IRC log

Convene, take roll, review records and agenda

Noah: partial regrets.

scribe next week: NDW

chair next week: Stuart

Re "ACTION CL: Chris collect IRC logs from last f2f ( cf pointers for assembling meeting minutes of 11 Aug) and turn into minutes." CL reports problems with a tool that seemed to be working before. WITHDRAWN. RESOLVED: to accept 09-tagmem-irc, 10-tagmem-irc, 11-tagmem-irc, ... and "TAG F2F minutes, Tue 10 Aug PM" as a true record.

RESOLVED: to accept Basel Meeting of the W3C Technical Architecture Group, 5-7 Oct 2004 as a true record.

SW: thanks, Dan, for making prose minutes

<timbl> +1

SW: today's agenda...

ACTION PC: create draft summary for AC, get it to Steve Bratt by Oct 22

ACTION TBL: to investigate possible staff contact for TAG, due date 20 October 2004

(continued without discussion)

1.1 TAG Charter (10 mins max!)

SW: NM expressed some concerns [... missed?]

PC: I've forwarded the revised charter to colleages in microsoft
... don't have an answer yet
... the 25 Oct deadline is not a lot of time
... I can see the motivation for it...

<Stuart> NM expressed concerned that he does not what his own disclosure obligations are.

<scribe> withdrawn due to lack of critical mass: Proposal: The TAG welcomes the revisions proposed in the draft TAG Charter. (member visible)

2.1 Review of 2nd Last Call Document

NW: going well... webarch 14 Oct draft
... I missed an update to the "... however ..." bit re RFC2119

<scribe> DONE: ACTION NDW: to fix cross references to "uri allocation" that read "uri assignment"

<scribe> DONE: ACTION NDW: add "for more info, see also" link to a section of a QA spec to 4.x

<scribe> DONE: ACTION NDW: to produce an editor's draft by 14 Oct (COB EDT)

SW: I intend to go 7, 20, infores, rest. [minutes have been reordered by date-comment-originally-sent]

(in the agenda, italics denote "commentor wait state")

SW: unfortunately, there are comments from Dubost that we didn't discuss in Basel.

  1. "information resource"

    SW: Stickler was not satisfied by the text we agreed in Basel.
    ... suggested 2 changes.
    ... 1 is a change to the wording of the definition of information resource
    ... 2nd is to define both Web Resource and Information Resource

    DanC: I'm not persuaded to change our decision from Basel

    CL, NW: me too[neither].

    SW: anyone care to support the changes? [silence]
    ... I'll let him know we discuss it.

    ACTION SW: inform Stickler re information resources

  2. non-authoritative syntaxes for fragment identifiers

    NW: "one may compare" no longer occurs; yes, I think I deleted the 2 sentences

    DanC: how about [closed] and pls fwd your question to www-tag for discussion

    <Roy> okay

    ACTION RF: reply [closed] and pls fwd your question to www-tag for discussion re non-authoritative syntaxes for fragment identifiers

  3. new text for Information Resource (section 3.1)

    Hawke is satisfied.

  4. resources/representations [was: random comments on 2nd LC of WebArch]

    Chris excerpted:

    - in 3.3.1, "One cannot carry out an HTTP POST operation using a URI that identifies a secondary resource." this seems very HTTP-specific; any chance this refers to something broader? Otherwise, I suggest it should belong to the HTTP spec, not to WebArch.

    <Chris> no longer occurs - moot

    NW: section on secondary has been redone. http://www.w3.org/2001/tag/2004/webarch-20041014/#def-secondary-resource

    ACTION SW: respond to Dom re resources/representations

  5. too positive on extensibility
    I expect that you should hear a reply from us by Monday EOB"

    CL: I'll ping again.

    (ok, so that one's really in commenter-wait state; Dom's msg wasn't a state-changing msg)

  6. section 2.2 - what does it mean to 'take on meaning'
  7. Use of "assign" for URI -> resource

    <Stuart> http://lists.w3.org/Archives/Public/public-webarch-comments/2004OctDec/0024.html

    I can 'live with' whatever wording you choose"

    ACTION SW: Close that thread Use of "assign" for URI -> resource

    <timbl> URIRev04 BOF minutes

    RoyF: let's get involved in the discussion of the revision of URI registration guidelines docs

    From: Larry Masinter <LMM@acm.org>
    To: 'Eric Hellman' <eric@openly.com>
    Cc: uri@w3.org
    Subject: RE: updating RFC 2718 (Guidelines for new URL schemes)
    Date: Tue, 07 Sep 2004 23:23:23 -0700

    revision documents seem to be forthcoming but not yet available

    RF, NW, SW volunteer to participate in the review.

    PC: I like the idea of letting them know what's in webarch now

    SW will let LMM know we'll gladly get involved in review of guideslines in his action.

    RF: FYI, IESG approved URI spec as IETF Standard.

  8. Comments from the QA WG on WebArch 2nd LC (extensibility)
  9. Cyberspace analogous to set of all sets: URIs & URLs
  10. Representation of a secondary resource?
  11. KD 002 [was: Comments on Web Arch WD - 2004-07-05]
  12. [Tim Bray] Review of webarch-20040816

    NW: I prodded him last week.

  13. KD 004

    is in commentor wait, as of CL's 7 Oct msg.

  14. URIs and resources

    TimBL: how about "specifications associated with the scheme name"

    PC: that's what he suggests.

    DanC: let's refer to where we traced the path thru all the specs

    NDW: I'm willing to fix...

    ah... rabbit-chase is 3.1.1. Details of retrieving a representation

    <Roy> +1 to clarification by reference

    ACTION NDW: fix "relevant specifications", incorporating a cross-reference to 3.1.1 Details of retrieving a representation

  15. HTML WG last call comment ...

    scribe: which has come out of commentor-wait state.

    rather, it's still in commentor wait state, but the commentor has given us an update out-of-band

    <Stuart> http://lists.w3.org/Archives/Member/tag/2004Oct/0050.html

    SW: I'm willing to follow up, showing them the specific text.

    ACTION SW: update HTML WG on specific text re xlink

    <Stuart> http://www.w3.org/2001/tag/webarch/#xml-links

  16. Editorial comments on 28 Sep 2004 Editor's Draft of Web Arch

    NDW responded, putting this in commentor-wait state.

    PC: his message is all editorial, giving us license to do as we may; let's close it.

    ACTION NDW: close thread on editorial input from ij

  17. Re: too positive on extensibility [was: random comments on 2nd LC of WebArch]

    seems to be a tool glitch.

  18. Late last-call comment on AWWW

    re 4.5.3

    TimBL: "One particularly useful mapping in the case of flat namespaces (specified, for example, in [RDFXML]) is to combine the namespace URI, a hash ("#"), and the local name, thus creating a URI for a secondary resource (the identified term)." is buggy.
    ... it would have been nicer that way, but actually the rule is just to concatenate.

    NDW: how about I s/ a hash ("#"),//

    CL: the "thus creating..." bit falls apart

    <Chris> no, that only works if the URI ended in a #

    <Chris> would be a better algorithm to add a hash *if required*

    ACTION NDW: fix "One particularly useful mapping in the case of flat namespaces (specified, for example, in [RDFXML]) is to combine the namespace URI, a hash ("#"), and the local name, thus creating a URI for a secondary resource (the identified term)."

    <timbl> He is right. to concatenate a namespace name ending in "#" with...

  19. Some thoughts on effective access to "primary" vs "secondary" resources, consistency of descriptions, and bootstrapping the semantic web...

    DanC: this one's late

    a few skimmed it; it doesn't seem to merit further attention

  20. KD005 thru KD016

    <paulc> Looking at KD14 in http://lists.w3.org/Archives/Public/public-webarch-comments/2004JulSep/0048.html

    NW: I responded "... are you satisifed" or "... could you be more specific" for all but K14...

    <Stuart> *KD 014

    <Stuart> 4.5.7. Media Types for XML

    <Stuart> """ In general, a representation provider SHOULD NOT assign Internet

    <Stuart> media types beginning with "text/" to XML representations."""

    <Stuart> Hmmmm.... I'm not sure. I understand. But for example if you want to

    <Stuart> display the source code of a XHTML file with text/plain, it's perfectly

    <Stuart> valid and a useful case.

    NW: but for the case of a page that's a source view of XML, text/plain would seem to be a good idea...

    CL: [scribe got too involved to take notes]

    <Chris> wonders about text/plain;charset="utf-16"

    TBL: I don't think the special case of a source view merits a change in webarch

    <Chris> um, well,

    <Norm> The root is http://lists.w3.org/Archives/Public/public-webarch-comments/2004OctDec/0053.html

    tbl, pls reply to http://lists.w3.org/Archives/Public/public-webarch-comments/2004OctDec/0053.html

    <Chris> Chris (explains text/* required fallback to text/plain;charset="us-ascii")

    ACTION TimBL: reply to KD014 defending current text

    <Norm> http://lists.w3.org/Archives/Public/public-webarch-comments/2004OctDec/0055.html

    KD016 Orthogonal specifications http://lists.w3.org/Archives/Public/public-webarch-comments/2004OctDec/0055.html

    <Stuart> * KD 016

    <Stuart> 5.1. Orthogonal Specifications

    <Stuart> """the software developer community would benefit from being able to

    <Stuart> find all HTTP headers from the HTTP specification (including any

    <Stuart> associated extension registries and specification updates per IETF

    <Stuart> process). Perhaps as a result, this feature of the HTML specification

    <Stuart> is not widely deployed. """

    <Stuart> Not true. Use case. I'm a technical writer, I'm explaining how to

    <Stuart> create an HTML file, foo.html, I give a link to the html representation

    <Stuart> of foo.html and therefore served as text/html. Now I want to explain

    <Stuart> the source code, and I would like to use the benefits of the object

    <Stuart> element to display the source code of the same file. So I set in my

    <Stuart> object element the text/plain mime type.

    <Stuart> Though because of precedences rules of HTTP over HTML, the only way to

    <Stuart> do is to not specify on the server side the mime type but only in the

    <Stuart> meta of the HTML file. So that once it can be displayed as an HTML file

    <Stuart> or it can be displayed as a text file.

    NDW thinks he's replied "I don't think this merits a change", though the archive doesn't yet show it

NW: I now have 2 actions... is that it? If so, I can have a spec for next week.

SW: 1st noah's text...

On Generalizing Representations

NM: [recaps the genesis of this action...]

<scribe> DONE: ACTION NM: to take a run through to see how generalizing 'representation' to be less constrained would look with more careful terminology, report on whether this looks feasible or not.: see draft of Thu, 14 Oct 2004 15:01:12 -0400

CL: I like that text you wrote in 3.2

NM: section by section... 1. Introduction

| the noun "representation" means "[{NOAH>} Machine readable data that encodes octets that encode resource state information".

<Chris> sorry i was only going to the green items in the toc

NM: in 2.4. URI Schemes ...

<Chris> http://www.w3.org/2001/tag/2004/10/webarch-nm/ArchdocNoahMediaTypeRevs.html#schemes-and-representations

(once again, I'll point out that the I18N WG commented on the pronouceability of Oxaca)

NM: new good practice: Reuse representation formats

<Chris> I like the direction this is going

<scribe> " New protocols created for the web SHOULD transmit representations as octet streams typed by Internet media types."

<Zakim> DanC, you wanted to ask what term NM is suggesting for bag-of-bits-with-mime-type

NM: I've read it now, and I like it.

<Stuart> ac Roy

RF: I don't like the way "protocol" is used...
... it's really about assignment of names [?]

<timbl> protocols

RF: I sent mail about this. (PC notes having received it. pointer?)
... HTTP protocol is used to proxy representations of resources named with ftp: etc.

NM: I think that's what I was trying to say, but I guess I misused "protcol"

RF: yes, this problem predates your changes.

<Chris> ha! So I was right to focus on 3.2 Interactions section :)

NM: do we have a name for protocol, as opposed to scheme? [the point is more subtle, but the scribe has no hope]

<Chris> the use of the protocols, the transfer, is the interactions section

(scribe thinks he hears on-the-wire-protocol, naming-scheme, and relationships between those and representations being discussed...)

<Chris> scribe seems to be correct, to me

(DanC is concerned by the frequency of "whatever we call it" references; deciding on the terms is 80% of the work)

<Zakim> Chris, you wanted to give general agreement

CL: I like NM's text in 3.2 ...
... [missed]. There are other protocols that use MIME: email, ...

NM: how about moving some of the story from [where?] to 3.2?

CL: yes...

<Chris> from 2.4.1

<Chris> protcol should be 'scheme name' perhaps, in section 2

NM: I read the webarch spec as saying [something] that I gather isn't what the TAG meant.

<Chris> [something] = use of protocols, rather than registration of scheme names

<Chris> i thought I was being asked a question!

SW: does this merit another last call?

CL, NW: no. DC: it introduces that risk, yes

<Roy> I don't know how to determine when a change requires new last call

DELTA does not merit a new last call if, when presented with LC+DELTA, the LC reviewers would say "yes, my review applies to that document too"

<Zakim> Chris, you wanted to carry on with my rationale

NW: I'll make the 2 actioned changes, checkpoint that, and then take a stab at incorporating changes from NM

SW: separately-named docs? NW: OK.

ACTION NDW: attempt to incorporate input from NM and RF etc. on generalizing representations


Minutes formatted by David Booth's scribe.perl 1.81 (CVS log)
$Date: 2004/06/08 14:14:43 $