W3C | TAG | Previous: 9 Dec teleconf | Next: 6 Jan 2003 teleconf
Nearby: IRC log | Teleconference details · issues list · www-tag archive
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.
<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.
<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
<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?
<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!
<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.
<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.
See also: findings.