Re: XML::LibXML::DocumentFragment

Robin Berjon wrote:
> 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. 

I said it was unusual, not wrong, though I suppose I did imply that. My
point was to seek insight. Is there a good reason why they broke from
convention and took that approach?

And yeah, I take some offense. DOM and related standards comprise a
large ecosystem. I've been using the DOM API to some degree for
something like a decade, but that doesn't mean I'm familiar with every
corner of it.

It also means I don't need to be intimately familiar with
DocumentFragment to spot an inconsistency in how it is specified in
comparison to other W3C and Internet standards.


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

OK, that's a better explanation for why a DocumentFragment isn't a
trivial subclass of a Document object, but it still doesn't explain why
many of the Document-specific methods that should be equally applicable
to a DocumentFragment aren't supported (createElement() being the
example I previously mentioned).

If you don't know, that's fine. The other poster answered my original
question by referencing the spec, which showed that XML::LibXML's
behavior was consistent with the spec. Beyond that I'm just pondering
why the spec is the way it is.


> 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?

Lets stick to rational analogies.

If a word processor edits documents, and a mythical "paragraph
processor" edits paragraphs, which you'd likely agree are a fragment of
a document, then logically I'd expect to be able to use a paragraph
processor to add/remove words (elements), just as I would with a word
processor.

What I expect it can't do are things that are document specific. (Say
creating a title page, or footnotes, or setting page margins, or
whatever aspects you'd attribute to the document at large.)


> fragment
> noun |ˈfragm(ə)nt|
> a small part broken or separated off something
> 
> verb |fragˈmɛnt|
> break or cause to break into fragments

That's entirely consistent with the expectations I described.

 -Tom

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