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