Would a lack of line breaks in a doc cause parsing problems ?

[charliefortune]

I am fetching some product feeds with PHP like this

$merch = substr($key,1);
$feed = file_get_conten ts($_POST['data_url'.$mer ch]);
$fp = fopen("./feeds/feed".$merch.". txt","w+");
fwrite ($fp,$feed);
fclose ($fp);

and then parsing them with PHP's native parsing functions. This is
succesful for most of the feeds, but a couple of them claim to be
empty when I know they are not. On inspection, the thing these failing
feeds have in common is that they contain no line breaks at all.
Should this cause a problem ?

[Asger Jørgensen]

HI Charlie

"charliefortune " <go****@charlie fortune.comskre v i en meddelelse
news:11******** **************@ 50g2000hsm.goog legroups.com...

>I am fetching some product feeds with PHP like this

$merch = substr($key,1);
$feed = file_get_conten ts($_POST['data_url'.$mer ch]);
$fp = fopen("./feeds/feed".$merch.". txt","w+");
fwrite ($fp,$feed);
fclose ($fp);

and then parsing them with PHP's native parsing functions. This is
succesful for most of the feeds, but a couple of them claim to be
empty when I know they are not. On inspection, the thing these failing
feeds have in common is that they contain no line breaks at all.
Should this cause a problem ?

Just to be sure, You are talking about Xml files ?

Whitespaces in a xml file are discarded, so it shouldn't matter, but
hey I'm just a newbee, so maybe someone else knows more.

But You should post a little sample of the xml file that cources the
error. that would make it easier to give adwise.

Kind regards
Asger

[Martin Honnen]

charliefortune wrote:

I am fetching some product feeds with PHP like this

$merch = substr($key,1);
$feed = file_get_conten ts($_POST['data_url'.$mer ch]);
$fp = fopen("./feeds/feed".$merch.". txt","w+");
fwrite ($fp,$feed);
fclose ($fp);

and then parsing them with PHP's native parsing functions. This is
succesful for most of the feeds, but a couple of them claim to be
empty when I know they are not. On inspection, the thing these failing
feeds have in common is that they contain no line breaks at all.
Should this cause a problem ?

The code you show above is not XML or feed specific, you are simply
using PHP file IO to fetch contents and write it to a file.
If you have trouble parsing such a file later with "PHP's native
parsing" functions then show us that code and show us a sample of a feed
where it does not work as you want it to work.
--

Martin Honnen
http://JavaScript.FAQTs.com/

[Joseph Kesselman]

Not for any compliant XML parser. Excess line breaks in the wrong places
might.

Since I don't use PHP, I can't speak to whether it has any limitations.
Contact its authors or support group?

--
Joe Kesselman / Beware the fury of a patient man. -- John Dryden

[Asger Jørgensen]

Hi Richard

"Richard Tobin" <ri*****@cogsci .ed.ac.ukskrev i en meddelelse
news:fd******** ***@pc-news.cogsci.ed. ac.uk...

In article <p1************ *@news.get2net. dk>,
Asger Jørgensen <Ju**@Asger-P.dkwrote:

>>Whitespaces in a xml file are discarded

This is not true. Whitespace in markup (e.g. between attributes) is
unimportant, but XML parsers must return all whitespace in text
content, even the possibly-unimportant whitespace between elements in
element-only content.

You are absolutely right, whitespace can be importent, but since the
question
was about line breaks, I wasn't that much off..;-)

Thanks for pointing it out.

Kind regards
Asger

[Asger Jørgensen]

Hi Charlie

"charliefortune " <go****@charlie fortune.comskre v i en meddelelse
news:11******** **************@ r29g2000hsg.goo glegroups.com.. .
On 26 Sep, 13:23, rich...@cogsci. ed.ac.uk (Richard Tobin) wrote:

In article <p1qKi.41$cQ4.. [e-mail]2net. dk>,

Here is one of the ones that doesn't work

http://fcshirtshop.com/feeds/feed1058.txt.

I can't find anything wrong wrong with the file either.
but I cant find any indications that the encoding should be UTF-8 either
unless thats the accepted default (XML Newbee You know)
At least the file don't say anything and there is no BOM.
The file must be a dificult on though, IE was working for 15 minutes
on the file and it was only half way throught when I closed it
it didn't report any errors though.

One trick You could try though.

You could do a searc and replace on the file before You parse it:

Look for: "<!" and replace it with "\n<!"
\n being new line

There is a <![CDATA in allmost every element
so that would give You enough linebreaks for Your
parser to cope with it. If it is the missing
linebreaks that gives the trouble.

Kind regards
Asger

[Richard Tobin]

In article <us************ *@news.get2net. dk>,
Asger Jørgensen <Ju**@Asger-P.dkwrote:

>I can't find anything wrong wrong with the file either.
but I cant find any indications that the encoding should be UTF-8

It only contains ascii characters, so as long as you don't use ebcdic...

-- Richard
--
"Considerat ion shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[Joe Kesselman]

Asger Jørgensen wrote:

but I cant find any indications that the encoding should be UTF-8 either
unless thats the accepted default (XML Newbee You know)

Most XML parsers will autodetect UTF-16, and will fall back to UTF8. The
XML spec describes how to do that.

There is a <![CDATA in allmost every element

Haven't looked, but I'd bet failure to balance those properly is what's
causing the problems. CDATA Sections are almost always bad practice, for
that reason among many others.

--
() ASCII Ribbon Campaign | Joe Kesselman
/\ Stamp out HTML e-mail! | System architexture and kinetic poetry

[Asger Jørgensen]

Hi Joe

"Joe Kesselman" <ke************ @comcast.netskr ev i en meddelelse
news:SP******** *************** *******@comcast .com...

>
Most XML parsers will autodetect UTF-16, and will fall back to UTF8. The
XML spec describes how to do that.

Yea, I've seen that done in some source code, that is not the easiest thing
to do, but from a look in the PHP manual it sais nothing about selfdetecting
encoding and it states that PHP defaults to ISO-8859-1.
but I gues nothing will happen if You try to decode
a US ASCII as UTF-8, except for the waste of time.

>There is a <![CDATA in allmost every element

Haven't looked, but I'd bet failure to balance those properly is what's
causing the problems. CDATA Sections are almost always bad practice, for
that reason among many others.

Well, those CDATA sections are quite simple, in this file they are simply
used
whenever the element contain text.
Which by the way got me thinking about my own hobby parser, I just throw
those CDATA sections away, I gues thats not the best way <g>

Kind regards
Asger

[Richard Tobin]

In article <11************ *********@d55g2 000hsg.googlegr oups.com>,
Andy Dingley <di*****@codesm iths.comwrote:

>There's also a lot of CDATA sections in there, in contexts where it's
far from necessary to use them. Could they be what's confusing the
parser?

Matching up brackets in huge strings is supposed to be just the sort
of thing computers are good at! I think a line-length limit is the
most likely explanation.

-- Richard

--
"Considerat ion shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.