W3C home > Mailing lists > Public > www-tag@w3.org > January 2003

[Minutes] 13 Jan 2003 TAG teleconf (XInclude issue, xmlProfiles-29, namespaceDocument-8, binaryXML-30)

From: Ian B. Jacobs <ij@w3.org>
Date: Mon, 13 Jan 2003 17:01:46 -0500
Message-ID: <3E23374A.8020402@w3.org>
To: www-tag@w3.org

Hello,

Minutes from the 13 Jan 2003 TAG teleconf are
available as HTML [1] and as text below.

  - Ian

[1] http://www.w3.org/2003/01/13-tag-summary

========================================================

    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

      * xmlProfiles-29
      * namespaceDocument-8
      * binaryXML-30

   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:01:53 $


-- 
Ian Jacobs (ij@w3.org)   http://www.w3.org/People/Jacobs
Tel:                     +1 718 260-9447
Received on Monday, 13 January 2003 17:05:02 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:47:15 GMT