[Minutes] 16 Dec 2002 TAG teleconf


Minutes available as HTML [1] and as text below.

  - Ian

[1] http://www.w3.org/2002/12/16-tag-summary.html

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


    W3C | TAG | Previous: 9 Dec teleconf | Next: 6 Jan
    2003 teleconf

            Minutes of 16 Dec 2002 TAG teleconference

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

1. Administrative

     1. Roll call: SW (Chair), TBL, DC, DO, TB, NW, RF,
        PC, IJ (Scribe), Paul Gross. Absent: CL.
     2. Accepted 9 Dec minutes
     3. Accepted this agenda
     4. Next meeting: 6 Jan 2003
     5. Include title page dates in first three findings
        per request from Mark Baker?
        Resolved: Yes. Title page date should correspond
        to the date of a TAG meeting. May include a last
        revised date; indicate in status section that we
        don't expect to modify in place.
     6. Meeting planning: Stuart continued to work on
        scheduling a meeting in January to discuss XLink.

   1.1 Completed actions

     1. Action SW 2002/12/09: Invite Paul Grosso to a
        future meeting
     2. Action SW 2002/12/09: Thanks XMLP WG

2. Technical

     1. xmlProfiles-29
     2. URIEquivalence-15
     3. namespaceDocument-8

   2.1 xmlProfiles-29

     1. xmlProfiles-29
          1. Action DO 2002/12/02: Talk to XMLP WG about
             this new issue.
          2. Action NW 2002/12/02: Talk to XML Core WG
             about this new issue
          3. Action NW 2002/12/09: Write up a first draft
             of the TAG position

    <Ian> NW: If there is a way for specs to refer
    normatively to a doc that describes a subset of xml,
    that would be useful. We should attempt to do this by
    editorial revision of XML 1.1. So that we can produce
    a spec that describes a standalone version of XML, and
    have another document that says "here's what else to
    do to get back full XML."

    <Ian> TB: This issue is becoming more visible (see,
    e.g.,sourceforge discussion).

    <DanC> sourceforge tracks security exploits? ah;
    security focus..

    <Ian> PG: I think it's fair to say that the XML Core
    WG last discussed in Feb 2002.

    * DanC wondersi if Norm's comment was recorded
    accurately; perhaps I should queue myself to ask

    <Ian> PG: The group's sense was not being eager to
    jump into a new version of XML. Glad this discussion
    happening outside of XML Core for now; will make our
    job easier (i.e., if the community figures out a
    limited scope, it'll make the XML Core WG's job
    easier). The XML Core WG is willing to work on this.
    Need to figure out in which spec this would happen
    (1.2? A W3C Note?)

    <Ian> PG: Core WG participants have expressed opinions
    from nothing -> minimal -> redoing XML right.

    <Ian> TB: Launching an XML 2.0 project would be
    disastrous. What's going on in XMLP is symptomatic.
    Custom subsets hurting interoperability

    <Ian> DO: It seems that we have a difference of
    opinion about what it means to be XML. Some people
    think of XML as "an XML spec", others think of XML as
    XML 1.x + other things.

    <Ian> TB: Anybody who will use XML will use namespaces
    and likely have recourse to the infoset. It's arguable
    that putting the pieces in one spec will make people's
    lives easier.

    <Ian> PG: I think that it would be very different
    developing a minimal XML and a mechanism for
    subsetting XML.

    <Ian> TB: I don't like run-time profiles for XML. My
    preferred approach is one hard-wired subset. xml:id is
    a new feature and thus out-of-scope IMHO

    <Ian> DC: I'd like any TAG finding to start "Profiles
    are evil. However, in some cases they are merited...."

    <PGrosso> Cf. xml:id, that is the one thing I'd have a
    hard time saying cannot be considered in any "new" XML

    <TBray> slippery-slope, that's all

    <Ian> TB: I think the TAG should be specific. We
    should do the things that would benefit the community,
    based on several years' experience.

    <Ian> TBL: Consolidation of specs is a separate issue.
    Are we (otherwise) just talking about removal of the
    external subset?

    <Ian> TB: Could be removal or a way to get rid of
    billion laughs bug. (Recursive explosions in run-time

    <TBray> anyhow, I'm far from convinced that xml:id is
    really needed

    <Ian> DO: I generally agree with TB here. In Web
    Services, we have run into a problem of the notion of
    doing ID attribute. Lots of Web Services vocabs have
    created some kind of ID attribute.

    <DanC> doc#foo doesn't work without xml:id.

    <TBray> it works if you serve it as anything but
    application/xml. And application/xml doesn't seem to
    be useful/used in practice

    <DanC> hmm..

    <Ian> PG: xml:id and entities are the 2 things the XML
    Core WG has told people to do in the internal subset.
    We can either (1) find a way to get rid of internal
    subset or (2) find a way to use safely. I have heard a
    trend to no character entities.

    <Zakim> PGrosso, you wanted to mention that xml:id and
    entities are the 2 things the XML Core WG has told
    people to do in the internal subset.

    <DaveO> TB, seems like application/foo+xml that
    re-used xml:id would be useful.

    <TBray> to say (1) nobody else is gonna take on the
    entity/char-ref problem, and (2) anybody who makes an
    XML language defines an ID attribute

    * DanC thinks (2) is a pretty good argument for xml:id

    <Ian> NW: I am flatly opposed to the idea of changing
    rules for how entities are declared. I think that this
    redefining would cause lots of problem, be hard to
    explain, cuase backwards compat issues. I hear people
    asking for one profile: one that doesn't have an
    internal subset. I would like no new features.

    <TBray> camel's nose indeed

    <Ian> PC to DC: Are you against us doing an XML
    version that is XML*?

    <Ian> DC: I want the cost of profiling acknowledged
    every time it's done.

    <Ian> PC: I am favorable to the idea of creating an
    XML-SW spec (or something like it). I ack DC's point
    about cost of profiles.

    <PGrosso> What is the advantage of combining specs at
    this point? It's too late to make the spec easier to
    read for implementors.

    <Ian> TB: XML-SW has fewer options than XML 1.0.
    Nobody in the world is going to take on the job of
    defining a new way of defining character entities (or
    other kinds).

    <Norm> We can't get rid of existing processors, so the
    fact that the subset is smaller doesn't mean there's
    fewer options; there can only be more options

    <Ian> TB: On xml:id - every xml language I know of has
    an ID attribute.

    <PGrosso> Tim, does that mean that we should do it
    (define entities) or not do it?

    <Ian> TB: In almost every case, it happens to be named
    "id". IDs won't go away.

    <Norm> If you want an ID, use an internal subset or a
    schema language.

    <Ian> TB: xml:id is a plausible idea, but I agree with
    NW - no new features.

    <Roy> I don't see how anyone could consider "entities
    must not be parsed or expanded inside entity
    declarations" a difficult to understand requirement. I
    am seriously considering asking that Xerces implement
    that in spite of the XML standard, because in this
    case XML is broken for all implementations. Unsafe
    code is never worthwhile outside of weaponry, and even
    then only when it is designed to be unsafe.

    <DanC> ooh... yes, fix xpointer so that #bar means the
    xpath expression @id='bar'

    <Ian> RF: I think it's a bug fix to XML : don't expand
    entities to be expanded in the declaration section.

    <Ian> NW: There are cases when cross referencing
    entities is a good / useful thing.

    <DanC> yeah; it would change the meaning of documents
    that are fairly widely deployed. bad news.

    <Ian> TB: The cost of doing this in XMLP and other
    applications is unacceptably high. A profile would not
    make XML 1.0 go away.

    <Ian> NW: I'm happier with an onion that has neither
    references to external or internal subsets. And built
    other XML versions on top of that. If you want what
    XML 1.0 does, use XML 1.0; If you want something else
    use this other [not yet defined] spec... We can define
    XML 1.1 as two specs (a core with no decls and a full
    1.1 that has the rest).

    <Ian> TB: version attribute.

    <Ian> NW: This can't be accomplished without revving
    the version number in XML 1.0 (e.g., 1.2a, 1.2b....)
    Or one could add a pseudo-attrib to the XML

    <Ian> TB: A profile would be subject to AC approval,

    * tim-lex didn't see why you had to label the subset
    with xml 1.0

    <Ian> PG: The XML Core WG should ask the AC to make
    clearer that we should pursue this (charter language

    <Ian> TB: We should document what we feel to be
    cost-effective and send to the AC.

    <Ian> DO: I'm interested in the TAG talking to the AC
    (e.g., about pursuing work).

    <Ian> PC: What's the relationship of this to Web

    <Ian> NW: Before we ask the AC to do anything; please
    wait until I finish my action item and that the TAG
    agree to precisely what we want to do.

    <Ian> DC: It's been suggested that our arch doc say
    "use xml for doc formats." One reason is that it has a
    self-similar syntax. DTDs make it a lot self-similar,
    however. There is a connection to architecture:
    self-similar syntax; minimalism.

    <Ian> TBL: The Arch Doc says it's a good thing to
    build networks by using messages; and a good idea to
    use xml to do that. As it stands, there's an obvious
    problem (due to denial of service attacks).

    <TBray> DO: message to AC from TAG pointing out that
    we've got a problem here. Going to a subset/profile
    architecture helps with the architecture

    <TBray> DO thinks the AC will find this compelling

    <TBray> SW: proposal to wait for Norm's action and
    consider going to AC thereafter

    <Norm> My point was that we should agree amongst
    ourselves, in writing, about what we're asking the AC
    to do

    <TBray> DO: emerging conensus that this is a good

    <TBray> Norm: will get this to us this week

    <TBray> PG: would be useful, when handing to AC & then
    core...Indication as to what we might call this (1.x,
    2.x) and schedule. Could Norm include suggestion for

    <Ian> IJ: What form would communication take with AC?

    <Ian> DC: I think this would take the form of an
    Activity Proposal.

    <Ian> SW: Thanks to PG for joining us!

   2.2 URIEquivalence-15

     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. TB's "How to Compare Uniform Resource
             Identifiers" draft finding.

    <Ian> TB: The hard problem this reveals is that a
    close reading of 2396 makes it clear that you can't
    tell whether %2a means the same other thing %2a in a
    different encoding. Will this be fixed, RF?

    <Ian> RF: I'll try to clarify what it means. I have
    some comments on uri-comp-2. I'll send those in today.

    <Ian> DC: You compare URIs with strcmp. It doesn't
    matter what the URI is. Server gets to choose what the
    URI string is. Only the server knows what %61 means.

    <Ian> TB: I have an example that shows strcmp is

    <Ian> [PC leaves]

    <Ian> * http://dir/a

    <Ian> * http://dir/%61

    <Ian> DC: Those are strings of different lengths;
    different URIs. Practice of Web browsers is heuristic.

    <Ian> TB: False negs are built into the system. But
    false positives should be avoided.

    <Ian> DC: /index.html and / might be considered equal
    by google, and that could be a false positive.

    <Ian> [Discussion of RFC2396 clarification]

    <Ian> RF: Schemes don't define what's reserved in each
    path since that is not standardized generally.
    Generally the specs shouldn't require things that the
    software doesn't implement. Within namespaces, there
    are chars that are used in a reserved way, that are
    not part of the generic set of reserved characters.
    Client is not allowed to %-escape something that isn't
    already in the form of data. Client can't take an
    existing URI and decode it without loss of

    <Ian> TB: I think the action item is to watch for
    feedback on this finding. In a week or so, I'll turn
    over to IJ to beautify.

   2.3 namespaceDocument-8

     1. 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
               1. RDDL Proposal from Tim Bray.
               2. RDDL Proposal from Chris Wilper
               3. RDDL Proposal from TBL
               4. RDDL Proposal from Jonathan Borden

    <DanC> # Re: The RDDL challenge Tim Berners-Lee (Mon,
    Dec 09 2002)

    <Ian> DC: As I said last week, I will oppose anything
    that says that putting an XML Schema at end of
    namespace URI is broken. I think that RDDL is a
    distraction. It suggests that there's nothing that's
    ok to put there now.

    <Ian> TB: Good exchange between DC and me on www-tag
    this week.

    <Ian> DC: W3C has used RDF, Schema, and XHTML to
    document a namespace.

    <DanC> # what's wrong with using XML Schema/HTML/RDF
    to document namespaces? Dan Connolly (Mon, Dec 09

    <Ian> DC: XML Schema and RDF Schema are ok by me.

    <TBray> thread starts at

    <Ian> DC: There is no format that I would advocate for
    all uses

    <Ian> DO: What are the criteria that you would use to
    decide what format to use?

    <Ian> DC: If you are doing an RDF vocabulary, using an
    RDF schema would be useful.

    <DanC> RDF schemas with CSS work pretty well, in
    recent experience. RDF schemas can even meet the "I
    wanna look at it in my browser" goal.

    <Ian> TBL: I think that we need to realize that
    different applications will have different sorts of
    needs. You may not want an indirection in all cases. I
    think it's reasonable to write down some best
    practices. I think RDDL is reasonable, but I'd rather
    RDDL be yet another format.

    <Ian> DO: I've heard one criterion - if doing RDF, use
    RDF assertions for namespace doc. Seems like we may
    cause more confusion. I think this makes the problem
    worse by allowing multiple different types of formats
    for namespace docs.

    <Ian> DC: Nobody has written the last work on how to
    choose a programming language. Why is this different?

    <Ian> TB: A really important use case is someone
    wishing to find documentation the first time they
    encounter a namespace. Schema annotations don't work
    for me; I don't have a schema processor.

    <Ian> TBL: An XML schema should have proper
    descriptions; but they may not be viewed by people.
    RDF + CSS can provide human-readable and
    machine-readable solution.

    <Ian> DC: Is CSS considered exotic machinery? See info
    about syndicating W3C home page. This is an example of
    RDF + CSS.

    <Ian> TB: If you can do that, that's a good outcome.
    Constraints: (1) Need to be able to include N links to
    other resources and (2) Need to be able to point a
    browser at it for human-readable descriptions.

    <Ian> DO: In my opinion, if we don't standardize on a
    format, I want to return to the position that you
    SHOULD NOT put something at the end of a namespace

    <Ian> NW: The namespace spec just says it's not a goal
    to put something there.

    <Ian> DC: I'm fine with RDDL; just don't say there's
    anything wrong with an XML schema there. I still think
    that TB + NW to write up options is a good idea.

    <Ian> TB: I think XML schema is a bad choice since
    lots of machinery is required.

    <Ian> DC: It's easy to find annotations; you don't
    need a schema processor.

    <Ian> IJ: I think that I hear agreement about the
    desirability of TB's constraints, that there are
    different formats for achieving goals in different
    cases. I hear DO saying that N formats will not
    satisfy him.

    <Ian> TBL: You have to assume that on top of schemas,
    or html, there are conventions for including
    additional info. You have to give people the benefit
    of the doubt; that problems can be addressed. You need
    to assume certain conventions (e.g., for putting an
    RDF schema inside an XML schema, etc.).

    <Ian> TB: I believe we have enough input to do so.

    <Ian> SW: I think we are awaiting NW's output in order
    to proceed.

   2.4 Postponed

     1. binaryXML-30
          1. Action CL 2002/12/02: Write up problem
             statement about binary XML; send to www-tag.
     2. fragmentInXML-28 : Use of fragment identifiers in
     3. 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. Completed action SW 2002/12/09: Contact the
             Hypertext Coordination group, Vincent Quint
             chair, as part of organizing linking meeting.

   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.
     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: 2002/12/16 22:26:35 $

Received on Monday, 16 December 2002 17:31:48 UTC