On Nov 15, 2010, at 9:45 AM, Tudor Girba wrote:
Hi,
Thanks for this nice overview. I am happy that XML handling gets a bit more traction in Smalltalk :). I took a quick look and your XMLPluggableElementFactory sounds quite interesting, and it's great that it supports namespaces.
Regarding Opax, your analysis is not quite right.
- You do not need to subclass the OPOpaxHandler.
- The goal of Opax is not to replace DOM, but to enhance SAX. It's true that at the moment it still creates a tree, but this should be changed to make it optional. The original idea of Opax was to dispatch everything, including the factory decision to the Element, but the implementation remained behind the wishes.
- Opax is tiny: 3 classes + 4 test classes
- OPGenericElement should simply be made a subclass of XMLElement, and we would have the compatibility we would need.
- I do not see the reasons why DOM should be preferred to SAX. The problem with DOM is that it always creates XML elements :). When you have large XML files, you often do not want to load them, but just to process them directly. This is the goal of SAX, but then SAX is procedural. Opax should be used to transform SAX into an object-oriented handling.
Instead of removing it, I would suggest a different approach. Let's make it focus on the SAX parsing:
- We could easily get it to use the XMLNodeFactory
- We could subclass OPGenericElement from XMLElement.
In any case, regarding packaging, I would definitely be in favor of splitting XMLSupport in multiple packages.
It would be good also to have a more sexy name that XMLSupport. I know people do not care about names but XMLSupport looks like ok here is a garage yes you can find the tool may be, while I would love to have Gardner a nice and cool toolkit to take care of tree (soft and nice (woman) voice) if you see what I mean.
Stef
+1 :)
Doru
On 15 Nov 2010, at 10:26, Stéphane Ducasse wrote:
On Nov 15, 2010, at 9:45 AM, Tudor Girba wrote:
Hi,
Thanks for this nice overview. I am happy that XML handling gets a bit more traction in Smalltalk :). I took a quick look and your XMLPluggableElementFactory sounds quite interesting, and it's great that it supports namespaces.
Regarding Opax, your analysis is not quite right.
- You do not need to subclass the OPOpaxHandler.
- The goal of Opax is not to replace DOM, but to enhance SAX. It's true that at the moment it still creates a tree, but this should be changed to make it optional. The original idea of Opax was to dispatch everything, including the factory decision to the Element, but the implementation remained behind the wishes.
- Opax is tiny: 3 classes + 4 test classes
- OPGenericElement should simply be made a subclass of XMLElement, and we would have the compatibility we would need.
- I do not see the reasons why DOM should be preferred to SAX. The problem with DOM is that it always creates XML elements :). When you have large XML files, you often do not want to load them, but just to process them directly. This is the goal of SAX, but then SAX is procedural. Opax should be used to transform SAX into an object-oriented handling.
Instead of removing it, I would suggest a different approach. Let's make it focus on the SAX parsing:
- We could easily get it to use the XMLNodeFactory
- We could subclass OPGenericElement from XMLElement.
In any case, regarding packaging, I would definitely be in favor of splitting XMLSupport in multiple packages.
It would be good also to have a more sexy name that XMLSupport. I know people do not care about names but XMLSupport looks like ok here is a garage yes you can find the tool may be, while I would love to have Gardner a nice and cool toolkit to take care of tree (soft and nice (woman) voice) if you see what I mean.
Stef
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"What is more important: To be happy, or to make happy?"
---- On Mon, 15 Nov 2010 01:26:50 -0800 Stéphane Ducasse wrote ----
On Nov 15, 2010, at 9:45 AM, Tudor Girba wrote:
Hi,
Thanks for this nice overview. I am happy that XML handling gets a bit more traction in Smalltalk :). I took a quick look and your XMLPluggableElementFactory sounds quite interesting, and it's great that it supports namespaces.
Regarding Opax, your analysis is not quite right.
- You do not need to subclass the OPOpaxHandler.
- The goal of Opax is not to replace DOM, but to enhance SAX. It's true that at the moment it still creates a tree, but this should be changed to make it optional. The original idea of Opax was to dispatch everything, including the factory decision to the Element, but the implementation remained behind the wishes.
- Opax is tiny: 3 classes + 4 test classes
- OPGenericElement should simply be made a subclass of XMLElement, and we would have the compatibility we would need.
- I do not see the reasons why DOM should be preferred to SAX. The problem with DOM is that it always creates XML elements :). When you have large XML files, you often do not want to load them, but just to process them directly. This is the goal of SAX, but then SAX is procedural. Opax should be used to transform SAX into an object-oriented handling.
Instead of removing it, I would suggest a different approach. Let's make it focus on the SAX parsing:
- We could easily get it to use the XMLNodeFactory
- We could subclass OPGenericElement from XMLElement.
In any case, regarding packaging, I would definitely be in favor of splitting XMLSupport in multiple packages.
It would be good also to have a more sexy name that XMLSupport. I know people do not care about names but XMLSupport looks like ok here is a garage yes you can find the tool may be, while I would love to have Gardner a nice and cool toolkit to take care of tree (soft and nice (woman) voice) if you see what I mean.
I believe the library used to be called YAXO, which was an acronym for... something. I am not sure why the name was changed to something so generic; perhaps because it sounds more professional, or for SEO performance reasons, or so people would know this was *the* package to download for handling XML in Squeak and Pharo. I don't really know.
Stef
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-
jaayer -
Stéphane Ducasse -
Tudor Girba