Hi All,

Terf uses a modified version of XML-Parser based on trunk XML-Parser-ul.44
and XML-Explorer-topa.1.

Levente Uzonyi
>> Monty's XML implementation is way more complete than the one in the
Trunk.

How so?

Ron Tetielbaum

On Sun, Sep 20, 2020 at 6:30 PM Eliot Miranda <eliot.miranda at gmail.com>
wrote:

>
>
> > On Sep 20, 2020, at 3:12 PM, Levente Uzonyi <leves at caesar.elte.hu>
> wrote:
> >
> > H Eliot,
> >
> >> On Sun, 20 Sep 2020, Eliot Miranda wrote:
> >>
> >> Hi Levente, Hi Tty,
> >>
> >>>> On Sep 20, 2020, at 8:10 AM, Levente Uzonyi <leves at caesar.elte.hu>
> wrote:
> >>> Hi Tim,
> >>> Be very careful here. The Xtreams Metacello configuration pulls in
> Monty's XML implementation along with the whole kitchen sink it depends on,
> and leaves your image with a bunch of undeclared variables.
> >>> That Xtreams dependency on that library is pretty much pointless:
> >>> - only one example grammar (PEGWikiGenerator) uses Monty's XML package
> >>> - the example uses it to produce web content as XHTML which is rather
> unusual for two reasons:
> >>> - the majority of web content is HTML5 nowadays. Some stats on the
> internet say XHTML is still at 10% but without proof.
> >>> - it uses an XML library to produce XHTML, but the two are
> surprisingly not as compatible as you would think (see below)
> >>> - the example does not use any features to justify using the
> not-so-Squeak-compatible XML package
> >>> - that example grammar only uses it for the sake of making it
> Pharo-compatible
> >>> Monty's XML implementation is way more complete than the one in the
> Trunk, but it's not compatible with the one in the Trunk.
> >>> So, anything that depends on Squeak's XML implementation will be
> broken if you load Xtreams.
> >>> IMO, the right solution is to either drop Pharo support for Xtreams,
> as Pharo does not use squeaksource (Metacello configuration assumes Pharo 4
> the latest) or split the package, and have a Squeak and a Pharo version of
> the example, making the example use Squeak's XML package in Squeak.
> >>> The latter also involves more work, and a more compilcated Metacello
> configuration.
> >>
> >> I’m pretty sure Terf uses the Squeak XML framework and I know that
> we’re heavily dependent on XML.  So let me make a plea for the latter.  I
> fear we would be heavily impacted by a change of XML framework.  Cc’ing Ron
> as he knows the reality far better than I (hi Ron).
> >
> > Does Terf use Pharo (version 4 or earlier)? If not, this change would
> make no difference.
>
> Terf is built in Squeak 5.3.  We want to move forward to trunk soon (we
> want to stay on trunk).  I have zero desire to develop on Pharo.
>
> >
> > Levente
> >
> >>
> >>>> On Sat, 19 Sep 2020, gettimothy via Squeak-dev wrote:
> >>>> Hi Folks,
> >>>> I have pretty much succesfully imported XTreams and the XML-Parser
> stuff to Squeak 6alpha. from Squeak5.3
> >>>> Some SUnit tests from my project on 5.3 , now ported to 6.0alpha are
> failing for the following reason.
> >>>>
> >>>>     (XMLElement name:'br' ) printString '<br/>'
> >>>> vs
> >>>> (XMLElement name:'br' ) printString '<br />'
> >>>> Notice the latter one inserts an extra space after the 'br'...that is
> the behavior on my 6.0.
> >>>> Checking the Monticello, the 6.0
> >>>>     XML-Parser (monty.428)
> >>>> while the 5.3 is
> >>>>
> >>>>     XML-Parser (monty.428 , ul.44)
> >>> You have probably updated that image after loading Xtreams, and the
> update process merged in the XML-Parsing package from the Trunk.
> >>>> So, presumably having the extra ul.44 removes the space, but I have
> no idea what the ul.44 is, why it is there, how it got
> there....yada,yada,yada.
> >>>> Being new to this, who knows how I managed that.
> >>> No. The two packages are not compatible with each other and you have
> "both" in your image at the same time.
> >>>> before I mailed this, I checked at the w3 schools on the <br> tag and
> it asserts it should not have the slash in it. w3 schools is not the xHTML
> standard, so this may or may not be true.
> >>>> FWIW, the <br/> stuff works fine for me as does the <br />, but I do
> not know if it will cause problems when I move on to XPath stuff later on
> the resulting xHTML docs.
> >>>> Which should I use?
> >>> The space is required for XHTML. It is not required for XML. You're
> using an XML library to generate XHTML, which, as you see, may or may not
> work.
> >>>> Should I bring in the ul.44? and how do I do that?
> >>>> Should I revise my tests (there are not too many) to insert that
> extra space.
> >>> If you want to produce specifically XHTML, then yes. Else you're
> better off generating HTML and not bother with how an XML library produces
> XHTML (which is not the job of an XML library IMO).
> >>> Levente
> >>>> thank you for your time.
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200921/402ce413/attachment.html>