W3C | TAG | Previous: 24 Nov teleconf | Next: 4 Dec TAG teleconf

Minutes of 1 December 2003 TAG teleconference

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

1. Administrative

1. Roll call: DC (Chair), SW, TBL, CL, DO, PC, RF, TB, IJ. Regrets: NW.
2. Accepted the minutes of the 15-17 Nov ftf meeting, TBL and PC abstaining.
3. Accepted the minutes of the 24 Nov teleconf
4. Accepted this agenda
5. Next meeting: 4 Dec 2003 teleconf at 8am PT / 11am ET. Review issues to close before last call.
6. Video meeting in Feb 2003:
   1. Action SW/PC 2003/11/10: Explore possibility of TAG videolink TAG distributed meeting in February.
7. Tech Plenary
   1. Continued action SW 2003/11/15: Take to tech plenary committee the TAG's proposal.

      SW: I haven't received a response from the committee yet (since they have yet to meet).

8. Negotiations with WGs for last call:
   1. SW/I18N: SW sent. Reply pending from I18N.
   2. Schema/PC: PC sent. MSM has confirmed for Schema WG.
   3. SVG/CL: CL sent. CL has confirmed for SVG WG..
   4. HTML/IJ: IJ sent. Reply pending from HTML WG.
   5. Todo: Voice/SW, XML Core/NW, WSDL/DO

2. Technical (75min)

1. Review of Architecture Document writing assignments

2.1 Review of Architecture Document writing assignments

Comments on 28 Nov 2003 WD of the Arch Doc?

Recent action items:

Ian

1. Withdrawn action IJ 2003/10/08: Starting from DO's diagram, create a diagram where the relationships and terms are linked back to the context where defined. Ensure that the relationships are in fact used in the narrative; any gaps identified? With DO, work on term relationship diagram.
2. Completed action IJ 2003/11/15: Add a column to the TAG issues list about the version of the document in which we are expecting to address the issue.
3. Completed action IJ 2003/11/15: Provide wording to replace text in 1.1.2 about relation between arch doc and findings (w.r.t. good practice notes).
4. Completed action IJ 2003/11/15: Revise SVG story in discussion with TBL.
5. Completed action IJ 2003/11/15: Incorporate TBL and DC text into 3.4.
6. Completed action IJ 2003/11/15: Fix ref to 30 at end of section 4.2
7. Completed action IJ 2003/11/15: Fix para after 1./2. bullets in 4.3 to make clear that language must prepare in advance (i.e., syntax) for this type of override.
8. Completed action IJ 2003/11/15: Write caveat about integration formats like FO
9. Action IJ 2003/11/15: Close issue 6 with TB proposed text. (Done) Inform reviewer. (Not done)
10. Completed action IJ 2003/11/15: In 4.6.4, amend story to talk about the choice of extensibility model and namespace policy how that helps them meet their desired goals (easy changes, less cost). Tie namespace change more strongly to extensibility model with a cross reference.
11. Completed action IJ 2003/11/15: In section 4.6.6, add refs to infoset and PSVI.
12. Completed action IJ 2003/11/15: Ensure that pointed to from issues list.
13. Completed action IJ 2003/11/15: Add new issue regarding derived resources.
14. Completed action IJ 2003/11/15: Add new issue ultimateQuestion-42.

Chris

1. Completed action CL 2003/07/21: Discuss and propose improved wording of language regarding SVG spec in bulleted list in 2.5.1. (Done)
2. Completed action CL 2003/11/15: Propose a sentence for 4.4 about delivery context.
3. Action CL 2003/11/15: Write text to reviewer about the resolution of errorHandling-20.

Norm

1. Completed action NW 2003/10/08: Revise QName finding. See draft finding from NW.
2. Completed Action NW 2003/11/15: Provide language on cost/benefit trade-off of extensibility.
3. Completed Action NW/IJ 2003/11/15: Rewrite 4.6.2. Revise first GPN per TB text. Second one ok. Take language from finding to give more context.

TB

1. Completed action TB: Rewrite paragraph on ambiguity in section 2.2.

Roy

1. Action RF 2003/10/08: Explain "identifies" in RFC 2396.

   RF: The current draft expires this week...I'd better do it...please continue.

DO

1. Completed Action DO/TBL 2003/11/15: Produce new text for a small subsection 1.2.4 (or perhaps for 1.2.1)

   [TBL not satisfied with how text incorporated; see below]

2. Action DO 2003/11/15: Point WSDL WG to resolution of issue 6.
3. Action DO 2003/11/15: Propose some extra text for section 4.5 that hypertext agents often follow an IGNORE rule and this often results in incompatible behavior. Ignore applied to fragid interpretation.

   MOVE TO ISSUES LIST.

TBL

1. Action TBL 2003/07/14: Suggest changes to section about extensibility related to "when to tunnel".

   MOVE TO ISSUES LIST.

DC

1. Withdrawn Action DC 2003/07/21: Propose language for section 2.8.5 showing examples of freenet and other systems. Progress; see URISchemes/freenet
2. Completed action DC 2003/11/15: Elaborate on value of orthogonality of specs in section 1.2.1 including example HTTP/HTML
3. Completed action DC 2003/11/15: Write up some replacement text for text at beginning of 3.3.1.
4. Action DC 2003/11/15: Follow up on KeepPOSTRecords with Janet Daly on how to raise awareness of this point (which is in CUAP).

SW

1. Action SW 2003/11/15: Verify that "agent" is used consistently in the document and makes sense as both people and software. [Subsumed by IJ?]

   TBray: Better than it used to be.

   IJ: I agree with TB.

   SW: Please continue my action 1.

2. Completed action SW 2003/11/15: Provide photo of extensibility/versioning whiteboard notes for the meeting record (Done)

   Action IJ: Link to SW's photos from 15 Nov ftf meeting minutes

Walkthrough of Tim Bray review of 28 Nov draft

TB review comments

[Ian]

1.2.1. Orthogonal Specifications

TBray: CL and I had some back and forth on this.

[Chris]

and http-equiv="refresh now"

[Ian]

TBray: I like the motherhood and apple pie language before the bulleted list.

[TBray]

" The HTML specification allows content providers to instruct HTTP servers to build response headers from META element instances. This is a clear abstraction violation; the developer community deserves to be able to find all HTTP headers from the HTTP specification (including any associated extension registries and specification updates per IETF process). Furthermore, this design has led to confusion in user agent development. The HTML specification state

[Ian]

TBray: I think the first sentence needs rephrasing. The HTML spec supplements HTTP servers.

CL: In fact, the HTML spec is an instruction for HTTP servers, which is universally ignored. That's evidence of a problem having arisen.

TBray: Perhaps a bit of phrasing "This doesn't work in deployed servers as specified!"

[TBray]

3rd bullet: " Some authors use the META/http-equiv approach to declare the character encoding scheme of an HTML document. By design, this is a hint that an HTTP server should emit a corresponding "Content-Type" header field. In practice, the use of the hint in servers is not widely deployed and many user agents peek inside the HTML document in preference to the "Content-Type" header field. This works against the principle of authoritative representation m

[Ian]

Action IJ: Salt this text to taste to emphasize that problems have arisen.

[DanC]

emph " servers is not widely deployed "

[Ian]

RF: There are servers that implement it, FYI. [Some] Content management systems do this.

[Chris]

content magagement systems, and the discontinued GN server

yes, i agree that a sentence of introduction would be helpful

[Ian]

TBL: The gist is missing: It's not just enough to make an extension language, you also need to make it so that not only old documents members of the new language, but also that new docs, without much damage, can be interpreted in the old language. Ok that extension is inverse of subset. Missing text is that you need to ensure that a doc in the extension language can be interpreted in the old language with predictable results.

[Roy]

"second" and "first" is ambiguous

[Ian]

TBL: Should be in para about "Language extension".

[DanC]

I note "we", the TAG decided on whatever timbl, daveo, and Ian agree to.

[Ian]

TBL/DO's text came from: http://www.w3.org/2001/tag/2003/webarch-20031111/tim

[timbl]

"Clearly, an extension language is better than an incompatible language, but in practice greater compatability is needed. Ideally, an instance of the superset language, in many cases can be safely and usefully processed as though it were in the subset language. Extensability the property of a langauge that allows this. The original language design can accomplish extensability by defining, for predicable unknown extensions, the handling by implementations -- for

[Roy]

Language A' is an extension of language A if and only if A is a subset of A'.

[Ian]

TBray: I think CL and I agree that most of the issues are probably not controverial.

CL: I agree with TB's assessment.

[Chris]

my response at http://lists.w3.org/Archives/Public/www-tag/2003Dec/0018.html

[Ian]

1.2.4 Is the 2nd sentence of the first para, about the longevity of

messages, new in this draft? It doesn't have anything to do, not in

the slightest, with the actual point being made in this section.

TBray: Propose to lose that sentence.

CL: Fine to drop.

Action IJ: s/messages exchanged/technology shared.

[Chris]

"the technology shared among agents in the Web may last longer than the agents themselves" would also be fine.

[Ian]

TBray: I propose that second para be dropped.

First sentence only?

TB proposal: Rewrite first sentence per CL proposal.

[Chris]

So, I agree with Tim about loosing the last para, but also suggest deleting "not in terms of APIs or data structures or object models, but in terms of protocols,". Make a positive point about the benefits of message based interop, its not necessary to knock other approaches to make the point.

ian does now

[Stuart]

s/content and sequence/content,sequence and semantics/

[Chris]

deletion proposed *is* in IRC

[TBray]

s/not in terms of APIs or data structures or object models, but//

[Ian]

(in FIRST para)

[DanC]

"The Web follows Internet tradition in that its important interfaces are defined in terms of protocols, by specifying the content and sequence of the messages interchanged."

[Ian]

TBL: I'd like semantics to go in para.

TBray: I can live with semantics.

[DanC]

"The Web follows Internet tradition in that its important interfaces are defined in terms of protocols, by specifying the content, sequence and semantics of the messages interchanged."

[Chris]

The Web follows Internet tradition in that its important interfaces are defined by specifying the content and sequence of the messages interchanged.

[TBray]

The Web follows Internet tradition in that its important interfaces are defined in terms of protocols, by specifying the content, sequence, and semmantics of the messages interdchanged.

[Roy]

s/content, sequence and/syntax, semantics, and sequence/

[Chris]

The Web follows Internet tradition in that its important interfaces are defined by specifying the content, sequence and semantics of the messages interchanged.

[TBray]

I'm OK with that

[Chris]

ok

[Ian]

CL: Fine.

[Chris]

+1 to roy

[TBray]

The Web follows Internet tradition in that its important interfaces are defined in terms of protocols, by specifying the syntax, semantics, and sequence.of the messages interchanged

[Chris]

go for it

[Ian]

Resolved: Accept TB's sentence.

Proposed: Drop third para.

Resolved: Drop third para.

TBray: 2. Would anyone else like to tighten up the first para by retaining just the first and last sentences? It would be immensely clearer I think.

[TBray]

Parties who wish to communicate must agree upon a shared set of identifiers and on their meanings. Thus, Uniform Resource Identifiers ([URI], currently being revised) which are global identifiers in the context of the Web, are central to Web architecture.

[Ian]

CL: I'm ok with losing second sentence...

[Roy]

/me diff's are so much clearer

[Chris]

I am fine with Tim Brays text

[Ian]

I note that this value bit comes back later in the section on ambiguity.

DC: I meant "network effect" sentence as motivation for first constraint.

[Zakim]

Ian, you wanted to talk about https if we get there. and to comment.

[Ian]

IJ: There's a tie-in in 2.3 in section on ambiguity.

DC: I don't like first para of 2.

CL: +1 to TB's proposal.

TBL: Delete 2nd sentence, leave third.

[Chris]

yay!

[Ian]

Resolved: Delete sentence two of first para of 2.

TBray: I don't understand "Of particular importance are those messages that express a relationship between a URI and a representation of the resource it identifies. "

DC: Those are "200 Ok" responses.

TBray: Then please send that.

IJ Proposal: Clarify intent of sentence in question as last sentence of para of 2.2.

[Roy]

seems redundant to the sentence following it

[Ian]

DC: The point is that the way URIs take on meaning is that you get representations back when you deref the URI; 200 Ok reponses are thus key.

[TBray]

yes, but doing well I think, have covered most of my hot-button issues

[Ian]

DC: I'm ok to lose the sentence, having heard RF.

Proposal to delete "Of particular importance are those messages that express a relationship between a URI and a representation of the resource it identifies."

[Roy]

okay

[Ian]

CL: ok

DC: Ok

TBray: Ok

TBL: Ok

[Stuart]

ok

[Ian]

Resolved: Delete said sentence of 2.2.

s/URI ownership URI/URI ownership

[Editor notes]

3.2. Messages and Representations

TBray: I propose change to read: "A messsage may include: data, metadata about the data, and metadata about the resource."

[Chris]

Some is about the resource, some is specific to a particular resource representation.

[Ian]

CL: My point was that some is about the resource, some about the representation.: E.g,. content-language is about the representation.

TBray: Change to "metadata about the representation data"

[Chris]

we need to say both - resouece and representation metadata

'Vary' for example is about the resource

[Ian]

TBL: Simplify to metadata about the resource and the message.

[timbl]

may include data and metadata about the resource and the message.

[DanC]

by "general" do you mean "typical"?

[Ian]

IJ: I moved "resource metadata" out of ordered list since not the general case.

[Stuart]

message ~= message metadata, representation, represenation metadata and resource metadata?

[TBray]

may include representation data as well as metadata about the resource, the representation, and the message.

[timbl]

Propose: A message may include data, and metadata about the resource and the message.

[Stuart]

+1 to TBray's draft

[Ian]

CL, DC: We prefer TB's proposal.

[Chris]

prefer tbrays one

[Roy]

prefers TBray's draft

[TBray]

A message may...

[Chris]

consensus!

[Ian]

Resolved to accept TB"s proposal.

TB Proposal: Lose GPN just before 3.5

[TBray]

Lose GP at end of 3.4.1

[Ian]

TBray: We say the same thing in preceding para (as in GPN)

[Chris]

"Server managers MUST ensure that resource metadata is appropriate for each representation."

[Roy]

This is not the responsibility of server managers.

[timbl]

s/appropraite for each represnetation/correct

[Stuart]

how about s/approriate/accurate/

[Chris]

s/each/all

[TBray]

s/each/all the/

[Ian]

CL: My point is that if your metadata says something about a resource, make sure it works for all representations.

RF: I don't think this is appropriate at all. It's not the server manager's responsibility. A server manager is incapable of knowing all the resources in the server namespace. The metadata depends on how the author intends a resource to be used (through representations).

[Zakim]

timbl, you wanted to point out that we can't really go into the disnction between different parties in the publisher.

[Ian]

TBL: I think that RF's distinction is between different parties within the publisher (abstraction).

IJ proposal to either add "metadata, especially that applying across representations" and deleting GPN.

[Chris]

+1 to what Ian said

ok now to drop the box

[Zakim]

Chris, you wanted to argue that distinguishing between resouce and representation is the crucial thing; drop 'server manager'

[Ian]

Proposed rewrite of sentence before GPN: Furthermore, server managers can help reduce the risk of error through careful assignment of representation metadata (especially that which applies across representations)." And delete GPN.

[DanC]

so RESOLVED.

[Ian]

3.5 Why the new XForms plug? It adds nothing to the example and creates confusion because people are going to wonder if this is special and different and couldn't have been done with old-fashioned HTML forms. Must be removed.

[Roy]

suggestion: Resource owners must manage the resource's provided metadata as carefully as they manage the data, ensuring that they remain consistent with the intended semantics of the resource.

[Ian]

TBray: Move back from Xforms to HTML forms. Might make people think that you need Xforms to do this.

CL: Propose "for example" around Xforms.

TBray: I'm fine with that.

[Chris]

add "for example' right before xforms

[Stuart]

+1

[Ian]

Proposed: "Built with, for example, XForms")

RF: I think the idea is good, not sure it improves readability.

[timbl]

(built with XForms ro HTMl forms)

[TBray]

OK with TBL's too

[Roy]

simple is better

[Ian]

TBray: Propose to lose parenthetical

[timbl]

Could we see the text we agreed on at the f2f in the 111?

[Ian]

DC: +1 to lose parenthetical

RF: +1 to lose parenthetical

Resolved: Lose parenthetical re: xforms.

[Zakim]

Chris, you wanted to say it makes a link to a finding

[Ian]

DC: Finding is cited in last para of the section.

4.2.2 "must understand". I totally don't agree that "must understand" is limited to markup from another namespace. XHTML could for example have applied a "must understand" policy to new XHTML elements (they may have, for all I know). All you need to do is /markup from an unrecognized namespace/unrecognized markup/

DO: That's correct.

CL: Namespace can be relevant.:You could have different handling whether in or out of namespace (and unrecognized).

[Chris]

http://lists.w3.org/Archives/Public/www-tag/2003Nov/0074.html

[Ian]

TBray: CL's example is deceiving. It's a particular example, less simple.

DO: +1 to TB

TBL: +1 to TB.

Resolved to accept TB's proposal.

4.3 The para beginning "Note that when content, presentation, and interaction are separated" is *very* fuzzy and I think could just be nuked. I don't remember discussing this, is it the output of TAG discussion?

[DanC]

TBray proposes to delete para "Note that when content, presentation, and interaction ..."

CL drafted it, Ian rewrote it

[Ian]

TBray: I withdraw my comment.

4.5.2 is the TAG comfy with being this much in favor of XPointer? I'd need to hear a few explicit "YESes"

[TBray]

To define fragment identifier syntax, use at least the XPointer Framework and XPointer element() Schemes.

[Ian]

TBL's text was this: "XLink is an appropriate specification for representing links in hypertext XML applications." (4.5.2)

[Roy]

Please condense all four paragraphs of 4.5.2 into one.

[TBray]

+1 to Roy

[Ian]

TBL proposal: Move "XLink is an appropriate specification for representing links in hypertext XML applications." to 4.4

[Chris]

I think that 4.5.2 is fine as it is

[Ian]

Support for move: TB

TB, CL: Leave where it is.

[Chris]

better where is is

[Ian]

TBL: Proposed change title of section to 4.5.2to "Hyperlinks in XML"

[Chris]

Propose moving "XLink is an appropriate specification for representing links in hypertext XML applications." to before " XLink allows links to have multiple ends"

[TBray]

Middle of 1st para of 4.5.2

[Ian]

TBL: I think that makes sense..........

[Chris]

establishes a hypertext context

[Ian]

IJ proposes louder back link to hypertext section

[Roy]

editorial: s/( in | for ) XML// for all section headings 4.5.*

[Ian]

IJ summarizing proposed changes to section 4.5.2:

1. s/use at least/consider
2. move third para to first para per CL proposal.
3. Link back to hypertext links section.

[TBray]

+1 to Roy

[Ian]

TBray: +1

TBL: +1

SW: Don't use "consider" twice in same para.

[Editorial]

[Chris]

yes we do

[TBray]

=================>Ian

[DanC]

"specifically" might help, yes.

[Ian]

Resolved: Accept IJ proposal.

4.5.5 2nd para, 2nd sentence is COMPLETELY WRONG. Yes, you can convert back & forth between qunames & URI/local-part pairs. What you can't do is go back & forth from qnames to URIs; which is clearly what Norm meant.

TBray: Yes there is. What there isn't is qname -> URI.

[TBray]

There is no single, accepted way to convert a QName into a URI or vice-versa.

[Chris]

There is no single, accepted way to convert a QName into a URI.

[TBray]

don't lose vice-versa please

OK chris?

[Ian]

SW, TBL: Qualified names and QNames are different.

[Roy]

First sentence defines them as same.

[Ian]

TBray: I think SW is right.

[Stuart]

Propose s/("Qnames")//

[Chris]

section is called "4.5.5. QNames in XML" so no ambiguity...

[Ian]

IJ: I am confused seeing qualified name , then qname, then not understanding the relation.

TBray: Nuke "QName", then insert a sentence explaining relation.

[Roy]

/me I need to go, but please continue without me

[Ian]

TBL: "Qualified names were introduced by XMLNS and are represented in XML by the "Qname" construct."

[DanC]

thanks, roy

[Ian]

IJ: I understand the proposed change the goal of ensuring that text is not inconsistent.

[DanC]

PROPOSED: to fix QName stuff to the satisfaction Lilley and Williams

[Ian]

TBray: +1

[DanC]

so RESOLVED.

[Ian]

Action IJ: Do another draft by Thursday, 4 Dec..

The TAG does not expect to cover these issues

2.2 Review of 3023-related actions

1. Action CL 2003/10/27: Draft XML mime type thingy with Murata-san

2.5 Findings

See also TAG findings home page.

• whenToUseGet-7: Finding: URIs, Addressability, and the use of HTTP GET and POST
• contentPresentation-26: Draft finding: Separation of semantic and presentational markup, to the extent possible, is architecturally sound
• contentTypeOverride-24: 9 July 2003 draft of Client handling of MIME headers
  1. Completed action RF 2003/09/15: Proposed substitute text in light of previous comments on charset param. (Done)
  2. Comments from Philipp Hoschka about usability issues when user involved in error correction. Is there a new Voice spec out we can point to for example behavior?
  3. Comments from Chris Lilley
  4. Lots of comments from Martin Duerst
• metadataInURI-31

2.2.1 Expected new findings

• siteData-36
• abstractComponentRefs-37

  Completed action IJ 2003/11/03: Publish DO's latest draft in finding format (Done)