[squeak-dev] XML-Parser and <br /> vs <br/> vs https://www.w3schools.com/html/html_elements.asp

gettimothy gettimothy at zoho.com
Mon Sep 21 22:20:36 UTC 2020


Sorry I don"t niw how to intersperse my comments as you all have done, so please bear with me.


If I an reading this correctly, TERF has the same issue as XTreams, a dependency on an XML package that is not in Trunk.  

Terf is a featured app on squeak.org and XTreams parsing is the bees knees.

The issue then becomes a corporate decision on upgrading the XML in Trunk for 6.0 and then retrofitting existing apps, or converting Terf , XTreams and others to the XML in Trunk.


Do I have that right?


My vote is to go with the best software, not marketing, solution. If the XML in trunk is not the best out there, go for the best.  I will help as best I can with that.

Furthermore, and I say this as a newbie who realized a few years ago that importing Omnibrowser(?) Via monticello, into an early squeak 3.x release,  ended up converting my squeak to pharo after all the dependencies where satisfied, and that that model was dangerous.

Keep it clean, keep it excellent, keep it elegant.  Monticello is not meeting that because it is a facade for complexity...it makes some installs very easy, but then you hit this and the "ensure recent Monticello" contortions .


Imho, the BSD ports or Slackware packages is the better model. Git stuff looking good too, but I am jyst an app guy, not a systems guy.
.

thanks all for your work, squeak is a great platform.









---- On Mon, 21 Sep 2020 13:03:43 -0400 Das.Linux at gmx.de wrote ----



> On 21.09.2020, at 17:56, Levente Uzonyi <leves at caesar.elte.hu> wrote:
>
> Hi Ron,
>
> On Mon, 21 Sep 2020, Ron Teitelbaum wrote:
>
>> 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?
>
> AFAIK, it supports namespaces, dtd and schema validation, and sax2. There may be other things too. I never really checked.
>
XLink support and the like.
It's really impressive and quite useful.
Had I had time, I'd incorporated it in 2017 or so.
I hadn't had time and I forgot :/

6.0 is a good Idea tho.

-t

>
> Levente
>
>> 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/56d823ed/attachment.html>


More information about the Squeak-dev mailing list