[
Lists Home |
Date Index |
Thread Index
]
"Richard Tobin" wrote:
>
> I think the best compromise is to say that documents labelled with a
> version other than 1.0 are not well-formed XML 1.0 documents,
Isn't this a direct contradiction of the 1.0 recommendation?
> but that
> an XML 1.0 parser may accept them.
Where one asserts that such a document is not well formed, isn't this a
contradiction in terms?
> This breaks no documents and no
> implementations, but it allows us to unambiguously state the version
> of a document. Can anyone see any problems with it?
>
It makes more sense to follow the recommendation's language and to expect a 1.0
parser to accept an otherwise well-formed document so long as the version number
conforms to production 26, and to expect that
1) A conforming 1.x parser also have 1.{y | y < x} modes, and that
2,3) the parser interpret the version numbers declared in the document entity
and in any external parsed entities to determine the respective syntax, and that
4) such a parser fail on an entity which does not conform to its declared
syntax, and that
5) a programmatic means is provided to specify a default value for and/or
constraints on an entity's version absolutely and with reference to the version
of the referencing entity.
Rick Jelliffe wrote:
>
> From: "Jeff Rafter" <jeffrafter@defined.net>
>
> > This makes a great deal of sense to me. I am not having an issue with 1.1
> > parsers that can parse 1.0 documents (they simply support two versions). I
> > have a problem with 1.0 parsers that parse 1.1 documents by chance.
Is not a document labelled with a version other than 1.0, and which conforms to
all 1.0 well-formedness constraints a well-formed 1.0 document by definition?
Which a conforming 1.0 parser is required to accept. By definition rather than
by chance?
> I agree
> > with Elliotte Rusty Harold that if a document is compatabile in both
> > (especially if it is designed with that intent) it should be labeled 1.0--
> > if that is the effect the author wishes to achieve.
>
> How does a system do this? You can only know which rules are being
> used when the pieces of the document are already available, which requires
> that the header will be generated last, or that it goes through some
> filter. Not efficient.
Wouldn't it suffice to introduce entity boundaries for shifts in syntax version
just as one would have to for shifts in character encoding?
...
|
