Re: [saxdotnet-devel] Discussion Status 2

[Karl W. <ka...@wa...>]

Jeff Rafter wrote:

>>  D) Requiring EndDocument
> 
> 
>>  However, this can be guaranteed only for in-process call-backs.
> 
> 
> Can you explain this a little more? Is this the point about non SAX 
> generated Exceptions (i.e., user throws an exception in a callback)? 
> Otherwise, agreed.

What I mean is that in a scenario like DCOM (or some other RPC mechanism)
one cannot guarantee that the call reaches the target, since RPC
mechanisms may have communication failures. You may guarantee that
the call is made (i.e. that it originates), but not that it arrives.
So in such a situation the callee cannot rely on the EndDocument() callback.
However, I think I mentioned that RPC is not a common SAX use case.

>>  F) Merging the IXmlReaderControl with IXmlReader
> 
> 
> I agree with Elliotte's opposition here. But at the time we were talking 
> about adding a lot more exceptional circumstances. Since that time, we 
> have scaled back that approach quite a bit. So I think that we can merge 
> still. We also wanted to have an accompanying mechanism to check support 
> without raising the exception (a feature?). But I think this is 
> manageable. So I think the 2:1 is accurate.

A feature called reader-control has been added. It is obviously a read-only
feature.

> 
>>  G) SAX holes
>>
>>  - Max string length: String.Length is defined as int,
>>     not much we can do here.
> 
> 
> The only thing we could do is come up with some mechanism for (a) 
> passing the stream info in a callback, (b) allowing subsequent calls on 
> all callbacks for the items to be aggregated (c) raise an exception in 
> the event that something exceeds the limit.

I am not sure I understand you fully.


>>  I) Re-define what "parsing" means in SAX.
>>  allow for "optional" argument or return values.
> 
> 
> Agreed, I will work on the new wording.

Thanks!

> 
> So based on that we have very little left undecided... just a little 
> more work to do...

Very good indeed!

Karl