Smalltalk › Squeak › Squeak - Dev

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

‹ Previous Topic Next Topic ›
 
classic Classic list List threaded Threaded
♦
♦
 16 messages Options
Squeak - Dev mailing list
Reply | Threaded
Open this post in threaded view
♦
♦
|

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

Squeak - Dev mailing list
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)


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.  


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? 

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.


thank you for your time.
Levente Uzonyi
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: XML-Parser and <br /> vs <br/> vs https://www.w3schools.com/html/html_elements.asp

Levente Uzonyi
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? 

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.
>
>
>
>
>
>
>
>
>
>
>
>
Squeak - Dev mailing list
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: XML-Parser and <br /> vs <br/> vs https://www.w3schools.com/html/html_elements.asp

Squeak - Dev mailing list


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 <[hidden email]> 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.
>
>
>
>
>
>
>
>
>
>
>
>
Eliot Miranda-2
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: XML-Parser and <br /> vs <br/> vs https://www.w3schools.com/html/html_elements.asp

Eliot Miranda-2
In reply to this post by Levente Uzonyi
Hi Levente, Hi Tty,

> On Sep 20, 2020, at 8:10 AM, Levente Uzonyi <[hidden email]> 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).

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

Levente Uzonyi
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: XML-Parser and <br /> vs <br/> vs https://www.w3schools.com/html/html_elements.asp

Levente Uzonyi
H Eliot,

On Sun, 20 Sep 2020, Eliot Miranda wrote:

> Hi Levente, Hi Tty,
>
>> On Sep 20, 2020, at 8:10 AM, Levente Uzonyi <[hidden email]> 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.


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.
>>
Eliot Miranda-2
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: XML-Parser and <br /> vs <br/> vs https://www.w3schools.com/html/html_elements.asp

Eliot Miranda-2


> On Sep 20, 2020, at 3:12 PM, Levente Uzonyi <[hidden email]> 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 <[hidden email]> 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.
>

Ron Teitelbaum
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: XML-Parser and <br /> vs <br/> vs https://www.w3schools.com/html/html_elements.asp

Ron Teitelbaum
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 <[hidden email]> wrote:


> On Sep 20, 2020, at 3:12 PM, Levente Uzonyi <[hidden email]> 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 <[hidden email]> 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.
>



Levente Uzonyi
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: XML-Parser and <br /> vs <br/> vs https://www.w3schools.com/html/html_elements.asp

Levente Uzonyi
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.


Levente

>
> Ron Tetielbaum
>
> On Sun, Sep 20, 2020 at 6:30 PM Eliot Miranda <[hidden email]> wrote:
>
>
>       > On Sep 20, 2020, at 3:12 PM, Levente Uzonyi <[hidden email]> 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 <[hidden email]> 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.
>       >
>
>
>
Tobias Pape
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: XML-Parser and <br /> vs <br/> vs https://www.w3schools.com/html/html_elements.asp

Tobias Pape

> On 21.09.2020, at 17:56, Levente Uzonyi <[hidden email]> 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 <[hidden email]> wrote:
>>
>>      > On Sep 20, 2020, at 3:12 PM, Levente Uzonyi <[hidden email]> 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 <[hidden email]> 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.
>>      >
>



Squeak - Dev mailing list
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: XML-Parser and <br /> vs <br/> vs https://www.w3schools.com/html/html_elements.asp

Squeak - Dev mailing list
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 [hidden email] wrote ----


> On 21.09.2020, at 17:56, Levente Uzonyi <[hidden email]> 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 <[hidden email]> wrote:
>>
>> > On Sep 20, 2020, at 3:12 PM, Levente Uzonyi <[hidden email]> 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 <[hidden email]> 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.
>> >
>






Ron Teitelbaum
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: XML-Parser and <br /> vs <br/> vs https://www.w3schools.com/html/html_elements.asp

Ron Teitelbaum
Hi get, 

I was only asking what was available. The additional features sound very useful to me. I've had to use other software in the past because of some of the missing features. I think I ended up with python.  I'm happy to have you believe that we have more power than we do but like everyone else we contribute what we find useful. There are no corporate cabals here.

Please feel free to push for what is best for everyone.

Ron Teitelbaum


On Mon, Sep 21, 2020, 6:20 PM gettimothy via Squeak-dev <[hidden email]> wrote:
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 [hidden email] wrote ----


> On 21.09.2020, at 17:56, Levente Uzonyi <[hidden email]> 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 <[hidden email]> wrote:
>>
>> > On Sep 20, 2020, at 3:12 PM, Levente Uzonyi <[hidden email]> 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 <[hidden email]> 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.
>> >
>







Squeak - Dev mailing list
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: XML-Parser and <br /> vs <br/> vs&nbsp; &nbsp; &nbsp; &nbsp; https://www.w3schools.com/html/html_elements.asp

Squeak - Dev mailing list
In reply to this post by Eliot Miranda-2
Thanks all for the replies.

Just to be clear here as I want to do the right thing.


We should keep the existing Squeak XML Framework
If we need improvements , modify that XML framework to include them.
Live with the per-application (Terf, XTreams) overrides of that default Squeak XML Framework.



"Squeak" does NOT want to replace the existing Squeak XML Framework with a more feature complete framework such as those in Terf or XTreams.


However, let me know if you are interested in upgrading....

1. let me know which is the best XML Framework out there. topa, etc....
2. I will get it working on my 6.0 alpha pristine images.
3. bring in other Squeak "stuff" that uses XML and adapt it to that.


cordially,

tty
Tobias Pape
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: XML-Parser and <br /> vs <br/> vs&nbsp; &nbsp; &nbsp; &nbsp; https://www.w3schools.com/html/html_elements.asp

Tobias Pape

> On 26.09.2020, at 19:57, gettimothy via Squeak-dev <[hidden email]> wrote:
>
> Thanks all for the replies.
>
> Just to be clear here as I want to do the right thing.
>
>
> We should keep the existing Squeak XML Framework
> If we need improvements , modify that XML framework to include them.
> Live with the per-application (Terf, XTreams) overrides of that default Squeak XML Framework.
>
>
>
> "Squeak" does NOT want to replace the existing Squeak XML Framework with a more feature complete framework such as those in Terf or XTreams.
>
I do...
-t

>
> However, let me know if you are interested in upgrading....
>
> 1. let me know which is the best XML Framework out there. topa, etc....
> 2. I will get it working on my 6.0 alpha pristine images.
> 3. bring in other Squeak "stuff" that uses XML and adapt it to that.
>
>
> cordially,
>
> tty
>
>
>
>
>
>



Squeak - Dev mailing list
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: XML-Parser and <br /> vs <br/> vs https://www.w3schools.com/html/html_elements.asp

Squeak - Dev mailing list
In reply to this post by Tobias Pape

ok, 

If I am reading this correctly....

Then http://www.smalltalkhub.com/mc/PharoExtras/XMLParser/main

is the most complete XML implementation out there and importing this into Squeak6.0 alpha would be useful.

amirite?

Also, importing that would break existing Squeak stuff that depends on the 
XML-Parser (tpr.45) and XML-Explorer (topa.1)  currently in the latest squeak6.0 alpha image..


So....

for a hard-replace....

remove XML-Parser (tpr.45) and XML-Explorer (topa.1) from a pristine 6.0 alpha image...

then run tests..

find all the stuff that depends on those packages and adapt them to the latest-greatest.

Is that about right?

thx in advance.



---- On Mon, 21 Sep 2020 13:03:43 -0400 Tobias Pape <[hidden email]> wrote ----


> On 21.09.2020, at 17:56, Levente Uzonyi <[hidden email]> 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 <[hidden email]> wrote:
>>
>> > On Sep 20, 2020, at 3:12 PM, Levente Uzonyi <[hidden email]> 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 <[hidden email]> 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.
>> >
>







Tobias Pape
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: XML-Parser and <br /> vs <br/> vs https://www.w3schools.com/html/html_elements.asp

Tobias Pape

On 26.09.2020, at 21:12, gettimothy via Squeak-dev <[hidden email]> wrote:


ok, 

If I am reading this correctly....

Then http://www.smalltalkhub.com/mc/PharoExtras/XMLParser/main




is the most complete XML implementation out there and importing this into Squeak6.0 alpha would be useful.

amirite?

Also, importing that would break existing Squeak stuff that depends on the 
XML-Parser (tpr.45) and XML-Explorer (topa.1)  currently in the latest squeak6.0 alpha image..


So....

for a hard-replace....

remove XML-Parser (tpr.45) and XML-Explorer (topa.1) from a pristine 6.0 alpha image...

then run tests..

find all the stuff that depends on those packages and adapt them to the latest-greatest.

Is that about right?

more or less.
I think I have a version of XML-Explorer that work's with monty's XML variant (see attached image)

-t


thx in advance.



---- On Mon, 21 Sep 2020 13:03:43 -0400 Tobias Pape <[hidden email]> wrote ----


> On 21.09.2020, at 17:56, Levente Uzonyi <[hidden email]> 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 <[hidden email]> wrote:
>> 
>> > On Sep 20, 2020, at 3:12 PM, Levente Uzonyi <[hidden email]> 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 <[hidden email]> 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.
>> >
> 
Squeak - Dev mailing list
Reply | Threaded
Open this post in threaded view
♦
♦
|

Re: XML-Parser and <br /> vs <br/> vs https://www.w3schools.com/html/html_elements.asp

Squeak - Dev mailing list

thank you!



---- On Sat, 26 Sep 2020 16:23:49 -0400 Tobias Pape <[hidden email]> wrote ----


On 26.09.2020, at 21:12, gettimothy via Squeak-dev <[hidden email]> wrote:


ok, 

If I am reading this correctly....

Then http://www.smalltalkhub.com/mc/PharoExtras/XMLParser/main




is the most complete XML implementation out there and importing this into Squeak6.0 alpha would be useful.

amirite?

Also, importing that would break existing Squeak stuff that depends on the 
XML-Parser (tpr.45) and XML-Explorer (topa.1)  currently in the latest squeak6.0 alpha image..


So....

for a hard-replace....

remove XML-Parser (tpr.45) and XML-Explorer (topa.1) from a pristine 6.0 alpha image...

then run tests..

find all the stuff that depends on those packages and adapt them to the latest-greatest.

Is that about right?

more or less.
I think I have a version of XML-Explorer that work's with monty's XML variant (see attached image)

-t


thx in advance.



---- On Mon, 21 Sep 2020 13:03:43 -0400 Tobias Pape <[hidden email]> wrote ----


> On 21.09.2020, at 17:56, Levente Uzonyi <[hidden email]> 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 <[hidden email]> wrote:
>> 
>> > On Sep 20, 2020, at 3:12 PM, Levente Uzonyi <[hidden email]> 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 <[hidden email]> 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.
>> >
> 
Free forum by Nabble Edit this page