Hi Alan,
This looks a good start.
Are the constants you have defined corresponding to the FI built-in
encoding algorithms, or do some correspond to application defined
encoding algorithms?
I am wondering how the attribute functionality can mirror the SAX
extensions proposed for text content:
For the content handler one get can notified of:
- arrays of primitive types (PrimitiveTypeContentHandler);
- restricted characters (RestrictedCharacterContentHandler); and
- application defined restricted alphabets and encoding algorithms
(AlphabetAndAlgorithmContentHandler).
Or just;
- built-in and application defined restricted alphabets and encoding
algorithms (AlphabetAndAlgorithmContentHandler).
if one chooses not to get notified of restricted characters through the
RestrictedCharacterContentHandler or the
AlphabetAndAlgorithmContentHandler then they will get notified through
the org.xml.sax.ContentHandler character method.
I am almost tempted to simplify all this and remove support for
restricted characters and restricted alphabets, thus is an internal
detail that is never exposed.
What do people think?
I wonder for attributes whether returning of arrays would be sufficient?
This has the follwing advantages:
- no boxing/unboxing of single values required (moot for 5.0 i know, but
we need to rely on 1.4.2).
- less constants to check
- both built-in and application defined encoding algorithms can be
supported using the same methods. An additional method will be
required to obtain the URI for application defined algorithms an
an array of byte[] will be returned, or potentially (we still need
resolve this) a decoded object(this will ensure that no byte copying
is required).
Paul.
Alan Hudson wrote:
> FastInfoSet will need a way to return typed information within the XML
> framework like SAX. Here is the approach I used for my FI mods for
> X3D. This is for SAX, I havently really looked at DOM yet.
>
> I extended the org.xml.sax.Attributes with two methods. getDataType and
> getDataValue.
> This preserves the original string attribute handling, but offers a way
> to get the native type without converting strings.
> public interface TypedAttributes extends Attributes {
> // Describes the datatype of the typed data
> public static final int TYPE_FLOAT_ARRAY = 0;
> public static final int TYPE_FLOAT = 1;
> public static final int TYPE_INT_ARRAY = 2;
> public static final int TYPE_INT = 3;
> public static final int TYPE_BOOLEAN = 4;
> public static final int TYPE_BOOLEAN_ARRAY = 5;
> public static final int TYPE_STRING = 6;
> public static final int TYPE_STRING_ARRAY = 7;
> public static final int TYPE_DOUBLE = 8;
> public static final int TYPE_DOUBLE_ARRAY = 9;
> public static final int TYPE_LONG = 10;
> public static final int TYPE_LONG_ARRAY = 11;
>
> /**
> * Get the datatype of an attribute. This call will
> * return one fo the TYPE_* constants. This describes
> * what type of object will be returned from getDataValue().
> *
> * @param index The attribute index.
> * @return The data type
> */
> public int getDataType(int index);
>
> /**
> * Get the data value for the attribute.
> *
> * @param index The attribute index
> * @return The attrbute as typed data.
> */
> public Object getDataValue(int index);
> }
>
> When you get a startElement call the Attributes will be of this type.
> This route does incur an extra method call on the primitive types like
> int and float. Perhaps intValue, floatValue... could be added. But I
> think internally these might just end up being Float.floatValue anyway.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_fi.dev.java.net
> For additional commands, e-mail: dev-help_at_fi.dev.java.net
>
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_fi.dev.java.net
For additional commands, e-mail: dev-help_at_fi.dev.java.net