& XSLT * Robin Berjon <robin.berjon@[...].fr>  [2005-10-20 11:50]:
>  Actually, I don't think that we want to specify what writers
>  are supposed to do.

I disagree, though mostly with the wording of this sentence.

I can see your following arguments, and Iâ??m not saying the spec
necessarily should specify how to fill in incomplete streams. But
if handlers are not *expected* to be able to handle incomplete
streams, then the spec should say theyâ??re not, so that when
someone hands a handler an incomplete stream and the handler
breaks, itâ??s clear whom the blame is with.

Specs should always be completely unambiguous; including being
unambiguous about what they donâ??t specify. Otherwise itâ??s not
possible to tell features from bugs. This is what Iâ??m lobbying
for.

I donâ??t really care which way the spec is disambiguated; just
that it be possible to look at the spec when a piece of code
breaks and say â??itâ??s my bugâ? or â??itâ??s your bug.â?

>  Note that I'm not saying that people should place that filter
>  between their code and the writer themselves, I think the
>  writer should do that for them. If you look at what sort of
>  object XSW returns from  its constructor, you'll see that it's
>  not what you might expect --  it's already returning a filter
>  (which it needs for some of its  escaping code).

Yes, that could be helpful.

OTOH, users can pass my code any handler they wish to; so my code
*must not* depend on the features of any particular handler.
Hence if the spec said that handlers are not required to support
incomplete streams, and my code produced incomplete streams, I
would always put the normalizing filter in place explicitly. Cf.
interoperability.

And in that case it would be better if the handler would avoid
providing any â??helpfulâ? DWIMmery at all, since that just adds
useless overhead. 

Regards,
-- 
Aristotle Pagaltzis // <http://plasmasturm.org/> 
_______________________________________________
Perl-XML mailing list
Perl-XML@[...].com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs