Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View
I have created a prototype of an XML Parser (a wrapper around the
XML::Parser) based on an idea of using a knowledge base about the
methods and invoking them via queries based referring to what the
class knows about them.

The prototype is here:

It depends on the "core" module:

The name is subject to change, I just found some slightly related
classes in the "Class" namespace and permitted myself to call the
prototype "Class::The". This is my first contribution, though, I may
have done something wrong. There are also some tests (in the dir "t")
and quite a lot of pod in the code. Please take a look.

Best regards,
Pawel Biernacki

Re: Class::The::XML::Parser

xuesheng wrote:
Quoted text here. Click to load it

If I understand correctly, you use a specialized language (with expressions like
path:alpha/beta or path:*/gamma, from the test code, the synopsis doesn't have
the 'path:' bit ) to trigger handlers that get passed the same arguments as
XML::Parser handlers. Is that correct? I am not sure I quite understand the
"knowledge base" part of your description.

How would this compare to existing modules like XML::Twig, XML::Rules or
XML::DT, which all have a similar model? Or even to XML::Parser Stream mode?

Some more examples, and an assessment of the benefits of using this module
instead of the other ones would be awelcome addition to the docs.

Also traditionally XML parsing modules are in the XML namespace. Which is very
crowded! Nevertheless I believe there would be a (slightly) better chance for
user to find your module if it was there instead of in the Class:: namespace.


Re: Class::The::XML::Parser

Quoted text here. Click to load it

I am very sorry for the mismatch, this is true, the documentation does
not contain the "path:" prefix, but the test code works and it does.

Concerning the question. I do use the "path:.." syntax, as you point
out. But my solution is not offering any fixed language to write the
rules. I do not think I can create something comparable with the Perl
regular expressions or XSLT/XPath. Maybe I will explain my reasoning
step by step. I needed a flexible way to store the knowledge. What is
knowledge? Data allowing resolving queries. The problem is about a
strong knowledge representation framework. First, all queries must be
legal and easy to write. So there is a standard way to write a query,
it is always a list of strings. But someone has to have the knowledge
how to match queries against attributes. I chose the someone to be the
attribute instance itself. The one who writes knowledge about methods
(the assertions) can mix various classes for attributes. He is not
limited by any language syntax, he can use any attribute class or even
write his own one (preferably inherited from Class::The::Attribute).
An attribute knows how to match itself against any query. For every
"assert" the user is free to use a different class. Sometimes he uses
the class Class::The::Attribute::XML::Path - then this is the class
using the language that you correctly identified - the expressions
with "path:". But many other classes are possible. We can even select
the class depending on the attribute, and identify even the attribute

sub learn_per_class
    my $this = shift;
    $this->assert("method1", $this->the(["class, that is the best to
match the attribute", $this->the["some strange attribute"])->new
(attribute => $this->the(["some strange attribute"])));

This means that both the class used to represent the attribute can be
an entity described with the knowledge representation system, and the
attribute itself too. Of course we need to store the knowledge before
it is used. My point is that in this case
Class::The::Attribute::XML::Path does not need to be hardcoded, and
the syntax "path:..." can be happily replaced by anything else.

Quoted text here. Click to load it

XML::Twig -
It offers two approaches, the first one is actually a DOM parsing
approach and offers a fixed set of methods to manipulate the tree of
document. The second one is close to my approach, but it does use a
fixed language (as far I know close to XPath). I would recommend my
approach if we write a class that does anything else apart from XML
parsing, and if we intend to use the XML::The framework to this
activity, too. Then my approach is more uniform. However if one
intends to do just XML parsing then I would recommend XML::Twig,
because its rule language is stronger than the "path:.." syntax
offered by my class Class::The::Attribute::XML::Path.

XML::Rules -
An excellent module. It's purpose is to create a data structure (using
arrays and hashes) and an instance of this class can be used as a kind
of filter to map certain original structures into the output
structures. It has a strong syntax for conditions of the rules, both
regular expressions and "*" can be used to identify paths. My module
is not intended especially for creating the data structures reflecting
somehow the XML although it can be used to do it. Consequently, it
does not offer any filtering of the underlying structures. It does
offer a little more only concerning the conditions - delegating the
attribute matching to separate classes is more flexible. So I would
recommend XML::Rules just for XML parsing when creating or filtering
data structures. In any other XML parsing I think it is better to
invest into my module.

Again an excellent module. I would recommend it if we have conditions
written in advanced XPath. It is stronger than my module, concerning
just XML parsing. However, again, my module is not only about the XML
parsing. It was just an example that the knowledge about entities can
be created automatically, and matched against certain conditions
written as "regular expressions for knowledge", which I call

Apart from the modules you listed I would add the XML::XSLT, I used it
a while ago and it is quite good. Of course the "rules" to map XML
documents are written in XSL then.

Quoted text here. Click to load it

Right. I will write more examples, maybe also comparison how various
problems can be solved with these modules and how they would be solved
with my module. You are right about the relationships between them -
my module is almost an example of the rule-based programming. One
could describe it as a rule-based programming engine if we write a
simple loop:

while (1)
    $x->the(["the best thing to do next"]);

And depending on the current state it would choose the next step and
execute it. The selection - what can be done, and what is better, and
even how to compare what is better (is it time? memory? money?) could
even be negotiated in runtime. I can imagine that at a certain point
the program realizes it does not have sufficient knowledge to do
something, and then it may stop and ask a question. Tell the user -
listen, I am looking for something that ...., and I cannot find it. Do
you allow me to dig in the Internet for a solution? Post a message to
compl.lang.perl.modules? Or maybe you could tell me what tests I could
do to solve the problem? Maybe we do not need an analytic solution,
maybe an approximation would do?

I think about a kind of expert system. But I could not write this
before I gave you some direct benefit, that is why I chose the XML
parsing. But I truly believe that even this prototype can do some
things better than the existing modules, I will try to support this
opinion with some more examples.

Quoted text here. Click to load it

I see. Of course, this was just a suggestion, I will be glad to
discuss changing the name. Feel free to suggest other names, I will
just write down all the suggestions. Anyway this is my first
contribution, I do not insist on locating it in any particular

Best regards,
Pawel Biernacki

Site Timeline