Cart
[Home] [By Thread] [By Date] [Recent Entries]
On Thu, Jun 21, 2001 at 11:02:42PM -0700, Tim Bray wrote: [...] > Then another potential problem: if you decide to push XML > past version 1.0, why not take the opportunity to pour > in namespaces? Interesting. Since the bulk of the newly specifications produced are using XML-1.0 + Namespace + Infoset as their base platform, the idea of making a bag of those, plus the updates to unicode and label it with version="2.0" would have the merit to put upfront the real level of processing and standard required. Not all applications would require it, but the gap is large enough the it's worth going through the revision process. But it would not requre efforts on the same scale than what XML Blueberry would require, it's larger. > And fix the white-space handling? And... Hum, could you be a bit more explicit ? > On the other side, we should consider the practicalities > and costs of upgrading (or not) the installed base in the > face of the deployment of data encoded in XML Blueberry. > > I.e., let's keep this pragmatic. Sure, basically the changes suggested in Bluberry are small from a code point of view (add a few tables and change the space definition), the problem is interoperability risks. I think there is already in straight XML 1.0 an interoperability risk at the encoding level. I would personaly for the Unicode upgrade prefer to piggyback it on the encoding="" attribute, I admit it is not really clean since it uses the label for the encoding definition to define the actual character set allowed, but it would allow to express the fact that a given document requires support of a given level of Unicode without modification of the XML spec. To allow the decoupling XML/Unicode without a big change in the infrastructure migh be considered good or bad, but this might be a way to introduce it smoothly. Daniel -- Daniel Veillard | Red Hat Network http://redhat.com/products/network/ veillard@r... | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ Sep 17-18 2001 Brussels Red Hat TechWorld http://www.redhat-techworld.com
|
