Re: XML::LibXML::DocumentFragment

On Feb 18, 2011, at 03:31 , Tom Metro wrote:
> I find it a bit unusual the way the W3C spec justifies the existence of
> the DocumentFragment class not on the basis of functionality ("it is
> true that a Document object could fulfill this role"), but on
> performance ("a Document object can potentially be a heavyweight object,
> depending on the underlying implementation"). That's just it...it
> depends on the implementation. I'm sure there are many object systems
> where an instantiated, but minimally populated Document object would
> consume no more resources than a DocumentFragment.

No offense, but for someone who only a few hours ago did not know what a DocumentFragment was, I think that you're a little bit quick to criticise the standard. Not that it isn't criticisable, but it probably is good practice to familiarise oneself with a given piece of a technology before assuming incompetence of the people who designed it.

The Document objects has a rather central role in the way in which the DOM is architected, moving nodes between documents certainly has implications that moving them into a DocumentFragment does not. But more importantly, a Document can quite logically only have one child element node. DocumentFragments don't have this limitation.

> The name, to me, suggests something that should provide the full
> functionality of a Document, less the outer container.

Do you expect to be able to drive to work in a car fragment? To drink beer from a glass fragment? To hunt mice with a cat fragment?

fragment
noun |ˈfragm(ə)nt|
a small part broken or separated off something

verb |fragˈmɛnt|
break or cause to break into fragments

ORIGIN late Middle English : from French, or from Latin fragmentum, from frangere ‘to break.’

-- 
Robin Berjon - http://berjon.com/



_______________________________________________
Perl-XML mailing list
[email protected]
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs