Lists Home |
Date Index |
From: "Richard Tobin" <email@example.com>
> >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