Re: [cowiki-dev] Complete reverse parser refusal
Archie Campbell <[email protected]> Sun, 07 Aug 2005 15:37:38 +0100
| Newsgroups | gmane.comp.php.cowiki.devel |
|---|---|
| Message-ID | <[email protected]> |
--------------090904060208030508040605
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
OK. Obviously option 1 is superior to option 2, because a pseudo-XML
eater is required in both options, plus option 1 involves the production
of strict XML, which will no doubt become useful at a later date. For
example, allowing the ReverseParser and HtmlTransformer to be designed
around the PHP5 xmlparser, drastically reducing the amount of work to be
done.
1.
Therefore, I'm going to start on a class.WikiPseudoXmlConverter.php that
will take legacy wiki database node data, in the old pseudo-XML format
and output strict XML.
<link strref="Hakan Küçükyilmaz">Contributor</link>
will become...
<link><strref><![CDATA[Hakan
Küçükyilmaz]]></strref><![CDATA[Contributor]]></link>
2.
class.WikiParser.php will have to be altered to output strict XML,
3.
class.WikiReverseParser.php will be altered to reflect the changes. Code
recognising attributes will be changed to stateful recognition of
attribute-elements, as above.
4.
class.FrontHtmlTransformer.php will be refactored to use the builtin xml
parser.
5.
class.ParserTest.php changed to incorporate class.PseudoXmlConverter.php
as $x. Tests become three-way.
a) Wiki to strict XML (WikiParser), b) strict XML to Wiki
(WikiReverseParser), c) pseudo-XML (currently included as target, now
useful as input) to strict XML (WikiPseudoXmlConverter).
Comments are welcomed. This is currently more important than issue #239.
Bear in mind that issue #239 is a lot simpler than the XML refactoring;
it can wait.
Patience will be required. I'm only going to commit *after* step 5 has
been reached, and I've been able to throw the unit tests at the three
main files, Parser ReverseParser and PseudoXmlConverter.
Regards,
Archie
Archie Campbell wrote:
> Right. Seemingly the non-ascii character data in "Hakan Küçükyilmaz"
> causes an error from the PHP5 xmlparser at the heart of the ReverseParser.
>
> Apparently the solution is for this part of our coWiki-XML to read
> thus...(to be strict XML)
>
> <q><p><link><strref><![CDATA[Hakan Küçükyilmaz]]></strref></link> has
> added ...etc.
>
> This is fairly demanding. Also, will we be unable to benefit from PHP5
> xml manipulation functions whilst our pseudo-XML is not strict XML?
> That is, will I be forced to make an xml parser for the ReverseParser?
>
> Apparently so, or not at all. Voting for...
>
> 1-XMLconverter to run over legacy documents and tweak to WikiParser to
> emit strict CDATA etc.
>
> or
>
> 2-XMLparsing ReverseParser that eats our pseudo-XML without problems.
>
> I'm not going to start right away, because it's late, but this matter
> is pretty important.
>
> Regards,
>
> Archie
>
> Daniel T. Gorski wrote:
>
>>On 03 Aug 18:35, Archie Campbell wrote:
>>
>>Hi Archie,
>>
>>
>>
>>>>please take the attached file (it is a legacy XML from delelnet.org) and
>>>>put it 1 to 1 in the "content" field of the "cowiki_node" table. Try to
>>>>edit this document then.
>>>>
>>>>
>>
>>
>>
>>>Should be better now, Dan. My commit was too hasty.
>>>
>>>
>>
>>With your new changes and the _given legacy XML_ data I get now (while
>>trying to edit):
>>
>>--- start of browser output ---
>>
>>Error on line 48 before
>>
>>has added Turkish localization to the latest coWiki development version.
>>Neat.
>>
>>FYI: The main coWiki core development is still frozen until the PHP5
>>developers know what they want. The one and only stable coWiki version is
>>0.3.3 with PHP beta1
>>Error on line 49 before
>>
>>--- end of browser output ---
>>
>>The generated HTML is:
>>
>>--- start of source output ---
>>
>>Error on line 48 before <q><p> has added Turkish localization to
>>the latest coWiki development version. Neat.</p><p>FYI:
>>The main coWiki core development is still frozen until the PHP5
>>developers know what they want. The one and only stable coWiki version
>>is 0.3.3 with PHP beta1</p></q>
>>Error on line 49 before
>>
>>--- end of source output ---
>>
>>Then, below this output, the edit "window"/box begins. Any ideas? Did you
>>try what I suggested, to take the legacy XML and try to work with it?
>>
>>I am also wondering as I got doubleqoutes (") emitted by the Firefox browser
>>at the location where the <q> and </q> are, but there are no quotes in the
>>source. Just asking myself if <q> is a valid HTML element and if Firefox
>>spits out these quotes automatically as this doesn't happen with IE. But this
>>not the "real" problem :)
>>
>>regards dtg
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: [email protected]
>>For additional commands, e-mail: [email protected]
>>
>>
>>
>>
>>
--------------090904060208030508040605
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
OK. Obviously option 1 is superior to option 2, because a pseudo-XML
eater is required in both options, plus option 1 involves the
production of strict XML, which will no doubt become useful at a later
date. For example, allowing the ReverseParser and HtmlTransformer to be
designed around the PHP5 xmlparser, drastically reducing the amount of
work to be done.<br>
<br>
1.<br>
<br>
Therefore, I'm going to start on a class.WikiPseudoXmlConverter.php
that will take legacy wiki database node data, in the old pseudo-XML
format and output strict XML.<br>
<br>
<link strref="Hakan Küçükyilmaz">Contributor</link><br>
<br>
will become...<br>
<br>
<link><strref><![CDATA[Hakan
Küçükyilmaz]]></strref><![CDATA[Contributor]]></link><br>
<br>
2.<br>
<br>
class.WikiParser.php will have to be altered to output strict XML,<br>
<br>
3.<br>
<br>
class.WikiReverseParser.php will be altered to reflect the changes.
Code recognising attributes will be changed to stateful recognition of
attribute-elements, as above.<br>
<br>
4.<br>
<br>
class.FrontHtmlTransformer.php will be refactored to use the builtin
xml parser.<br>
<br>
5.<br>
<br>
class.ParserTest.php changed to incorporate
class.PseudoXmlConverter.php as $x. Tests become three-way.<br>
a) Wiki to strict XML (WikiParser), b) strict XML to Wiki
(WikiReverseParser), c) pseudo-XML (currently included as target, now
useful as input) to strict XML (WikiPseudoXmlConverter).<br>
<br>
Comments are welcomed. This is currently more important than issue
#239. Bear in mind that issue #239 is a lot simpler than the XML
refactoring; it can wait.<br>
<br>
Patience will be required. I'm only going to commit *after* step 5 has
been reached, and I've been able to throw the unit tests at the three
main files, Parser ReverseParser and PseudoXmlConverter.<br>
<br>
Regards,<br>
<br>
Archie<br>
<br>
Archie Campbell wrote:<br>
<blockquote type="cite" cite="[email protected]">
<meta http-equiv="Content-Type" content="text/html;">
<title></title>
Right. Seemingly the non-ascii character data in "Hakan Küçükyilmaz"
causes an error from the PHP5 xmlparser at the heart of the
ReverseParser.<br>
<br>
Apparently the solution is for this part of our coWiki-XML to read
thus...(to be strict XML)<br>
<br>
<q><p><link><strref><![CDATA[Hakan
Küçükyilmaz]]></strref></link> has added ...etc.<br>
<br>
This is fairly demanding. Also, will we be unable to benefit from PHP5
xml manipulation functions whilst our pseudo-XML is not strict XML? That
is, will I be forced to make an xml parser for the ReverseParser?<br>
<br>
Apparently so, or not at all. Voting for... <br>
<br>
1-XMLconverter to run over legacy documents and tweak to WikiParser to
emit strict CDATA etc.<br>
<br>
or<br>
<br>
2-XMLparsing ReverseParser that eats our pseudo-XML without problems.<br>
<br>
I'm not going to start right away, because it's late, but this matter
is pretty important. <br>
<br>
Regards,<br>
<br>
Archie<br>
<br>
Daniel T. Gorski wrote:<br>
<blockquote type="cite" cite="mid20050804182211.GW545@bantha">
<pre wrap="">On 03 Aug 18:35, Archie Campbell wrote:
Hi Archie,
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">please take the attached file (it is a legacy XML from delelnet.org) and
put it 1 to 1 in the "content" field of the "cowiki_node" table. Try to
edit this document then.
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->
</pre>
<blockquote type="cite">
<pre wrap="">Should be better now, Dan. My commit was too hasty.
</pre>
</blockquote>
<pre wrap=""><!---->
With your new changes and the _given legacy XML_ data I get now (while
trying to edit):
--- start of browser output ---
Error on line 48 before
has added Turkish localization to the latest coWiki development version.
Neat.
FYI: The main coWiki core development is still frozen until the PHP5
developers know what they want. The one and only stable coWiki version is
0.3.3 with PHP beta1
Error on line 49 before
--- end of browser output ---
The generated HTML is:
--- start of source output ---
Error on line 48 before <q><p> has added Turkish localization to
the latest coWiki development version. Neat.</p><p>FYI:
The main coWiki core development is still frozen until the PHP5
developers know what they want. The one and only stable coWiki version
is 0.3.3 with PHP beta1</p></q>
Error on line 49 before
--- end of source output ---
Then, below this output, the edit "window"/box begins. Any ideas? Did you
try what I suggested, to take the legacy XML and try to work with it?
I am also wondering as I got doubleqoutes (") emitted by the Firefox browser
at the location where the <q> and </q> are, but there are no quotes in the
source. Just asking myself if <q> is a valid HTML element and if Firefox
spits out these quotes automatically as this doesn't happen with IE. But this
not the "real" problem :)
regards dtg
---------------------------------------------------------------------
To unsubscribe, e-mail: <a class="moz-txt-link-abbreviated"
href="mailto:[email protected]">[email protected]</a>
For additional commands, e-mail: <a class="moz-txt-link-abbreviated"
href="mailto:[email protected]">[email protected]</a>
</pre>
</blockquote>
</blockquote>
</body>
</html>
--------------090904060208030508040605--