Re: [xml] how do I...

On Wed, May 25, 2005 at 09:43:50AM -0500, Eric Haszlakiewicz wrote:
On Tue, May 24, 2005 at 06:01:00PM -0400, Daniel Veillard wrote:
  By the definition of XML this is not possible. Packing multiple
XML document on a single stream without out of band markers is a frequent
but huge design flaws. The demonstration is obvious for anybody who
read the 2 first pages of the XML standard:

   First production of the XML specification:
   [1] document ::= prolog element Misc*

 Misc* means there is no potential limit to the number of Misc element at 
the end, and not finding one is a fatal error. 
      And the definition of Misc is:
Misc     ::=          Comment | PI | S

i.e. either a comment (<!-- ... -->), a processing instruction (<? ... ?>) or
white space.  That PI is further defined to _exclude_ <?xml ... ?>.

So it seems that is IS possible to determine where the next xml doc starts
just by looking for the next xml declaration or the next actual element.

  But a parser will not do this a parser MUST report an error and abort
at that point if it finds an element there it's the spec. The parser 
must error, so something else must detect the end of the root and then 
find the next document, basically you need to rewrite a second non-conformant
parser to do that in front of the real parser.

On Tue, May 24, 2005 at 02:47:12PM -0600, Sebastian Kuzminsky wrote:
I've got a couple of processes that trade XML messages over the network.
The sender writes each XML message on a single newline-terminated line.
The receiver uses select and read, and reads until it gets a '\n',

      While I wouldn't necessarily call a design that tried to intuit where
the next doc starts broken, using a delimeter between docs does sound like
a better idea.  As others have said, using \0 instead of \n will probably
work better, at least until you do something like switch to UTF-16 encoding.

  That would work too I guess.


Daniel Veillard      | Red Hat Desktop team
veillard redhat com  | libxml GNOME XML XSLT toolkit | Rpmfind RPM search engine

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]