& XSLT On Oct 20, 2005, at 18:49, A. Pagaltzis wrote:
>  * 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 fully agree. I'm not saying that the spec is perfect or that it  
shouldn't change. In fact, if I had had the experience I now have  
(from participating in several W3C specifications) while I was co- 
editing the PerlSAX2 spec, it would have been a lot stricter. The  
fact that the people who were working on the spec were also in  
constant contact over IRC *and* the people implementing the code to  
go with it didn't help either :) Thankfully, Petr is doing excellent  
work updating it now.

>  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.â?

Agreed. The reason I wouldn't want the spec to say how errors  
conditions should be automagically fixed is because that's similar to  
making them non-errors, and then requiring that all handlers support  
that level of complexity, something which I think would have a  
negative impact (PerlSAX was designed so that handlers -- the most  
common case -- would be the simplest part of a pipeline to create).

Creating a piece of code that will do a best effort job of fixing  
broken streams is a different matter. Code that wishes to handle  
broken streams (at the cost of extra processing even when the stream  
is valid) can then chose to do so.

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

Yes, but on the gripping hand magic is good too :) The normalizing  
filter could detect that the next step in the pipeline is another  
instance of itself and replace it with that instance's handler. It  
shouldn't be unduly hard, it wouldn't break anything, and it would  
allow both the producer and the handler to be defensive with no  
overhead.

-- 
Robin Berjon
    Senior Research Scientist
    Expway, http://expway.com/




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