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
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)
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)
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.
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
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
Hawke is satisfied.
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
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)
<Stuart> http://lists.w3.org/Archives/Public/public-webarch-comments/2004OctDec/0024.html
I can 'live with' whatever wording you choose" LMM
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.
NW: I prodded him last week.
is in commentor wait, as of CL's 7 Oct msg.
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
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
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
seems to be a tool glitch.
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...
DanC: this one's late
a few skimmed it; it doesn't seem to merit further attention
<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...
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 ...
(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
ADJOURN.