tag:blogger.com,1999:blog-6082261199073042821.post6300053428641029584..comments2023-08-05T19:55:17.072+01:00Comments on David Carlisle: XML 1.0 Fifth EditionDavid Carlislehttp://www.blogger.com/profile/12909254806316189772noreply@blogger.comBlogger7125tag:blogger.com,1999:blog-6082261199073042821.post-37898774106250750902008-12-19T22:15:00.000+00:002008-12-19T22:15:00.000+00:00Tom, note that none of this is about program-gener...Tom, note that none of this is about program-generated XML: your program knows what it's generating, and has no need for silly warnings: don't generate XML that uses non-ASCII characters in names or ID values and you'll be fine -- and if you are a native speaker of English and writing a program with XML as an interchange format, this is both the usual approach and very sensible.<BR/><BR/>As to whether ISO has made changes to specifications, of course they have; there may or may not have been retrospective changes to C99, I don't know -- sometimes such changes are published as "normative errata" and on at least one occasion for an ISO spec as a "technical corrgendum".<BR/><BR/>I personally hope we don't start releasing larger changes in this way; the change to the version number rules introduced in XML 5e may mean we could do an XML 1.2 at some point in the future and have it actually fly. But we aren't there today.<BR/><BR/>The actual impact on other specifications, including MathML, XSLT, XPath, XQuery, SVG and others, remains to be seen. Specs that have a fixed vocabulary, such as SVG, might be affected by ID values, although it's unlikely: for the most part, the people needing to use the new characters will at first know what they are doing, and by the time others catch up we hope for widespread deployment. Specs, like XQuery, that rely on XML names as part of their syntax, mostly also allowed the use of XML 1.1. And it turns out that some XSLT 1 processors at least already accepted the characters from XML 1.1. So pragmatically it may fly, even though everyone knows metal cylinders can't take off the ground :-)<BR/><BR/>LiamLiam Quinhttps://www.blogger.com/profile/07191558941418599733noreply@blogger.comtag:blogger.com,1999:blog-6082261199073042821.post-55678620734933407832008-10-24T22:53:00.000+01:002008-10-24T22:53:00.000+01:00I'm a total outsider to this discussion (came here...I'm a total outsider to this discussion (came here from a Java programming blog), but the proposed change seems disturbing to me.<BR/><BR/>If I were working on an end user application using a XML 1.0 5th edition parser, I'd want to put a big bold warning up front in my user documentation: any XML 1.0 data this app produces may or may not work with applications targeted to XML 1.0 4th edition or earlier. Not fun. Vendors will have to make this qualification to their users and quite possibly put warning annotations in their data -- which is supposed to be the purpose of a version number in the first place.<BR/><BR/>I totally agree that XML should allow Unicode data in element and attribute names, but this is a strange way to do it. The reasoning I've read is basically "people aren't adopting XML 1.1, so we're going to make a change to XML 1.0". It seems disingenuous to me. I can't imagine such an incompatible parser change being retrofitted to, say, C99. If we need the features of XML 1.1, we should demand applications to use XML 1.1.<BR/><BR/>This doesn't affect me (yet), and other people have expressed my reservations in a better way, but I have to get it out there.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6082261199073042821.post-87819168715834886462008-10-17T01:50:00.000+01:002008-10-17T01:50:00.000+01:00. I should have added that wrt XPath 1, the situat...<I>. I should have added that wrt XPath 1, the situation is perfectly clear: The normative definition of paths references the definition of names in the _undated_ version of XML Namespaces, which in turn references the definition of name characters in the _undated_ version of XML 1.0,</I><BR/><BR/>Even here, things are not so clear. The reference to Name in the text of the namespace spec is linked to the undated XML rec, however the only normative reference to XML from XML namespaces is to the dated 4th edition.<BR/><BR/>I suppose you could say that again referencing the dated and undated version of xml 1.0 is a bug in the namespace spec, a bug shared with svg, xml canonicalisation, xpath 2, xslt, xhtml 1, ...<BR/><BR/>Would you agree that it is clear that any document using the new characters can not be used with XSD 1.0 as both parts 1 and 2 make normative references to the dated 2nd edition of xml 1.0?David Carlislehttps://www.blogger.com/profile/12909254806316189772noreply@blogger.comtag:blogger.com,1999:blog-6082261199073042821.post-31884642368763409942008-10-16T12:14:00.000+01:002008-10-16T12:14:00.000+01:00Henry, I think your answer is deeply troubling. Yo...Henry, I think your answer is deeply troubling. You imply that for specifications that happened to have referenced a dated spec, it is clear that the original production applies.<BR/><BR/>So the answer to the question "can I use a new character in an ID" does, by your interpretation, depend on the fine print of the references section of the language being used.<BR/><BR/>Implementations are <EM>not</EM> going to do that. If you are using id() in xpath or similar functionality in other API, or simply just dtd or xsd validation, software is going to use the same xml parser for all xml languages, it is not going to switch in an xml 4th edn parser just because it has to validate IDs in a fooML document and fooML references the 4th (or 1st) edition.<BR/><BR/>So in practice all users will have to ignore the specifications and just test on an application by application basis to see what has been implemented. This is bad. It goes completely against the point of having a standard at all.<BR/><BR/>You say<BR/><BR/>on that day new names become conformant in XPath 1.0 paths, and implementations may choose to upgrade.<BR/><BR/>But that is not really an accurate description of the situation (as you interpret it). What your interpretation says is:<BR/><BR/>on that day new names become conformant and any Xpath 1 implementation that raises an error on such names is non conformant. There is no "choice" involved here, You have deliberately removed choice by making the change in place.David Carlislehttps://www.blogger.com/profile/12909254806316189772noreply@blogger.comtag:blogger.com,1999:blog-6082261199073042821.post-25673790992574517872008-10-16T11:17:00.000+01:002008-10-16T11:17:00.000+01:00I feel a bit like I'm contributing to one of t...I feel a bit like I'm contributing to one of the US election blogs---the ratio of heat to light is a bit off where it should be. Here's what David asked, and I answered, wrt XPath:<BR/><BR/> > Could you answer a simple yes/no<BR/> > question, as to whether on the day<BR/> > the 5th edition is published whether<BR/> > an xpath statement that uses xpath<BR/> > with a "new" Name is conformant to<BR/> > the W3C specifications or not?<BR/><BR/> > XPath2 references<BR/><BR/> > World Wide Web Consortium. Extensible<BR/> > Markup Language (XML) 1.0. (Third<BR/> > Edition) W3C Recommendation. See<BR/> > http://www.w3.org/TR/REC-xml<BR/><BR/> Well, that's a problem, isn't it :-) ?<BR/> It _names_ a specific version, but<BR/> _points to_ the undated version. If<BR/> you take the name as definitive, then<BR/> it remains conformant. If you take the<BR/> pointer as definitive, it could be seen<BR/> as becoming non-conformant.<BR/><BR/> I say 'could be', because (and my<BR/> colleague Michael Sperberg-McQueen is<BR/> the expert on this, I'll try to channel<BR/> him on this), specs which (name and)<BR/> refer to undated versions should do so<BR/> in a way which allows implementations<BR/> to track the resulting changes in an<BR/> implementation-defined way, that is,<BR/> all they have to do to be conformant is<BR/> to identify which version they are<BR/> (currently) supporting. That makes<BR/> sense to me.<BR/><BR/>So, the reason I was equivocal was _not_ because the situation wrt XML 1.0 is unclear, or broken, but because there's a bug in the XPath 2 spec. I should have added that wrt XPath 1, the situation is perfectly clear: The normative definition of paths references the definition of names in the _undated_ version of XML Namespaces, which in turn references the definition of name characters in the _undated_ version of XML 1.0, so yes, if XML 1.0 5th edition is published as a REC, on that day new names become conformant in XPath 1.0 paths, and implementations may choose to upgrade.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6082261199073042821.post-20682688142173156672008-10-16T08:35:00.000+01:002008-10-16T08:35:00.000+01:00David hiWell said. This is potentially a very bad ...David hi<BR/><BR/>Well said. This is potentially a very bad development for XML users.<BR/><BR/>Do you think it is possible to work around this (and other) problems with formal profiling: http://is.gd/4arN ?<BR/><BR/>And would you be interested in editing such a standard? :-)<BR/><BR/>- Alex.Alex Brownhttps://www.blogger.com/profile/12566145758707210809noreply@blogger.comtag:blogger.com,1999:blog-6082261199073042821.post-28128552420563628252008-10-16T06:39:00.000+01:002008-10-16T06:39:00.000+01:00One result of this terrible decision is that it wi...One result of this terrible decision is that it will be impossible to claim conformance to any W3C recommendation anymore. I have been considering how to do this for Gestalt 1.1 (when it's ready).<BR/><BR/>The only formulation I could come up with is something like:<BR/><BR/>"conforms to the 127th edition of XSLT 2.0, as published on 23rd November 2203".<BR/><BR/>That way no one could prove me wrong until long after I'm dead. Of course, such a declaration is useless for users - they don't know where they stand.<BR/><BR/>So a practical consequence is that I will make no further attempts to conform to W3C recommendations, and do whatever I feel like.<BR/><BR/>Of course, XML 1.0 fifth edition is illegal (it's a straight lie to call it XML 1.0). That is, I believe a determined attempt to challenge it in the courts could yield money.Colinhttps://www.blogger.com/profile/09240704815981280608noreply@blogger.com