W3C | TAG | Previous: 6-8 Oct ftf in Bristol | Next: 27 Oct 2003 teleconference

Minutes of 20 October 2003 TAG teleconference

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

Note: The Chair does not expect the agenda to change after close of business (Boston time) Thursday of this week.

1. Administrative (15min)

  1. Roll call: NW (Chair), TBL, TB, DO, PC, RF, CL, IJ (Scribe). Regrets: SW, DC.
  2. Accepted the minutes of the 6-8 Oct ftf in Bristol
  3. Accepted this agenda
  4. Next meeting: 27 Oct 2003 teleconference. Regrets: TB, IJ. PC at risk.
  5. Reminder: Action items related to Arch Document due 22 October. People reconfirmed that they would be able to complete their actions.

Upcoming meeting topics:

1.1 TAG update at Nov 2003 AC meeting.

  1. Completed action SW 2003/09/29: Draft summary based on monthly reports from previous six months (for AC meeting). See previous highlights.
  2. Completed Action DO, CL 2003/10/07: Draft presentation for the AC meeting (Done)

Action DO, CL 2003/10/20: Produce draft slides for AC presentation; for discussion at 27 Oct teleconference.

2. Technical (75min)

  1. abstractComponentRefs-37
  2. Review of 3023-related actions
  3. Review of Architecture Document writing assignments

2.1 abstractComponentRefs-37


[Background on draft finding from DO]
TBray: There needs to be more structure of this document to point out (1) here's what we think you should do (2) here's the raw data. Not clear why raw data there. I think it's useful to have that data there.
IJ: Should I publish this on the W3C site?
DO: Yes, after my next round of updates.

IJ: My suggestions for the finding:

  1. Create an acknowledgments section. Move references to people who have contributed to this project to the acks section. Leave only technical material in the heart of the document.
  2. The information that is time-sensitive (e.g., "The TAG is currently....") belongs either in the status section of the document or in a separate section on ongoing work. Please separate that from the technical issues which do not depend on what the TAG is currently doing.
  3. Section 2.1 refers to "Requirements" but I believe these are the requirements initially set forth by the WSDL WG. These aren't TAG requirements. Furthermore, it's not clear whether any or all of the solutions in the solution space conform to the requirements. I think it may be better if, after discussion of the solution space, there is an indication of which, if any of the proposed solutions conform to the WSDL WG's original requirements. I think you could even remove the list of requirements and just include a link to some published statement of the requirements. In short, I don't think the requirements need much presence in the finding.
  4. The finding does not state clearly what an abstract component is. It also doesn't explain what the problem is: why are references to abstract components trickier than others? Please include a story nearer to the front of the document (e.g., after the summary of principles)..

Discussion about balanced parentheses in fragment identifier syntax

At this point, discussion shifted from the finding to the question of the relationship between the finding, the xpointer syntax, and previous statements from Roy Fielding about the use of balanced parentheses in frag identifier syntax. There were no additional comments on DO's first draft of the finding.
CL: Re balanced parens; are we saying that in general balanced parens are bad in URIs?
RF: Yes
CL: In that case, we have some problems with xpointer framework...
PointerPart ::= SchemeName '(' SchemeData ')'
EscapedData ::= NormalChar | '^(' | '^)' | '^^' | '(' SchemeData ')'
is broken, as stated earlier
TBray: Roy has publicly flamed xpointer in the past.
so we are saying, as the TAG, that XPointer Framework and dependent specs are *broken*? or not?
DO: Hence wording in the finding - I don't think that the TAG has made an explicit recommendation that xpointer is broken. Some TAG participants have said that balanced parens are a bad idea. Some of the participants have agreed, or not actively pushed back.
RF: I've seen many bad designs in which parens are used; I've seen no designs that actually required parentheses. I've seen some cases where parens were used *internally*, but not exposed. Xpointer produces invalid fragments since the URI spec does not allow those characters.
RF: xptr spec uses illegal characters not allowed in fragment identifiers
cl: however, the syntax used in XML will be escaped when used on the wire as per usual
CL: I have concerns that some folks on the TAG feel a recent W3C Rec is broken. And that the finding uses the xpointer syntax. I'd be ok pointing out (1) this is the syntax and (2) there are problems with it.
RF: I'm ok with presentation as is in the draft finding.
DO: Maybe the TAG should have an issue on parens in frag identifier syntax; tied to xpointer.
CL: This affects SVG as well, which has its own fragment syntax.
which uses parens as per what was believed to be correct current practice
DO: I'm not sure that we would recommend xpointer to wsdl wg even if we said parens ok. Do we want a finding on good URI practices?
CL, TB: Yes.
[TB seeks title for issue regarding URI design]
http://www.w3.org/XML/Linking has no link to an implementation report
PC: Has anyone done this work on best practices for URI design?
RF: It's not in the spec (since hard to get consensus on that...).
PC: I'm concerned that, while useful, documenting good practice might be too much of a challenge.
RF: The info is there, in various places. Some info is in TBL's DesignIssues. If I get excited, I'll add as an appendix of RFC2396 bis
DO: Should the TAG start on this and then fold into RFC2396?
RF: It's always useful to seed the clouds, but people tend NOT to agree on how to design a URI space. They tend to not agree strongly.
TB: Look at what Vignette does and don't do that.
IJ to self: This is also related to URI-squatting.
DO: Even enumeration of choices (even if some agree, some don't) still useful. Another survey..
RF: Also sounds like arch doc.
Principles: don't put in the name of the product e.g. example.com/cgi-bin/sadlfk.cfm?cfmId=3125
DO: Hmm, seems like finding a better place for this level of detail rather than in arch doc, especially if the material is controversial.
Principle: consider putting in dates
TBray: I think that we should adopt this as an issue: "What are good practices for URI construction?"
I will take that as an action item
Resolved: Add issue URIGoodPractice-40
Action IJ: Add to issues list.
Action RF: Draft finding for this issue.
NW: This should allow DO to simplify his finding a little.
NW: Is this in the critical path for last call?
[Nobody thinks it is.]

2.2 Review of 3023-related actions

Actions 2003/10/08:
- NW to liaise with Paul Grosso and the XML Core WG
- TBL and DC to liaise with the IETF regarding obsoleting RFC 3023.
- TB to talk to authors of 3023 about inclusion as appendix in xml 1.1.
- TBL and DC will talk to the Architecture Domain Lead.


[TB update on action items]

NW: I spoke to the Core WG about this last Weds. There was general agreement that a revision of 3023 would be a good thing, and that XML 1.1 should point to an updated version. In addition, the Core WG felt it would be nice if 3023 used xpointer syntax for frag ids for xml. I told them that the TAG was unlikely to push for that.

- TBL and DC to liaise with the IETF regarding obsoleting RFC 3023.
TBL: We talked to the IETF about this
CL: There was discussion at the XML CG teleconference about this (minutes)
TBL: Good direction in general, but not for this iteration of XML 1.1. Happy to leave it in son-of-3023 this time round. Does tag have an opinion on that, xml fragid syntax? People use barename id pointers currently
I would prefer that the "id" issue be settled first.
TB: People do not use application/xml they use a more specific type (docbook, svg, whatever).
NW: I'm in favor of having a generic fragment syntax to prevent each one having to define the same minimum stuff. Like xptr framework syntax.
TB: So no consensus on what the pointer should be or whether it is needed?
- TB to talk to authors of 3023 about inclusion as appendix in xml 1.1.
TBray: I'm less optimistic about getting this revised. I talked to the editors: Simon is not keen to work on a revision; MURATA-SAN wants to wait until W3C has a policy on charsets. Dan Kohn no longer active in this area..
TB: arch doc says 3023 is wrong, simon says "and?"
TBray: I think we have made our position clear; it's written up in arch doc; there's not much else we can do.
RF: You can write a short draft and publish it as a proposed std. Have the RFC editor mark 3023 as updated. You don't need the original editors to write an update spec. I'll point CL out some examples (e.g., RFC 2732).

TBray: For formatting document, check out "xml2rfc" tool, just type that into Google.

RF: Or see XSLT for RFC generation.

Action CL: Draft update to 3023 for review by the TAG (on www-tag).

2.3 Review of Architecture Document writing assignments

Latest draft is the 1 Oct 2003 WD of the Arch Doc.

The TAG revised action items; none were completed. People are nonetheless confident that they will complete their actions by 22 Oct.

  1. Action TB 2003/10/08: Write up a paragraph for section 3 on syntax-based interoperability.
  2. Action TB 2003/10/08: Write a paragraph of rationale for why error handling good in the context of the Web.
  3. Action TB 2003/10/08: Propose a revised paragraph to replace the "Furthermore" sentence in section 2.3
  1. Completed action SW: Send to IJ draft diagrams
  1. Action IJ 2003/10/08: Add ed note to abstract that the abstract will be rewritten.
  2. 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.
  3. Action IJ 2003/10/08: Draft good practice note for 4.4.
  4. Action IJ 2003/10/08: In 2.4, add story that shows how two classes of error can arise (inconsistency v. no frag id semantics defined). Frame story in terms of secondary resources.
  5. Action IJ 2003/10/08: Split persistency section into two and move http redirection para there, with appropriate rewrites.
  6. Action IJ 2003/10/08: Update OWL ref since in CR
  7. Action IJ 2003/10/08: Add a future work section for identifiers that the TAG expects to summarize various URI schemes and what agents can infer from the scheme.
  1. Action DO,NW 2003/10/08: Make the summary to replace 4.5 Extensibility and Versioning in the arch doc
  1. Action CL 2003/07/21: Discuss and propose improved wording of language regarding SVG spec in bulleted list in 2.5.1.

    CL: Progress. I'll send new text; see also IRC log.

  1. Action NW 2003/10/08: Write up text on information hiding/abstraction respect for before 2/3/4.
  2. Action NW 2003/10/08: Revise QName finding. We will also add those two good practice notes to section 2:
    1. If you use Qnames, provide a mapping to URIs.
    2. Don't define an attribute that can take either a URI or a Qname since they are not syntactically distinguishable."
  3. Action NW 2003/10/08: Rewrite the last paragraph of 4.9.2 to be less inflammatory about DTDs
  4. Action NW 2003/10/08: Massage three paragraphs following good practice note about persistency at beginning of 2.6.
  1. Action RF 2003/10/08: Explain "identifies" in RFC 2396.

    RF: In the Arch Doc, just remove '(i.e., name)'.

  1. Action TBL 2003/07/14: Suggest changes to section about extensibility related to "when to tunnel".
  1. Action DC 2003/07/21: Propose language for section 2.8.5 showing examples of freenet and other systems. Progress; see URISchemes/freenet
IJ talked about modeling Web Arch in OWL
IJ: I have been doing desxcription in OWL
TBray: I'd prefer circles and arrows diagrams to UML.
DO: We'd only be using a small piece of UML.
IJ: I would like to get TBL to work with me on this offline.
I guess it should be stated for the record that moving from visio as I proposed to OWL for diagrams effectively cuts me out of being able to edit said diagrams. I am concerned that this will set a default for all future diagrams, such as the extensibility/versioning diagram.
IJ: I think that RF's action is not critical path. What about TBL's action from July?
TBL: Please don't drop this action.

The TAG did not cover these issues

2.5 Findings

See also TAG findings home page.

2.2.1 Expected new findings

2.6 Issues

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

2.6.1 Identifiers (URIEquivalence-15 , IRIEverywhere-27)

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

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

Existing Issues:

2.6.4 Miscellaneous issues

3. Other actions

Ian Jacobs for Norm Walsh and TimBL
Last modified: $Date: 2003/10/20 22:27:55 $