W3C home > Mailing lists > Public > www-tag@w3.org > December 2002

[Minutes] 2 Dec 2002 TAG teleconference (New issues: XML subsetting, Binary XML, metadata in URIs)

From: Ian B. Jacobs <ij@w3.org>
Date: Mon, 02 Dec 2002 19:53:11 -0500
Message-ID: <3DEC0077.20204@w3.org>
To: www-tag@w3.org


The minutes of the 2 Dec 2002 TAG teleconference are
available as HTML [1] and as text below.

  - Ian

Ian Jacobs (ij@w3.org)   http://www.w3.org/People/Jacobs
Tel:                     +1 718 260-9447

    W3C | TAG | Previous: 25 Nov teleconf | Next: 9 Dec
    2002 teleconf

             Minutes of 2 Dec 2002 TAG teleconference

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

1. Administrative

     1. Roll call: All present. SW (Chair), TBL, DC, TB,
        CL, PC, NW, DO, RF, IJ (Scribe).
     2. Accepted 18 Nov minutes
     3. Accepted 25 Nov minutes
     4. Accepted this agenda
     5. Accepted draft summary of TAG work from previous
        month (with changes suggested by DC and additions
        from this meeting). IJ to include TB's draft
        finding on URI comparison in summary.
     6. Next meeting: 9 Dec 2002

   1.1 Completed actions

      * Action IJ: 2002/11/25: Update
        rdfmsQnameUriMapping-6 to indicate waiting on WSDL
      * Action IJ: Remove "Status of discussions with WSA
        WG about SOAP/WSDL/GET/Query strings" from agenda,
        make sure that issues list whenToUseGet-7 tracks
        this open state.

   1.2 Meeting planning

      * [NOT DISCUSSED] Next TAG ftf: 6-7 Feb 2003 in
        Irvine, CA (USA)

   1.3 Other business?

    The TAG discussed its slide presentation from the W3C
    Advisory Committee meeting.
      * Action TB: Send proposed changes to SW slides to
      * Action NW: Create updated slides for XML 2002
      * Action IJ: Update SW slides with pointer to NW
        slides (and refer to TB comments).

2. Technical (75min)

    Possible new issues:
     1. SOAP and XML internal subset
     2. Binary XML
     3. Metadata in URIs
     4. Postponed issues
     5. Arch Doc/Findings

   2.1 SOAP and XML internal subset

    See message from Paul Grosso


           yes, please; I don't want to take this up until
           the XMLP WG has responded to a "don't subset
           XML" request.

           DO: I think this is an important arch issue. I
           think it should have been sent earlier to XMLP
           WG. But having said that, the topic of
           subsetting has come up before. I'm on the record
           of wanting a next generation of profiles. I
           think the TAG ought to bring up this issue and
           consider the arch ramifications of profiles of
           XML specs.
           TB: I agree with DO. The IETF's BCP says "don't
           do this." For the case of SOAP, I think they
           have overwhelming technical arguments for their
           design choice (namely, avoid risk of denial of
           service attacks). I think that in general,
           subsetting XML is probably not wise for the
           reasons cited by the IETF authors. There is a
           recurring desire of some groups to do this; that
           signal should be looked at.

           Timmit, you wanted to agree we should take up
           issue and to suggest that original WG should be
           heavily involved and/or in charge when a profile
           is made of any spec.

           TBL: I agree we should accept the issue. While
           there is a WG that is responsible for this work,
           I think it's important that that WG do the work.
           We should not establish the precedent that one
           group can profile the work of another (notably
           cross-organizational boundaries). We can discuss
           it, with an option to return to the XML Core WG
           with a request to produce a profile.

           DanCon, you wanted to express a preference for
           having PaulG/XMLCore make a request to XMLP WG
           before we accept this

           DC: If we accept this as an issue, can we
           immediately contact both WGs to ensure that they
           know they are represented?: One possibility: do
           this by email or in a teleconf. I would prefer
           that Paul write to the XMLP WG and get their
           reply on record.
           NW: There's a lot of editorial work, not much
           technical benefit, unclear political
           ramifications of such an exercise. By
           "political" I mean that it's not clear what
           buy-in would be obtained from vendors and parser
           authors, etc. I'm not sure that's really
           "political" but it's more than purely technical.
           DO: I think that Paul Grosso should ask the XMLP
           WG for their rationale, and that the TAG is
           interested in that reply. I believe that Chair
           of XMLP WG is interested in providing
           information on this topic.
           PC: On the IETF BCP - does this apply when XML
           used as the basis of a protocol?: TBL talks
           about profiles as though they were bad; but
           profiles happen all the time within W3C.

           I wonder if there are at least two profiles:
           "non-protocol" and "protocol".

           PC: I'm not sure that the TAG can do anything
           about on group profiling (or not profiling) the
           work of another group.

           I don't think TimBL suggested lockstep; I think
           he just meant that if XMLP wants to profile XML,
           the WG working on XML should get the right of

           PC: There's a long history on this topic (going
           back to Sep 2001, at least, see message on
           xml-dist-app) regarding SOAP. I think it is
           appropriate to tell Paul G to talk to the XMLP
           WG. We can give him some pointers to the public
           TB Proposal:

          1. We should officially respond to PaulG saying
             that there is some history and that it would
             be appropriate to direct his query to the XMLP
             WG to ensure that the evidence is brought out
             for review.
          2. Propose TAG adopts subsetXML issue, based on
             the fact that XML doesn't provide a means for
             subsetting. Some people (like me) think that
             it's bad to subset XML. But some groups still
             want to do this, and some groups have good
             reasons for doing so.

           hmm... I thought the subsetting XPath case was
           directly relevant. the name "subsettingXML"
           seems exclusive of that.

           Dan, what is "XML"?

           a language defined in the XML 1.0
           recommendation, I think.

           Is XML=XML 1.* + namespaces + xpath + dom +
           xquery + xslt?

           DaveO: XML is http://www.w3.org/TR/REC-xml

           TB: The XMLP WG has evidence that subsetting
           will be sometimes necessary.: It's not
           reasonable for SOAP 1.2 to wait for a revised

           DaveO: XML++ might include namespaces, base, et.

           DO: Friendly amendment to TB's (2). Not just an
           issue of subsetting XML, but rather among the
           family of XML specs.
           TB: Retitle as profileXML.: Change wording "XML
           family of specifications"
           DC: "Profiling W3C specs" would be fine.

           You don't conform to XPath. You conform to
           XPointer or XSLT.

           DC: Flavors of a language are evil. Sometimes
           you need profiles, but there is a cost to
           interoperability. Profiles are to be avoided.
           RF: What you want with a profile of XML is to
           make it possible to implement software.


           I agree with Tim's amended resolution of this
           item but I would like to see a clear statement
           of the "XML family of specification" issue.

           RF: General purpose servers implement HTTP
           differently from specific-purpose servers. There
           are limits on URIs, size of request header. Apps
           need to be able to define these things on their
           own. Not limits on the protocol, but limits on
           the implementation of the protocol.

           Re XPath, I guess you could also conform to the
           new DOM API + XPath.

           TB: I agree with DC - one of the good things
           about XML historically is that it's much more
           option-free than other specs. Clearly this
           approach is running into trouble. I've put a
           stake in the ground about which specs to group
           together (XML, namespaces, base) so that
           profiling not necessary.
           TBL: Things will break if some parsers
           understand entities and others don't.

           hmmm... sounds reasonable

           Timmit, you wanted to say that http example is
           more -- what happens if an http server doesn't
           implement HEAD?

           issue profilePlussesAndMinuses-NNN
           issue profilesNecessaryEvil-NNN

           PC: Wasn't this on the XML Core WG agenda at
           some point?
           DO: Yes, they are chartered to do this.
           TB: Maybe it suffices to say to the XML Core WG
           that we think this should be moved up their list
           of priorities.
           NW: No one I know of is chomping at the bit to
           address this; seems like a lot of work, without
           much promise of payoff. If we want this work
           done, we should ask the Core WG.
           TB: Don't phrase this as "Do XML 2.0". If we
           think there's a problem here (and I think
           evidence suggests there is), we could profitably
           invest some time in how we get a solution. Will
           be hard to disentangle tech from process issues.
           DO: This issue has also come up in WSA WG.
           NW: The major issues here are not technical.:
           The Core WG has discussed this.
           DO: What information can be conveyed here?
           TB: Let's toss this out into www-tag.
           NW: If we want to engage the Core WG, we should
           invite Paul Grosso to a meeting where this is

           DanCon, you wanted to propose:

           SW: I have concerns about our communications
           with other groups.
           DC: We should accept issue and PC/DO and NW
           should ask the groups how they want to be
           represented here.
           IJ: Title of this issue?

           I don't want us to send an appeal to www-tag on
           this front since I want the negotiatiation with
           the Chairs and WGs to occur first.

           TB: Whither and how to profile W3C
           specifications in the XML Family
           DC: I object to "in the XML Family"
           DO: I feel strongly about "in the XML Family"
           TBL: I feel that the profiling issue applies to
           other issues as well.

           he didn't say "feel strongly"; he (DaveO)
           observed that the XML family is what we've been
           talking about

           DO: I'd like to examine the issue w.r.t. the
           scope of things in the XML family of specs.
           TBL: If the comment is "necessary evil" then it
           applies to all our specs.
           CL: We have two issues (general and specific).
           SW Proposed: Accept profilesNecessaryEvil-NNN as
           new issue.
           DO: I object.

           I don't like it either

           Objections: PC, CL, TB.
           TB Proposed: xmlProfilesNecessaryEvil.
           CL: I don't like "necessary evil"; presupposes
           an outcome.



           Proposed: xmlProfiles.

           issue xmlProfiles-NNN: When, whether and how to
           profile the XML family of recommendation

           DC: Abstain.

           like daves

           Resolved: xmlProfiles. DC Abstains.
           Action IJ: Add to issues list xmlProfiles-NNN.
           TB suggests title "When, whither and how to
           profile W3C specifications in the XML Family"
           Action DO: Talk to XMLP WG about this new issue.
           Action NW: Talk to XML Core WG about this new

   2.2 Binary XML

    See messages from Robin Berjon, Paul Cotton (member
    only), Don Brutzman (member only)


           For accepting: DO, DC.
           Objections: TB
           Abstain: NW, RF.
           RF: I abstain, mostly because I wouldn't call it
           TB: Exactly, if it's binary, it's not XML.

           its not the XML serialisation format, true

           SW Proposed: Adopt binaryXML-NNN as an issue.
           Objections: TB
           Abstain: NW, RF, SW, PC

           proposed - binaryXMLInfoset

           PC: My rationale - I'm not sure what the
           community is asking for.
           CL: Discussion started before I could send crisp
           problem statement.

           I would like to be on the record as to why I
           would have supported this

           Supports binaryXML-NNN: DO, TBL, DC, CL

           I would like to take up this issue because it
           has been raised by so many parties too often,
           and no statment one way or the other exists
           about it. The community deserves such a thing.

           Action CL: Write up problem statement about
           binary XML; send to www-tag.
           TBL: Here's why I think we should take it up -
           it's been raised by a lot of people (e.g.,
           Web3D, who are users). The XML community has
           ruled it out of scope. If the TAG's conclusion
           is that it's better to do Y than binary XML,
           then we should say so clearly. If the answer is
           so obvious, we should state it clearly. If it's
           not, then we should unearth it and deal with it.

           considering changing my vote

           DO: Also an issue in the Web Services
           community.: I think the TAG could help out in
           this area.
           CL: For SVG we said "use gzip" but the mobile
           folks said that wasn't good enough; they have to
           store strings with whitespace preserved. They
           end up having 2 copies of the data.

           (because the DOM allows access t the original

           TB: I am profoundly against the notion of binary
           XML in general. However, having listened here,
           it's apparent that it's an issue that won't go
           away.: If it's a bad idea, we should say why and
           tell people how to solve problems in the real
           SW Proposed: binaryXML-NNN as a new issue.
           Objections: None.
           Abstain: RF, NW, PC
           Support: DC, CL, TB, DO, TBL, SW
           Resolved: Accept binaryXML-NNN as a new issue.
           Action IJ: Add binaryXML-NNN to issues list.

   2.3 Metadata in URIs

    See message from Ossi Nyk?nen.


           DO: I'm interested in the issue of versioning
           resources.: E.g., namespaces and versioning.
           TB: Notion of encoding metadata in a URI is
           broken. Versioning has application-specific

           Now RDF for metada is a good idea...

           memories of VMS filenames with ;version in the

           CL: If we universally thing this is a bad thing
           to do, we should say so loudly.
           SW Proposed: Accept medataInURI-NNN?
           IJ: Could be short if universal response is
           Resolved: Accept issue matadataInURI-NNN with
           note that TAG thinks the answer is "no" and will
           explain what to do instead.

   2.4 Postponed issues

     1. Status of URIEquivalence-15, IRIEverywhere-27.
        Relation to Character Model of the Web (chapter 4)?
        See text from TimBL on URI canonicalization and
        email from Martin in particular. See more comments
        from Martin.
          1. Action MD 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.
          3. Action TB 2002/11/18: Write a finding for
             URIEquivalence-15 on IRI relation to URI,
             different levels of equivalence. Done
     2. namespaceDocument-8
          1. Action NW 2002/11/18: Take a stab at
             indicating pros and cons for the various
             RDDL/RDF/Xlink designs arising from TB's RDDL
     3. rdfmsQnameUriMapping-6
          1. The Schema WG is making progress; they will
             get back to us when they're done. See XML
             Schema thread on this topic.
          2. Action IJ: 2002/11/25: Update
             rdfmsQnameUriMapping-6 to indicate waiting on
             WSDL WG. Done.
     4. uriMediaType-9:
          1. Action DC 2002/08/30: Write a draft Internet
             Draft based on this finding (Deadline 2 Dec).
             This action probably subsumes the action on
             TBL to get a reply from the IETF on the TAG
             finding. Done, TAG only.
             Action DC: Point to this draft on www-tag: "A
             Registry of Assignments using Ubiquitous
             Technologies and Careful Policies."
          2. Resolved: The TAG thanks Mark Baker for his
             contributions to this draft!
     5. fragmentInXML-28 : Use of fragment identifiers in
     6. xlinkScope-23 (5 minutes)
          1. Action SW 2002/11/18: Organize a
             special-interest teleconf for discussion of
             this issue on linking. Pending; see email from
             SW (TAG-only).

   2.5 Findings in progress, architecture document

    See also: findings.
     1. Findings in progress:
          1. deepLinking-25
               1. TB 2002/09/09: Revise "Deep Linking" in
                  light of 9 Sep minutes. Status of
          2. URI Comparison.
               1. Resolved: Link to TB's draft finding from
                  findings page. Action IJ: Link to this
                  from findings page.
     2. 7 Nov 2002 Arch Doc
          1. Action CL 2002/09/25: Redraft section 3 based
             on resolutions of 18 Nov 2002 ftf meeting.
          2. Action DC 2002/11/04: Review "Meaning" to see
             if there's any part of self-describing Web for
             the arch doc. Done.
          3. Complete review of TBs proposed principles
             CP9, CP10 and CP11

     Ian Jacobs, for Stuart Williams and TimBL
     Last modified: $Date: 2002/12/03 00:52:25 $
Received on Monday, 2 December 2002 19:53:13 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:32:35 UTC