W3C | TAG | Previous: 6 Jan teleconf | Next: 20 Jan 2003 teleconf

Minutes of 13 Jan 2003 TAG teleconference

Nearby: IRC log | Teleconference details · issues list · www-tag archive

1. Administrative

  1. Roll call: SW (Chair), TBL, TB, DC, NW, PC, RF, DO (partial), IJ (Scribe). Regrets: CL.
  2. Accepted 6 Jan minutes (with corrections suggested by CL and DC).
  3. Accepted this agenda
  4. Next meeting: 20 Jan.
    SW: I will move up on the agenda the question of written contributions; arch doc and review of "How to Compare Uniform Resource Identifiers".
  5. Upcoming meetings: 3 Feb (brief welcome to newcomers). No meeting 10 Jan.

1.1 Completed actions

  1. SW 2002/11/18: Organize a special-interest teleconf for discussion of this issue on linking.
  2. IJ 2003/01/06: Create a ftf meeting page.

1.2 Meeting planning

1.2.1 XLink teleconference

16 Jan; see meeting details (TAG-only).

[DanConn]
MIT holiday calendar
[Ian]
Action SW: Invite Micah Dubinko as well.
[Review of agenda of XLink meeting]
IJ: What about starting discussion with a proposal (e.g., TB's proposal).
NW: I think that concrete proposal based on XLink will not encourage discussion.
TB: What about opening discussion on goals of linking in XHTML 2.0?
TBL: Let's return to the original requirements. I have the feeling the HTML WG has tried to provide a generalized solution, rather than providing a way for authors to make links across vocabs.
SW: I'm not sure we have a clear articulation of the problem.
IJ: Do we have anyone who will champion a cause?
TB: I will champion (1) new functionality for linking in XHTML 2.0 and (2) some principles for linking for the syntax if it's considered to be helpful in making progress.
[TimBL]
I am prepared to speak on behalf of xlink:a
[Ian]
TB: It's important to understand where the HTML WG is coming from, and what they think is important.
IJ: We did hear them say "external namespace is not a huge hurdle."
[SW and TB will chat more about agenda]
IJ: On xlink:a, how do you handle content model?
TBL: You export the content model of html:a. Answer - you crosslink the schemas.
NW: That particular style solution does not address a big part of the process space - some vocabs don't have HTML elements at all.
[Norm]
I want an XLink solution for DocBook which will *never* have HTML inlines in it.

1.2.2 Next TAG ftf

6-7 Feb; see ftf meeting page.

[Ian]
SW: I would like to talk about Tech Plenary.
DC: I hope we will chew over Arch Doc text.
IJ: Most expected text is from action items; there's not much.
[DanConn]
Ian: I expect text from ChrisL on data formats, and perhaps from Tim/Roy on http-14
[Ian]
TB: I'll look at latest editor's draft and send comments.
[DanConn]
DanC: hmm... that's not a whole lot... hmm...

1.3 New issues? Architectural issues with XInclude

See email from M. Murata

  1. fragmentInXML-28 : Use of fragment identifiers in XML.

[Ian]

NW: Consensus of Core WG was that XInclude was doing roughly the right thing. Unsure whether this should be bumped to TAG or whether Core WG should politely indicate that the WG has considered the issue. Purpose of XInclude is to combine infosets of two XML Docs. The only thing it makes sense to include are bits of plain text and bits of XML. XInclude willfully disregards the MIME type. That's its purpose in life.
TB: If this a symptom of a larger problem, we should invest time in it. If this only appears in XInclude, we can safely ignore.
TBL: I think there's need out there; just hasn't been available.
DO: I don't think there's anything architectural to look at here. I'd advise against accepting this as an issue.
NW: I think there's a deep and ugly issue lurking here (though we may choose to not take it up). Frag identifier reliance on MIME type is worrisome...
[DanConn]
Norm, is this different from "fragmentInXML-28 : Use of fragment identifiers in XML"?
[Ian]
TB: I think this intersects with recent flurry about content negotiation.
[DanConn]
hmm... i thought "fragments and mime types" was on our agenda; I thought I was obliged to tell RDFCore what we decided about it...
[Norm]
Yes, fragmentInXML-28 is a good hanger for the larger issue
[Ian]
TBL: What happens if there's a doc served as plain text and you say "treat as plain text". What about the inverse?
NW: With XInclude, you can point to a doc served as text/plain and say "treat as XML". If well-formed, all will go well. I have no problem with that. Murata-san says that that's not the right thing to do since that's explicitly overriding the MIME type.
TB: We say in arch document not to override MIME type.
IJ: Did we say that or did we say "There's one authoritative way to do this; if you do something else you're on your own?"
TB: I think that XInclude is doing the right thing here. We are not talking about general resource representation retrieval. This is a clear special case.
NW: I agree.
DC: Does XInclude recommend Accept headers? I'm inclined to accept this as a new issue (or almost any disposition).
SW: Does anyone propose we take this on as a new issue?
TBL: I haven't read the spec in enough detail.
TB: I agree with TBL that there may be an issue lurking out there, but I don't think we should accept until we have a better crystalization. I would decline on the basis that XInclude functionality is special and wired into XML's view of the world; it is not of particular arch import.
TBL: If it's fundamental to XML, I think we can't say that it's not important to Web architecture. My sense is that there are two functions - they are accepting either xml or taking a plain text doc and doing a rather risky conversion. Fear of ending up specifying same thing in 6 places, inconsistencies, fear of having URI+media type pair.
NW: Nothing risk about conversion of XML -> text/plain
TB: Suppose I ask for something to be included as text that has entity refs?
NW: They are processed.
TBL: I'd like to raise as an issue. I don't want to put it in the head of our queue.
TB: We don't want to get onto the slippery slope of turning URIs into doubles. It does strike me as architecturally question that XInclude doesn't say anything about this (e.g., what happens when content is not xml)?
NW: XInclude will fail.
[Zakim]
DanC, you wanted to propose that we don't find material for a new issue, but we note the requestors stay tuned to fragmentsInXML-28
[Ian]
NW: I'm uncomfortable with that proposal since I'm not sure what the Core WG can do to get to PR.
DC: I think that the Core WG should try to satisfy the commenter.
TB: I'd be willing to second DC's proposal to formally attach this input to issue 28. TBL has convinced me that there's something here we can't ignore.
TBL: That's fine by me.
Resolved: Include this question as part of issue 28.
PC: I'd like minutes to say what, if anything, we are saying to Core WG.
[DanConn]
... TAG isn't instructing the XML Core WG in any particular way...other than to address the comment in the usual way.
[Ian]
PC: Thank you, that's fine.

Action IJ: No new issue. Add this to issue 28 (with reference to XInclude).

2. Technical

2.1 xmlProfiles-29

  1. xmlProfiles-29
    1. Completed action NW 2003/01/06: Write up a second draft of the TAG position based on original proposal.
    2. See email from Chris on options for ID
    3. See email from NW (TAG-only) on ID attributes.
    4. See comments from Paul Grosso to treat xml:id as separate spec.

[Ian]

TB: I'm still uncomfortable here since CL claims there's a big issue here that needs solving. Not in my experience. I think we need more feedback from the community.
Proposal: Move NW proposal to www-tag
David O is leaving the meeting now.
DC: If NW's skunkworks proposal, please don't send out in TAG name. Minimal effort for who? not the readers of the XML specs. There are a lot more readers than writers.
NW: I'm not suggesting this as the sum total; this is "one extreme."
TBL observes that NW's proposal amounts to a diff.
TB: I suggest proposing to www-tag, but with a status section that we don't know whether it represents TAG consensus, but well-enough cooked to get feedback.
Resolved: Send NW proposal (0012) to www-tag
Action NW: Forward proposal to www-tag.

2.2 namespaceDocument-8

  1. namespaceDocument-8
    1. Please read NW summary of the following proposals:
      1. RDDL Proposal from Tim Bray.
      2. RDDL Proposal from Chris Wilper
      3. RDDL Proposal from TBL
      4. RDDL Proposal from Jonathan Borden
      5. RDDL Proposal from Micah Dubinko
      6. RDDL Proposal from Sandro Hawke
SW: Any discussion of NW summary?
NW: I suggested one to pick.
TB: I am increasingly convinced that there would be benefit to the community if W3C published a Rec that was not mandatory, but could be used when appropriate to improve interoperability. I am favoring Sandro's proposal. Like NW, I could live with "none".
IJ: Do you really want the full machinery of the Rec track, or would Note suffice?
TB: Rec track. If we think this should go to Rec, we can either write it or go back to the Director/AC on which other group should address.
TB Proposal: Suggest that W3C take one of these proposals and publish as a W3C Rec.
PC: I think I prefer publishing as a WD with a status section with the intention to take to Rec. I would prefer WD over Note to get wider review.
[No support to publish directly as Note.]
[Some discussion of splitting big pieces into smaller documents to advance them according to ripeness.]
TB Proposal: The TAG thinks W3C should proceed with a recommendation for a data format for namespace docs (not compulsory) and that such a document should follow the Rec track process. The content of the document should be taken from the RDDL challenge proposals; they are
isomorphic in technical content.
NW: Seconded.
[TBray]
TimBL: s/The content/The initial content/
+1
[TimBL]
in favor
[PaulC]
Paul is in favor.
[Ian]
In favor: TB, PC, TBL, NW
Objections: None.
[Roy]
+1
[Ian]
Abstentions: DC, SW
[We note that DO is no longer in the meeting]
Resolved: The TAG thinks W3C should proceed with a recommendation for a data format for namespace docs (not compulsory) and that such a document should follow the Rec track process. The initial content of the document should be taken from the RDDL challenge proposals; they are isomorphic in tecnical content.
Action PC, TB: Write up a WD.
[Enlisting the help of the contributors]
DC: Please include drawbacks in the draft. For example, using an HTML dialect (ala Sandro's proposal) for the RDF namespace wouldn't work, I don't think.

2.3 binaryXML-30

  1. binaryXML-30
    1. Action CL 2002/12/02: Write up problem statement about binary XML; send to www-tag.

[Ian]

TB: There seem to be real requirements out there to be able to send info around in a manner that is either (1) more compact or (2) more rapidly parsed. I am convinced by some usage scenarios. I am, however, unconvinced that there is a single format that will meet the needs of the various applications. There is work in this area in MPEG, but that's loaded with IPR problems. I think this should be a do-nothing unless somebody comes forward with a plausible candidate. I'd be reluctant to pour energy into this without a candidate that solves a broad range of problems and is Royalty-Free.
TBL: The discussion has been about decompression on the fly on small devices. The only time it's interesting - send message to someone with whom you share a knowledge of namespaces. [Scribe thinks TBL talked about partial evaluation as approach to problem in some cases.]This is not generic magic you can sprinkle over XML documents generally.
IJ thinks TB was referring to this email from Robin Berton.
[DanConn]
TBL's comments seem quite similar to my comments on trust boundaries and binary XML...
[Ian]
SW: Is this an arch issue or an engineering document?
DC: Engineering, but applies to a number of WGs.
TB: I think we should defend XML as a generalized information format; prevent people from retreating to specialized formats.
[TimBL]
The idea is that you can't compact general things without some header info which explains what the short things will mean. Compression is available for desktop-sized machines in the general case, so one does not need binary XML in that case. The need is when you have a small device which cannot hold the decomression tree. Then, a prior knowledge of the XML namespaces it uses would allow one to make a faster encoding.
[Ian]
PC: A number of people in Microsoft are interested in this problem; I am looking forward to CL action is completed.
[TBray]
what TimBL said... but compression effectiveness depends on msg size, with big enough msgs you could compress effectively & self-descriptively

2.4 Postponed

  1. IRIEverywhere-27
    1. Action MD and CL 2002/11/18: Write up text about IRIEverywhere-27 for spec writers to include in their spec.
    2. Action CL 2002/11/18: Write up finding for IRIEverywhere-27 (from TB and TBL, a/b/c), to include MD's text.

2.5 Findings in progress, architecture document

See also: findings.

  1. Findings in progress:
    1. deepLinking-25
      1. Action TB 2002/09/09: Revise "Deep Linking" in light of 9 Sep minutes.
    2. URIEquivalence-15
      1. TB's "How to Compare Uniform Resource Identifiers" draft finding.

        Completed Action DC 2002/01/06: I expect to review this (done).

  2. 6 Dec 2002 Editor's Draft of Arch Doc (new):
    1. Action CL 2002/09/25: Redraft section 3 based on resolutions of 18 Nov 2002 ftf meeting.
    2. Complete review of TBs proposed principles CP9, CP10 and CP11
Ian Jacobs for Stuart Williams and TimBL
Last modified: $Date: 2003/01/13 22:04:43 $