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 profiles.

<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 messages).

<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 declaration.

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

* 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 insufficient).

<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 architecture?

<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 thing

<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 implementation

<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 insufficient.

<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 information.

<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 challenge.
      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) http://lists.w3.org/Archives/Public/www-tag/2002Dec/0130.html

<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 2002) http://lists.w3.org/Archives/Public/www-tag/2002Dec/0123.html

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

<TBray> thread starts at http://lists.w3.org/Archives/Public/www-tag/2002Dec/0123.html

<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 URI.

<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 XML.
  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 $