RE: Configuration file format

Brian Scully <[email protected]>
Newsgroups gmane.comp.java.mx4j.devel
Message-ID <[email protected]>
I'm with Carlos on this one.  In the projects I have
been on, we have always specified an order attribute
when needed.  This is done explicitly to protect from
a parser implementation that may not go in document
order.  Maybe there's an optimization that would cause
a parser to do that - I haven't thought about it
enough.  Is there a specification somewhere that says
that the parser will always preserve document element
order?

Brian

--- "Alan D. Cabrera" <[email protected]> wrote:
> The parser should go in document order.
> 
> -----Original Message-----
> From: Bordet, Simone [mailto:[email protected]] 
> Sent: Wednesday, October 29, 2003 4:28 AM
> To: Carlos Quiroz; MX4J-Dev (E-mail)
> Subject: RE: [Mx4j-devel] Configuration file format
> 
> Hi,
> 
> > I did a similar work a while a go for our internal
> loader and 
> > one of the things
> > I was wondering then was how to specify the order
> of 
> > creating, loading,
> > unloading and invoking operations
> > 
> > Will the order be set by the positions of the 
> > create/register/unregister nodes
> > in the file? Isn't that a bit risky since the
> parser may 
> > change the order?
> 
> Really ?
> I always thought the parser goes in the document
> order, are you sure the
> parser can mix it ?
> 
> Simon

__________________________________
Do you Yahoo!?
Exclusive Video Premiere - Britney Spears
http://launch.yahoo.com/promos/britneyspears/


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?   SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.