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

gettimothy gettimothy at zoho.com
Sun Sep 20 16:17:25 UTC 2020


Levente


Thank you for your detailed reply.



I will get back to you throughout the week as I am very tired at the moment and the brain is sub-par.






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.



Can the Trunk XML stuff handle the XPath and SAX?  I will be iterating over many gigabytes of XML document.

If so, I would love to use the Squeak stuff and begin documenting it (there is no documenation that I am aware of)




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 prefer the latter approach. Surprisingly, I chatted with the pharo team...and I tried to import XTreams into Pharo at one point...and it does not load.

So having a pharo dependency on something that does not work in Pharo is silly. 



It has been years since I wrote a Metacello configuration, but ramp up time should not be too much.








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). 








I do. I have some Postgres XPath and XSLT functions written that depend on XHTML.  

The strict document stuff makes data extraction and manipulation easier in the long-run.





So, if I am reading you correctly, the "right thing to do" is decouple the Monty XML stuff from Xtreams, 

Modify the existing XML stuff in the package to use the Trunk XML stuff, then provide a squeak and pharo ConfigurationOfXTreamsPharo and ConfigurationOfXTreamsSqueak.



That's a big job.



My project is about 2/3 done and I do not think I will be using anything in the image that will hit the dangers you describe.





I do have a "pristine6.0" image for testing loading stuff and getting it running on Squeak6  That porting project would be perfect to run on it.



I will need guidance on the porting project as source control stuff is a big weak spot with me.

I usually "putter" code on Sunday's .



I have added : 


DECOUPLE Project per Levente on the Pristine on "down time putter"


to my TODO list in my image.



cheers.



t








---- On Sun, 20 Sep 2020 11:10:16 -0400 Levente Uzonyi <mailto: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. 
 
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?  possibly in Postgres
 
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/20200920/0bac25dd/attachment-0001.html>


More information about the Squeak-dev mailing list