Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • That this isn't an XML parser. It is majorly broken in various ways. It's more of a tag-soup parser. I still think you should change the name of it.
    • "It is majorly broken in various ways" is not constructive criticism. Please try again. If you can find ways in which it is *actually* broken - ie, where it doesn't conform to the documentation, or the tests are inadequate - then I would prefer that you open a ticket using rt.cpan.org [cpan.org], although I will also accept submissions by email.

      As for "It's ... a tag-soup parser" - yes, well done, you spotted that it is a non-validating XML module. I know this may come as a shock, but such things are actually use

      • You're entirely missing the point. This is not about being a subset of the functionality or anything, this is not an XML parser. The problem is not about validation -- no one sane cares about that -- the problem is about well-formedness. There is a lot of perfectly good XML out there that this thing won't parse, and there is a lot of completely wrong XML that it won't flag as such.

        If you want to write and release a parser for "vague stuff that has angle brackets in it" and find it useful that's wonderful and by all means go ahead, just don't for a single second delude yourself that you've written an XML parser. Or if you must insist on deluding yourself, please be so kind as to not chance dragging others down in your misunderstanding by releasing it in the XML:: space. It has absolutely nothing to do there. Please move it.

        --

        -- Robin Berjon [berjon.com]

        • Re: (Score:2, Insightful)

          CSS::Tiny [cpan.org] does not parse the entire CSS specification.

          YAML::Tiny [cpan.org] does not support the entire YAML specification.

          Config::Tiny [cpan.org] does not support some elements of the Windows .ini specification.

          Taken literally, CSS::Tiny is not a CSS parser, YAML::Tiny is not a YAML parser and Config::Tiny is not a Windows .ini parser.

          In exchange for sacrificing some completeness and correctness, ::Tiny modules provide a single small .pm file you can drop onto any Perl you are likely to find in existance anywhere, copied in by
          • But to complain that XML::Tiny is missing features is to miss the entire point of the ::Tiny suffix.

            I think people instead are complaining that it's missing the XML:: part of the distribution name.

            • Nah, what they're complaining about is that they think users are too stupid to read the documentation before using the software, and so won't be aware of its limitations.

              Personally, I have a considerably higher opinion of the users than that.

              • Well if that's all it is, XML::Tinier ought to be a breeze to write, and I guarantee that it'll have even less code.

              • I don't think that users are too stupid to read the documentation, but I do think that they will tend to believe it when they read it, and unfortunately it is misleading, as explained in http://use.perl.org/comments.pl?sid=34409&cid=52943 [perl.org], and will waste their time. That's not playing nice.

                --

                -- Robin Berjon [berjon.com]

                • I've fed the "not well formed" parts of the w3c test suite throw this and I don't think that it would be too much of a hardship to make it pass *nearly* all of them (or rather reject them but you know what I mean.) The tricky bit of course is having it check for "well-formedness" in things that it is already ignoring such as comments and processing instructions.
                  • At first glance, a great number of those failures seem to be to do with broken entity declarations which, of course, I don't spot. I'll certainly take a look though and see if there's any quick wins to be had. Thanks!
          • As I said, if people find this sort of thing useful, let them have it, I have no issue with that. Just don't call it XML. It's not. NotXML::Tiny or TagParser::Tiny would be fine. Furthermore the documentation is extremely misleading in that it claims to support a subset of XML -- that is not the case. It would support a subset of XML if every document it understood could also be successfully parsed by an XML parser, but didn't support some things that an XML parser would report. As it is, it supports all

            --

            -- Robin Berjon [berjon.com]

            • One excellent reason for calling it XML::Tiny rather than SomethingElse::Tiny which I've not mentioned yet is that that's what users will look for. Users who need to process simple XML documents will, obviously, look for XML stuff. If I were to call it SomethingElse::Tiny I wouldn't be able to help them. I suppose you could call that "banking on the holy trigraph" but given that I don't actually care whether anyone else uses it, it must be a very small bank.

              If you were to bother to tell me *what* it su

              • Although to be fair you did claim that you "decided to do XML right" and that might be why those that have "done XML right" got out of their pram.
                • I have to agree here. I can see the value of this module... if you have some tiny chunk of very simple XML, and you want something Tiny to just get it into a usable Perl structure, then sure this is a plausible solution. However, saying that you feel that you've done XML right and implemented (you feel) "the useful subset" of XML is obviously going to rile people who have dedicated time to actually implementing robust, if heavy, solutions. I tried the module, tossed an everyday XML file from my $work at
            • What sort of thing were the 83 it was useful for?