> I basically spent all day yesterday trying to get
> [HTML::Data::Parser](http://search.cpan.org/dist/HTML-Data-Parser/lib/HTML/Data/Parser.pm)
> to work. 

HTML::Data::Parser has a bit of an uncertain future. It does some cool
stuff, like it's able to occasionally find where, say, the @role
attribute and some microformats are describing the same thing, and
synchronise blank node identifiers. But apart from that, you're
probably better off using the modules it depends on individually.

> Now that I've gotten a chance to sleep on it,
> [RDF::RDFa::Parser](http://search.cpan.org/dist/RDF-RDFa-Parser/lib/RDF/RDFa/Parser.pm),
> on which HTML::Data::Parser depends, is actually a little weird. In
> its constructor, it takes either a string, an XML::LibXML::Document
> object or an HTTP::Response (I think?) object. Then it has has a
> `consume` method that takes no arguments at all.

Yeah, the API is kinda dumb. That's why 1.097 comes with
RDF::TrineX::Parser::RDFa which is a frontend with a better
interface (it inherits from RDF::Trine::Parser).

> Anyway, the problem with that is you have to choose the DOM parser
> when the object is initialized, because that's when the document
> initially gets processed. So if I can't, say, switch from LibXML to
> HTML::HTML5::Parser at that time (by passing a parameter to the
> constructor), I get a croak if I try to process any real-world data.

If you pass an XML::LibXML::Document or an HTTP::Response to begin
with, this shouldn't be a problem. In the former case the DOM parsing
has already been done, so RDF::RDFa::Parser does no DOM parsing, so
won't croak trying. In the latter case, it has the HTTP Content-Type
header to guide its choice of DOM parsing.

> One other odd thing: HTML::Data::Parser is a subclass of
> RDF::Trine::Parser and sets
> `$RDF::Trine::Parser::parser_names{htmldata}` to itself. So *really*,
> the way to use it would be, if I'm not mistaken, to call it like
> `RDF::Trine::Parser->new('htmldata');`—no?

Either RDF::Trine::Parser->new('htmldata') or HTML::Data::Parser->new
should work.

> As for action items: For starters, I think we should bring @tobyink
> into the discussion, since he wrote both RDF::RDFa::Parser and
> HTML::Data::Parser. As for `parse_url_into_model`, I have an idea
> around how the dispatcher can be short-circuited if the method is
> inherited and called from a subclass (whether by class or instance).
> That way just the network code is run against the syntax-specific
> parser. 

That would be nice. I'd been considering writing a patch for Greg along
those lines myself. If you take a peek here:

https://metacpan.org/source/TOBYINK/RDF-TrineX-Functions-0.003/lib/RDF/TrineX/Functions.pm#L206

You'll see where I've had to do something along these lines...

	if ($parser eq 'RDF::Trine::Parser')
	{
		parse_url_into_model
	}
	else
	{
		$response = LWP::UserAgent->new->get;
		parse_into_model($response->decoded_content)
	}

It would be nice if something like that was part of Trine out of the
box.

> Also I'm not sure how much interaction has gone on between
> you guys re RDF::Trine::Parser::RDFa and RDF::RDFa::Parser, but I
> wager some considerable optimization can be done in there.

It's my hope that RDF::Trine::Parser::RDFa will be dropped soon, and
the recommendation will be to use RDF::TrineX::Parser::RDFa for RDFa.

It seems likely that the whole API for parsers and serializers will
change soon though.

-- 
Toby A Inkster
<mailto:mail@tobyinkster.co.uk>
<http://tobyinkster.co.uk>