Re: [code-review] Just subscribed

Jean-Michel Hiver wrote:
>>I'm not objecting to the possible usefulness of something that works at the 
>>lexical level, just to the name. XML is very strict and anal about 
>>interoperability, and that approach has paid. At the very least, I would add in 
>>huge bold fiery letters (using the =fiery POD tag) at the top THIS IS NOT AN XML 
>>PARSER, DO NOT USE IT TO PROCESS XML UNLESS YOU KNOW WHAT YOU ARE DOING.
> 
> Sounds like a sensible suggestion. Will do.

Great, thanks. Another thing that would be useful is stating (in the docs) your 
requirements for producing this module. People /will/ ask "but why an XML 
reading module that only does tokens?" There are many many many XML modules out 
there on CPAN, clearly stating what yours is for helps a lot. Something along 
the lines of a "Why should I use this instead of XML parsers that have feature 
foo/a standard interface such as SAX or DOM/error chacking/etc?" section might 
be a good way amongst others.

> Well, it's called a bug... Thanks for your report, I'll fix it and add a
> test for it. I guess I should add a is_valid() method to the
> MKDoc::XML::Token class to make sure that '<!-- comment --' is not
> considered valid.

That, or you may want to die on things that can't even be tokenized right.

>>I'm also scared of what it'll do when parsing some UTF-16 XML with a BOM. 
>>Likely, something insane.
> 
> True. You'd have to encode it to UTF-8 and then encode it back in
> UTF-16. I should add that in the documentation.

That's not always easy to do portably accross Perls, and users don't always know 
which encodings they're dealing with. XML::SAX::PurePerl has code to handle 
that, you may want to reuse it so that your users don't have to care (in a 
perfect world, no one would have to care about character encodings :).

-- 
Robin Berjon <[email protected]>
Research Scientist, Expway      http://expway.com/
7FC0 6F5F D864 EFB8 08CE  8E74 58E6 D5DB 4889 2488