Need help on File parsing

Discussion in 'C Programming' started by Maxx, Mar 21, 2011.

  1. Maxx

    Maxx Guest

    I'm writing a C program which would parse a xml file as its input and
    perform specific operations...
    Now what i have in my mind is that i should declare a two dimensional
    array and store the xml file in it

    for example::: char country[][]={<countries>,
    <country>,
    <text>Norway</
    text>,
    <value>N</value>,
    </country>}, and so on


    My question is... is there any better way to do this, i.e. is there
    any better way to store the xml input input..

    Thanks
    Maxx, Mar 21, 2011
    #1
    1. Advertising

  2. Maxx

    Ian Collins Guest

    On 03/22/11 09:35 AM, Maxx wrote:
    > I'm writing a C program which would parse a xml file as its input and
    > perform specific operations...
    > Now what i have in my mind is that i should declare a two dimensional
    > array and store the xml file in it
    >
    > for example::: char country[][]={<countries>,
    > <country>,
    > <text>Norway</
    > text>,
    > <value>N</value>,
    > </country>}, and so on
    >
    >
    > My question is... is there any better way to do this, i.e. is there
    > any better way to store the xml input input..


    That's more of a generic programming question than a C one. Have a look
    at a common XML parser like libxml, the documentation will give you
    ideas even if you choose not to use the library.

    --
    Ian Collins
    Ian Collins, Mar 21, 2011
    #2
    1. Advertising

  3. Maxx <> writes:

    > I'm writing a C program which would parse a xml file as its input and
    > perform specific operations...


    What specific operations? See below...

    > Now what i have in my mind is that i should declare a two dimensional
    > array and store the xml file in it
    >
    > for example::: char country[][]={<countries>,
    > <country>,
    > <text>Norway</
    > text>,
    > <value>N</value>,
    > </country>}, and so on
    >
    >
    > My question is... is there any better way to do this, i.e. is there
    > any better way to store the xml input input..


    It's almost impossible to say without knowing how a piece of data is
    going to be accessed (or manipulated).

    A good place to post would be comp.programming. If you say what you
    propose to do with the XML you should get good help there. Be prepared
    to be told that you should use an existing XML parsing library (because
    that is almost always the right answer).

    --
    Ben.
    Ben Bacarisse, Mar 21, 2011
    #3
  4. Maxx

    Nobody Guest

    On Mon, 21 Mar 2011 13:35:01 -0700, Maxx wrote:

    > I'm writing a C program which would parse a xml file as its input and
    > perform specific operations...
    > Now what i have in my mind is that i should declare a two dimensional
    > array and store the xml file in it


    > My question is... is there any better way to do this, i.e. is there any
    > better way to store the xml input input..


    Yes. In fact, it would be hard to imagine a worse way.

    First, I wouldn't recommend trying to actually parse the XML yourself, as
    you're practically bound to get it wrong. Use an XML parsing library
    instead.

    XML parsing libraries come in two main flavours: DOM and SAX. DOM
    constructs a parse tree for the entire file, which the application can
    then query. SAX generates events (reported via callbacks) as it parses the
    file; it's up to the application to actually store the data.

    Which flavour to use and exactly how to do it depend upon the details of
    the application.
    Nobody, Mar 22, 2011
    #4
  5. On Mar 21, 10:35 pm, Maxx <> wrote:
    >
    > My question is... is there any better way to do this, i.e. is there
    > any better way to store the xml input input..
    >

    Think of the XML as a tree, and build what is known as a recursive
    descent parser.

    Basically it's the same problem as a mathematical expression with
    deeply nested parentheses, in a slightly different form. You need one
    token of lookahead.

    Once you've converted the XML to a tree, you'll usually want to walk
    the tree to convert to a set of nested arrays, but sometimes it will
    be better to keep the data in tree form.
    Malcolm McLean, Mar 22, 2011
    #5
  6. Maxx

    Dr Nick Guest

    Malcolm McLean <> writes:

    > On Mar 21, 10:35 pm, Maxx <> wrote:
    >>
    >> My question is... is there any better way to do this, i.e. is there
    >> any better way to store the xml input input..
    >>

    > Think of the XML as a tree, and build what is known as a recursive
    > descent parser.
    >
    > Basically it's the same problem as a mathematical expression with
    > deeply nested parentheses, in a slightly different form. You need one
    > token of lookahead.
    >
    > Once you've converted the XML to a tree, you'll usually want to walk
    > the tree to convert to a set of nested arrays, but sometimes it will
    > be better to keep the data in tree form.


    I did it the other way round. First I wrote a good generic "values"
    handling system that allowed me to have named strings, integers, lists,
    string-indexed-arrays, all as recursive as you like. That was the
    difficult bit.

    They I just hooked xmlparse up to it and it sucked the XML in nicely.

    Think hard about what you want to, if anything, to distinguish between:

    <stuff>
    <item>fred</item>
    </stuff>

    <stuff item="fred"/>

    To summarise - you need more a specification of the problem before
    starting to find a solution.
    --
    Online waterways route planner | http://canalplan.eu
    Plan trips, see photos, check facilities | http://canalplan.org.uk
    Dr Nick, Mar 22, 2011
    #6
  7. Maxx

    Maxx Guest

    On Mar 21, 1:43 pm, Ian Collins <> wrote:
    > On 03/22/11 09:35 AM, Maxx wrote:
    >
    > > I'm writing a C program which would parse a xml file as its input and
    > > perform specific operations...
    > > Now what i have in my mind is that i should declare a two dimensional
    > > array and store the xml file in it

    >
    > > for example:::  char country[][]={<countries>,
    > >                                                  <country>,
    > >                                                      <text>Norway</
    > > text>,
    > >                                                     <value>N</value>,
    > >                                                 </country>}, and so on

    >
    > > My question is... is there any better way to do this, i.e. is there
    > > any better way to store the xml input input..

    >
    > That's more of a generic programming question than a C one.  Have a look
    > at a common XML parser like libxml, the documentation will give you
    > ideas even if you choose not to use the library.
    >
    > --
    > Ian Collins


    Alright i've looked up libxml and seems to have hit jackpot... It does
    contains the necessary function which i need...
    Thanks
    Maxx, Mar 22, 2011
    #7
  8. Maxx

    Maxx Guest

    On Mar 21, 8:41 pm, Nobody <> wrote:
    > On Mon, 21 Mar 2011 13:35:01 -0700, Maxx wrote:
    > > I'm writing a C program which would parse a xml file as its input and
    > > perform specific operations...
    > > Now what i have in my mind is that i should declare a two dimensional
    > > array and store the xml file in it
    > > My question is... is there any better way to do this, i.e. is there any
    > > better way to store the xml input input..

    >
    > Yes. In fact, it would be hard to imagine a worse way.
    >
    > First, I wouldn't recommend trying to actually parse the XML yourself, as
    > you're practically bound to get it wrong. Use an XML parsing library
    > instead.
    >
    > XML parsing libraries come in two main flavours: DOM and SAX. DOM
    > constructs a parse tree for the entire file, which the application can
    > then query. SAX generates events (reported via callbacks) as it parses the
    > file; it's up to the application to actually store the data.
    >
    > Which flavour to use and exactly how to do it depend upon the details of
    > the application.


    Actually the xml file that i was going to provide the program will
    always have a predefined format, like the one example i gave above.It
    will always parse the same format and simply extract the values from
    the fields and write another xml file having the same template... so i
    was looking for the easiest way to solve it, instead of requiring to
    call extensive library functions...

    any ways Thanks
    Maxx, Mar 22, 2011
    #8
  9. Maxx

    Maxx Guest

    On Mar 21, 11:40 pm, Malcolm McLean <>
    wrote:
    > On Mar 21, 10:35 pm, Maxx <> wrote:
    >
    > > My question is... is there any better way to do this, i.e. is there
    > > any better way to store the xml input input..

    >
    > Think of the XML as a tree, and build what is known as a recursive
    > descent parser.
    >
    > Basically it's the same problem as a mathematical expression with
    > deeply nested parentheses, in a slightly different form. You need one
    > token of lookahead.
    >
    > Once you've converted the XML to a tree, you'll usually want to walk
    > the tree to convert to a set of nested arrays, but sometimes it will
    > be better to keep the data in tree form.


    Yeah i had this concept in mind at first, but as i was going to write
    a simple program which would simply extract values from a set of
    predefined fields, so i kinda avoided going into trees.. Although i
    recon a tree would be the best solution but i'm still quite naive in
    trees.

    Thanks
    Maxx, Mar 22, 2011
    #9
  10. Maxx

    Maxx Guest

    On Mar 22, 12:01 am, Dr Nick <>
    wrote:
    > Malcolm McLean <> writes:
    > > On Mar 21, 10:35 pm, Maxx <> wrote:

    >
    > >> My question is... is there any better way to do this, i.e. is there
    > >> any better way to store the xml input input..

    >
    > > Think of the XML as a tree, and build what is known as a recursive
    > > descent parser.

    >
    > > Basically it's the same problem as a mathematical expression with
    > > deeply nested parentheses, in a slightly different form. You need one
    > > token of lookahead.

    >
    > > Once you've converted the XML to a tree, you'll usually want to walk
    > > the tree to convert to a set of nested arrays, but sometimes it will
    > > be better to keep the data in tree form.

    >
    > I did it the other way round.  First I wrote a good generic "values"
    > handling system that allowed me to have named strings, integers, lists,
    > string-indexed-arrays, all as recursive as you like.   That was the
    > difficult bit.
    >
    > They I just hooked xmlparse up to it and it sucked the XML in nicely.
    >
    > Think hard about what you want to, if anything, to distinguish between:
    >
    > <stuff>
    > <item>fred</item>
    > </stuff>
    >
    > <stuff item="fred"/>
    >
    > To summarise - you need more a specification of the problem before
    > starting to find a solution.
    > --
    > Online waterways route planner            |http://canalplan.eu
    > Plan trips, see photos, check facilities  |http://canalplan.org.uk


    Yeah yeah a generic list of values would be helpful but i need more
    ideas on how to implement it.. I'm trying to avoid library function in
    this program as it will always parse the same fields over and over
    again..
    Maxx, Mar 22, 2011
    #10
  11. On Mar 22, 4:13 pm, Maxx <> wrote:
    > On Mar 21, 8:41 pm, Nobody <> wrote:
    >
    >
    >
    > > On Mon, 21 Mar 2011 13:35:01 -0700, Maxx wrote:
    > > > I'm writing a C program which would parse a xml file as its input and
    > > > perform specific operations...
    > > > Now what i have in my mind is that i should declare a two dimensional
    > > > array and store the xml file in it
    > > > My question is... is there any better way to do this, i.e. is there any
    > > > better way to store the xml input input..

    >
    > > Yes. In fact, it would be hard to imagine a worse way.

    >
    > > First, I wouldn't recommend trying to actually parse the XML yourself, as
    > > you're practically bound to get it wrong. Use an XML parsing library
    > > instead.

    >
    > > XML parsing libraries come in two main flavours: DOM and SAX. DOM
    > > constructs a parse tree for the entire file, which the application can
    > > then query. SAX generates events (reported via callbacks) as it parses the
    > > file; it's up to the application to actually store the data.

    >
    > > Which flavour to use and exactly how to do it depend upon the details of
    > > the application.

    >
    > Actually the xml file that i was going to provide the program will
    > always have a predefined format, like the one example i gave above.It
    > will always parse the same format and simply extract the values from
    > the fields and write another xml file having the same template... so i
    > was looking for the easiest way to solve it, instead of requiring to
    > call extensive library functions...


    Note that it always starts this way. It is easy to hand parse the XML
    if it is in a truly fixed format, so why use a real parser? But then
    there are modifications/extensions/etc. People hand edit the file and
    add white space, which won't confuse a parser but messes up your less
    flexible hand parse. People write a mixture of <element></element>
    instead of <element/>, which should parse as equivalent and somehow
    don't when hand parsing. People suddenly want validation. etc.
    Going with a real parser is very much the way to go in a real
    application, much more future friendly even if not apparently needed
    up front...
    David Resnick, Mar 23, 2011
    #11
  12. Maxx

    John Bode Guest

    On Mar 23, 1:45 pm, David Resnick <> wrote:
    > On Mar 22, 4:13 pm, Maxx <> wrote:
    >
    >
    >
    >
    >
    > > On Mar 21, 8:41 pm, Nobody <> wrote:

    >
    > > > On Mon, 21 Mar 2011 13:35:01 -0700, Maxx wrote:
    > > > > I'm writing a C program which would parse a xml file as its input and
    > > > > perform specific operations...
    > > > > Now what i have in my mind is that i should declare a two dimensional
    > > > > array and store the xml file in it
    > > > > My question is... is there any better way to do this, i.e. is thereany
    > > > > better way to store the xml input input..

    >
    > > > Yes. In fact, it would be hard to imagine a worse way.

    >
    > > > First, I wouldn't recommend trying to actually parse the XML yourself, as
    > > > you're practically bound to get it wrong. Use an XML parsing library
    > > > instead.

    >
    > > > XML parsing libraries come in two main flavours: DOM and SAX. DOM
    > > > constructs a parse tree for the entire file, which the application can
    > > > then query. SAX generates events (reported via callbacks) as it parses the
    > > > file; it's up to the application to actually store the data.

    >
    > > > Which flavour to use and exactly how to do it depend upon the detailsof
    > > > the application.

    >
    > > Actually the xml file that i was going to provide the program will
    > > always have a predefined format, like the one example i gave above.It
    > > will always parse the same format and simply extract the values from
    > > the fields and write another xml file having the same template... so i
    > > was looking for the easiest way to solve it, instead of requiring to
    > > call extensive library functions...

    >
    > Note that it always starts this way.  It is easy to hand parse the XML
    > if it is in a truly fixed format, so why use a real parser?  But then
    > there are modifications/extensions/etc.  People hand edit the file and
    > add white space, which won't confuse a parser but messes up your less
    > flexible hand parse.  People write a mixture of <element></element>
    > instead of <element/>, which should parse as equivalent and somehow
    > don't when hand parsing.  People suddenly want validation.  etc.
    > Going with a real parser is very much the way to go in a real
    > application, much more future friendly even if not apparently needed
    > up front...


    Not to mention it's code that *you* don't have to write or test.

    Figuring out how to use the library in your code will take less time
    than writing a robust parser from scratch. Yes, you can hand-hack a
    minimal, non-validating, less-than-totally-robust XML parser in an
    afternoon (I've done it), but you'll be tweaking that sucker
    *constantly* (which I did as well).
    John Bode, Mar 23, 2011
    #12
  13. In article
    <>,
    David Resnick <> wrote:

    > On Mar 22, 4:13 pm, Maxx <> wrote:
    > > On Mar 21, 8:41 pm, Nobody <> wrote:
    > >
    > >
    > >
    > > > On Mon, 21 Mar 2011 13:35:01 -0700, Maxx wrote:
    > > > > I'm writing a C program which would parse a xml file as its input and
    > > > > perform specific operations...
    > > > > Now what i have in my mind is that i should declare a two dimensional
    > > > > array and store the xml file in it
    > > > > My question is... is there any better way to do this, i.e. is there any
    > > > > better way to store the xml input input..

    > >
    > > > Yes. In fact, it would be hard to imagine a worse way.

    > >
    > > > First, I wouldn't recommend trying to actually parse the XML yourself, as
    > > > you're practically bound to get it wrong. Use an XML parsing library
    > > > instead.

    > >
    > > > XML parsing libraries come in two main flavours: DOM and SAX. DOM
    > > > constructs a parse tree for the entire file, which the application can
    > > > then query. SAX generates events (reported via callbacks) as it parses the
    > > > file; it's up to the application to actually store the data.

    > >
    > > > Which flavour to use and exactly how to do it depend upon the details of
    > > > the application.

    > >
    > > Actually the xml file that i was going to provide the program will
    > > always have a predefined format, like the one example i gave above.It
    > > will always parse the same format and simply extract the values from
    > > the fields and write another xml file having the same template... so i
    > > was looking for the easiest way to solve it, instead of requiring to
    > > call extensive library functions...

    >
    > Note that it always starts this way. It is easy to hand parse the XML
    > if it is in a truly fixed format, so why use a real parser? But then
    > there are modifications/extensions/etc. People hand edit the file and
    > add white space, which won't confuse a parser but messes up your less
    > flexible hand parse. People write a mixture of <element></element>
    > instead of <element/>, which should parse as equivalent and somehow
    > don't when hand parsing. People suddenly want validation. etc.
    > Going with a real parser is very much the way to go in a real
    > application, much more future friendly even if not apparently needed
    > up front...


    XML is the same as csh. Every time somebody raises a
    problem with XML somebody else steps in and presents an
    easy workaround. Eventually you are told not even to
    try writing a parser. It is the death of a thousand
    cuts. And for what?

    XML gives PHBs the illusion that they know about
    programming; and adventurers a cozy berth. XML is a scam.

    Has XML gotten to the point a universal Turing machine
    could be written in XML, or is it still singing "Daisy"?

    --
    Michael Press
    Michael Press, Mar 24, 2011
    #13
  14. On Mar 24, 4:45 am, Michael Press <> wrote:
    > In article
    > <>,
    >  David Resnick <> wrote:
    >
    >
    >
    > > On Mar 22, 4:13 pm, Maxx <> wrote:
    > > > On Mar 21, 8:41 pm, Nobody <> wrote:

    >
    > > > > On Mon, 21 Mar 2011 13:35:01 -0700, Maxx wrote:
    > > > > > I'm writing a C program which would parse a xml file as its inputand
    > > > > > perform specific operations...
    > > > > > Now what i have in my mind is that i should declare a two dimensional
    > > > > > array and store the xml file in it
    > > > > > My question is... is there any better way to do this, i.e. is there any
    > > > > > better way to store the xml input input..

    >
    > > > > Yes. In fact, it would be hard to imagine a worse way.

    >
    > > > > First, I wouldn't recommend trying to actually parse the XML yourself, as
    > > > > you're practically bound to get it wrong. Use an XML parsing library
    > > > > instead.

    >
    > > > > XML parsing libraries come in two main flavours: DOM and SAX. DOM
    > > > > constructs a parse tree for the entire file, which the application can
    > > > > then query. SAX generates events (reported via callbacks) as it parses the
    > > > > file; it's up to the application to actually store the data.

    >
    > > > > Which flavour to use and exactly how to do it depend upon the details of
    > > > > the application.

    >
    > > > Actually the xml file that i was going to provide the program will
    > > > always have a predefined format, like the one example i gave above.It
    > > > will always parse the same format and simply extract the values from
    > > > the fields and write another xml file having the same template... so i
    > > > was looking for the easiest way to solve it, instead of requiring to
    > > > call extensive library functions...

    >
    > > Note that it always starts this way.  It is easy to hand parse the XML
    > > if it is in a truly fixed format, so why use a real parser?  But then
    > > there are modifications/extensions/etc.  People hand edit the file and
    > > add white space, which won't confuse a parser but messes up your less
    > > flexible hand parse.  People write a mixture of <element></element>
    > > instead of <element/>, which should parse as equivalent and somehow
    > > don't when hand parsing.  People suddenly want validation.  etc.
    > > Going with a real parser is very much the way to go in a real
    > > application, much more future friendly even if not apparently needed
    > > up front...

    >
    > XML is the same as csh. Every time somebody raises a
    > problem with XML somebody else steps in and presents an
    > easy workaround. Eventually you are told not even to
    > try writing a parser. It is the death of a thousand
    > cuts. And for what?
    >
    > XML gives PHBs the illusion that they know about
    > programming; and adventurers a cozy berth. XML is a scam.
    >
    > Has XML gotten to the point a universal Turing machine
    > could be written in XML, or is it still singing "Daisy"?
    >


    XML is great in its place. Not a PHB, and don't believe
    it to be a scam. I love it for flatfiles that need
    structured information and flexibility. Easy to extend,
    easy (with XPATH queries say) to get stuff out of.
    Standard, everyone knows what it means, how to add
    to it, how to parse and validate it. Does it solve
    all problems in the world? Of course not...

    -David
    David Resnick, Mar 24, 2011
    #14
  15. Maxx

    Nobody Guest

    On Wed, 23 Mar 2011 11:45:47 -0700, David Resnick wrote:

    > Note that it always starts this way. It is easy to hand parse the XML
    > if it is in a truly fixed format,


    If you restrict the application to reading a subset of XML, that defeats
    the purpose of using XML in the first place.

    You can find a wide range of tools which can process XML, but the range of
    tools which can process a particular custom subset of XML is likely to be
    much smaller (i.e. those tools which you write yourself).

    If you think that you only need to support files written by a particular
    program, you're likely to end up only supporting files which were directly
    written by that program and not post-processed in any way. This often
    makes your program less useful than you had originally assumed.
    Nobody, Mar 25, 2011
    #15
  16. On Mar 24, 12:57 am, John Bode <> wrote:
    > On Mar 23, 1:45 pm, David Resnick <> wrote:
    >
    > Figuring out how to use the library in your code will take less time
    > than writing a robust parser from scratch.  Yes, you can hand-hack a
    > minimal, non-validating, less-than-totally-robust XML parser in an
    > afternoon (I've done it), but you'll be tweaking that sucker
    > *constantly* (which I did as well).
    >

    The problem is that it becomes harder to distribute the program. Even
    if you have source to the library, it's often in messy files that are
    hard to integrate and distract the reader from the actual logical core
    of the program.
    Malcolm McLean, Mar 25, 2011
    #16
  17. On Mar 25, 3:40 am, Nobody <> wrote:
    > On Wed, 23 Mar 2011 11:45:47 -0700, David Resnick wrote:
    > > Note that it always starts this way.  It is easy to hand parse the XML
    > > if it is in a truly fixed format,

    >
    > If you restrict the application to reading a subset of XML, that defeats
    > the purpose of using XML in the first place.
    >
    > You can find a wide range of tools which can process XML, but the range of
    > tools which can process a particular custom subset of XML is likely to be
    > much smaller (i.e. those tools which you write yourself).
    >
    > If you think that you only need to support files written by a particular
    > program, you're likely to end up only supporting files which were directly
    > written by that program and not post-processed in any way. This often
    > makes your program less useful than you had originally assumed.


    Holy out of context quotes, Batman. Your reply misses the entire
    point
    of mine, which is that hand parsing is a bad idea. Did you read the
    rest of the post or just answer after the first 2 lines?

    -David
    David Resnick, Mar 25, 2011
    #17
  18. Maxx

    Nobody Guest

    On Fri, 25 Mar 2011 04:31:43 -0700, David Resnick wrote:

    > Holy out of context quotes, Batman. Your reply misses the entire
    > point of mine, which is that hand parsing is a bad idea. Did you read the
    > rest of the post or just answer after the first 2 lines?


    I wasn't "replying" to your comments. I elaborated on your reply,
    providing more reasons why it's a bad idea to assume that you only need
    to handle a subset.
    Nobody, Mar 25, 2011
    #18
  19. On Mar 25, 2:15 pm, Nobody <> wrote:
    > On Fri, 25 Mar 2011 04:31:43 -0700, David Resnick wrote:
    > > Holy out of context quotes, Batman.  Your reply misses the entire
    > > point of mine, which is that hand parsing is a bad idea.  Did you read the
    > > rest of the post or just answer after the first 2 lines?

    >
    > I wasn't "replying" to your comments. I elaborated on your reply,
    > providing more reasons why it's a bad idea to assume that you only need
    > to handle a subset.


    Just seemed to be replying to my comments, as that was the only quoted
    text being addressed. My mistake.

    -David
    David Resnick, Mar 25, 2011
    #19
  20. Maxx

    Maxx Guest

    On Mar 23, 11:45 am, David Resnick <> wrote:
    > On Mar 22, 4:13 pm, Maxx <> wrote:
    >
    >
    >
    > > On Mar 21, 8:41 pm, Nobody <> wrote:

    >
    > > > On Mon, 21 Mar 2011 13:35:01 -0700, Maxx wrote:
    > > > > I'm writing a C program which would parse a xml file as its input and
    > > > > perform specific operations...
    > > > > Now what i have in my mind is that i should declare a two dimensional
    > > > > array and store the xml file in it
    > > > > My question is... is there any better way to do this, i.e. is thereany
    > > > > better way to store the xml input input..

    >
    > > > Yes. In fact, it would be hard to imagine a worse way.

    >
    > > > First, I wouldn't recommend trying to actually parse the XML yourself, as
    > > > you're practically bound to get it wrong. Use an XML parsing library
    > > > instead.

    >
    > > > XML parsing libraries come in two main flavours: DOM and SAX. DOM
    > > > constructs a parse tree for the entire file, which the application can
    > > > then query. SAX generates events (reported via callbacks) as it parses the
    > > > file; it's up to the application to actually store the data.

    >
    > > > Which flavour to use and exactly how to do it depend upon the detailsof
    > > > the application.

    >
    > > Actually the xml file that i was going to provide the program will
    > > always have a predefined format, like the one example i gave above.It
    > > will always parse the same format and simply extract the values from
    > > the fields and write another xml file having the same template... so i
    > > was looking for the easiest way to solve it, instead of requiring to
    > > call extensive library functions...

    >
    > Note that it always starts this way.  It is easy to hand parse the XML
    > if it is in a truly fixed format, so why use a real parser?  But then
    > there are modifications/extensions/etc.  People hand edit the file and
    > add white space, which won't confuse a parser but messes up your less
    > flexible hand parse.  People write a mixture of <element></element>
    > instead of <element/>, which should parse as equivalent and somehow
    > don't when hand parsing.  People suddenly want validation.  etc.
    > Going with a real parser is very much the way to go in a real
    > application, much more future friendly even if not apparently needed
    > up front...


    I'm using the parser so that i can extract the necessary values from
    specific fields...Anyways i have decided to go with a real parser as
    its becoming too cumbersome.


    Thanks
    Maxx, Mar 25, 2011
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. GIMME
    Replies:
    2
    Views:
    874
    GIMME
    Feb 11, 2004
  2. John Frame

    Need Help Parsing From File

    John Frame, Dec 7, 2006, in forum: Python
    Replies:
    12
    Views:
    514
    Markus Rosenstihl
    Dec 10, 2006
  3. Koncept
    Replies:
    9
    Views:
    200
    Mark Hubbart
    Mar 3, 2004
  4. Mrmaster Mrmaster

    Need Advice Help On Parsing A File

    Mrmaster Mrmaster, Jun 28, 2009, in forum: Ruby
    Replies:
    9
    Views:
    152
    David Masover
    Jun 30, 2009
  5. Replies:
    6
    Views:
    107
    Tad McClellan
    Jun 27, 2006
Loading...

Share This Page