Paul Sandoz wrote:
> Alan Hudson wrote:
>
>> Paul Sandoz wrote:
>>
>>> Alan Hudson wrote:
>>>
>>>> I think the getValue methods should convert native datatypes to
>>>> strings if asked for the value. This way you can feed this data
>>>> into a non-fi aware stream and it will just work. right now it
>>>> returns null for this. thoughts?
>>>>
>>>
>>> Currently i have tried to keep sort of consitent behaviour for the
>>> returning of element content and attribute values.
>>>
>>> When a PrimitiveContentHandler is registered then primtive types:
>>>
>>> - for element content will be returned by methods on the handler; and
>>>
>>> - for attribute values will be obtained by call to getAlgorithmData.
>>>
>>> Registering of a PrimitiveContentHandler signals that the
>>> application can process primitive types for element content and
>>> attribute values. A non-fi aware stream should not register a
>>> PrimitiveContentHandler then all primitive types will be returned as
>>> strings for both element content and attribute values (not very
>>> efficiently mind you as i have not optimized the code, and also i
>>> have not checked it is completely conformant in terms of the
>>> characters produced).
>>>
>>> Do you think we need to separate out how we manage element content
>>> and attribute values for encoding algorithms?
>>>
>> I'm considering least suprise issues. I was converting some code
>> over to use FI and had partially changed it over. So I had some
>> things getting primitives and others not. In the end I've changed
>> them all over, but in the interim it caused some problems. Perhaps
>> just having a warning come up when that method is accessed
>> incorrectly. Ie it was the silence that gave me the problem.
>>
>
> Do you mean an exception should be thrown in that case?
>
>
its very suprising that it comes back null even though the attribute was
set. So either it should autoconvert to respond to the method, or throw
an exception. I just think there will be lots of insidous bugs that
arise with the current implementation. I'd rather catch the wrong usage
very early in development.
>> I suspect in the end we will have to have some autoconversion going
>> on, but I'll need to think about it more to substantiate that hunch.
>>
>
> OK.
>
> If necessary it should be easy to add this conversion functionality.
>
agreed. It certainly doesn't have to the be the performant way to do
things.