Bjoern Hoehrmann <derhoermi@gmx.net> wrote:
>In the good old days the validator confessed it's limited XML support by
>pointing at http://www.jclark.com/sp/xml.htm IIRC. Since the XML support
>is obviously not any better than before, the not should be reassembled.
The limitations in OpenSP, the XML Parser we now use, are:
[[[
OpenSP does not enforce the following XML constraints:
* XML constrains processing instructions with a target matching
[Xx][Mm][Ll], both in terms of where they can occur and their content.
* XML does not allow a parameter separator that is adjacent to a
delimiter to be omitted.
* XML has constraints on the use of & in parameter literals. In SGML
terms, XML says that the ero delimiter is recognized in a parameter
literal, and that it must be followed by an entity reference, but
the entity reference is not expanded.
Line ends are normalized using SGML conventions to a CR/LF character
pair rather than using the XML convention of a single LF character.
OpenSP does not enforce XML's rules on not continuing normal processing
after an error. Applications can enforce these if they choose.
Web SGML Adaptations Annex
OpenSP's support for XML is based on Annex K of ISO 8879 (the Web
SGML Adaptations Annex). The following features of Annex K are not
yet implemented:
* #IMPLICIT document type name
* Attribute list declarations for #NOTATION #ALL and #NOTATION
#IMPLICIT
* #ALL and #IMPLICIT in model groups and exceptions
]]] - http://openjade.sf.net/doc/xml.htm
Neither of which are relevant to the case you cite, and for the most part
they are rather obscure bits AFAICT. That it does not detect leading
whitespace is simply a bug (unfortunately, it's one that doesn't look like
it will be fixed very soon).
--
Interviewer: "In what language do you write your algorithms?"
Abigail: English.
Interviewer: "What would you do if, say, Telnet didn't work?"
Abigail: Look at the error message.