On Nov 29, 2007 3:44 PM, Smylers <[EMAIL PROTECTED]> wrote:
> What makes you so sure that nobody will come up with a better way of
> working with XML

there is power in everyone doing the same thing ... this is a
variation of lingua franca design pattern.

For example, would we say that the reason why HTML is powerful today
based upon the right mix of angle brackets and hyperlinks, etc... I
would argue no; its simply because everyone is using it. HTML 'could'
just as easily been pure SGML or s-expressions for all I care.

Back to the arguement;

By placing some basic xml handling in core, then you are enforcing a
single authoritative approach to using XML inside of perl ... you are
not restricting it ... yes someone can come up with a 'better' way as

I have been arguing that having some simple functionality, provided by
the core, would potentially harmonize usage across modules and promote
better understanding of code, in general, through consistent usage.

There is a recent analogs in perl, of what happens, for example; the
lack of a case statement in perl (which I am personally fine with)
meant a multiplication of the ways one implements such a logic
structure, in turn reducing understandability .... in the end we now
have 'given'.

I would not include XML::Parser .... though I would expect an XML
parser (like expat) to have to 'live' somewhere in perl or be
dynamically linked.... is there one in parrot I wonder ..... to
underpin the structures I have shown in my previous email with faux
perl syntax.

Once again, the point is that I would like to manage and process XML
using native types, structures and xml aware  operators, from within
perl. If I inherit XPATH, then I get 90% of everything I need.

cheers, Jim Fuller

Reply via email to