Re: I need help with error message 'xml declaration not at start of external entity'

Perhaps you're not reading the same XML spec I am, because to me it is
ABSOLUTELY clear that whitespace is not allowed to come before the XML
specification:

The primary rule states this:

document	   ::=   	 prolog  element  Misc*

Note that a prolog is defined as so:

prolog	   ::=   	 XMLDecl? Misc* (doctypedecl  Misc*)?

Which says the XMLDecl is optional, but if present, it would be defined as so:

XMLDecl	   ::=   	'<?xml' VersionInfo  EncodingDecl? SDDecl? S? '?>'

and since whitespace (the term 'S' as used in this ruleset) does not
appear to be mentioned until the end of the XMLDecl, it makes it
pretty clear its not allowed at the beginning.

If you don't like this behaviour, you'd be better off lobbying the W3C
to change the spec, but as it stands, eXpat is quite clearly enforcing
the rules of validity for an XML document.

Note that the rules also make it quite clear that you don't HAVE to
have a XMLDecl, and thus without it your document can have as much
initial whitespace as makes you happy...  (I have tested this with
eXpat and it works fully as expected.)

Nick


On Fri, Jun 20, 2008 at 1:02 PM, Steve Fogoros <[email protected]> wrote:
> I'm using the PHP module XML Parser under PHP version 4.4.0.
>
> I get the referenced error due to new lines before the preamble.
>
> I've searched the error message and reviewed the w3c spec for
> information on xml parsing. I haven't found anything that explicitly
> states what a parser should do about leading white space outside of the
> xml document. I've also noted that there are many failures of this type
> reported on WordPress and RSS feed forums. In all cases, the correction
> seems to be altering the provider application to submit the xml document
> without any leading characters before the preamble.
>
> My question is: does the xml spec explicitly specify that there be
> nothing other than the preamble at the beginning of a well formed xml
> doc? Is this something that shoud/could be addressed in the parser (it
> sure would eliminate a lot of failed implementations)?

-- 
Nick MacDonald
[email protected]