OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] The version number in XML documents

[ Lists Home | Date Index | Thread Index ]

From: "Richard Tobin" <richard@cogsci.ed.ac.uk>

> >And two infosets (if S production is modified then there needs to be
> >an infoset item telling you whether the 1.1 infoset is being used or
> >the 1.0 infoset, I gather?)
> There hasn't been any decision yet on changing the Infoset spec as a
> result of XML 1.1.

Has there been a decision that there will not be a different infoset?
That would be great.

> I'm not sure whether we need the distinction of a "1.0 infoset" vs. a
> "1.1 infoset".

I hope the WG will be generous in considering what is an erratum 
and what is new. (Michael Kay seems to wish the reverse!)

The Core WG has already set a precendent by removing the 
checks for language from the spec with an erratum, which did not
cause a ripple.  Perhaps this could be made into a general policy:
that backwards-compatible changes which relate to tracking external
standards will be dealt with by errata rather than by minor versions.

>  1.1 will change which XML documents have infosets
> (because it will change which documents are well-formed) and some
> documents labelled 1.1 will have different infosets than they would if
> they were labelled 1.0 (an NMTOKENS attribute containing a NEL will be
> normalized differently, for example), but a given document will have a
> single infoset.

No-one could have used NELs in an NMTOKENs attribute in XML 1.0,
surely.  If they are using NMTOKENs, then they must be validating,
so the NEL would be an error.   
And if the WG takes the route of just handling NEL like CR, there
would be few flow-on effects.

> On the other hand, some infosets will not be serializable as 1.0
> documents (e.g. because they have new name characters).  Do we need
> something to indicate this?  

The people who need the extra characters will have to put up with 
having a different generation deployed for a long time. There is the
danger that an XML 1.1 would not be supported, because of being
disruptive and not adding value needed by the great unwashed majority.

The best way to meet the goals of getting support for Unicode 3.1
out faster may be *not* to go 1.1 but just update 1.0 (strictly in
areas relating to tracking Unicode) with a suitable caution
that this will take a while to be deployed and that old parsers
may fail. 

Rick Jelliffe


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS