Alan Hudson wrote:
> Paul Sandoz wrote:
>
>
>>Ah, there is a bug in my thinking i cannot see how external vocabulary
>>URIs would get added thus an extra step is required for this :-(
>>
>>Yes, some additional information for encoding algorithms to be added to
>>the table is required. Hmm... obviously this information needs to be
>>filtered from the XML document before a vocab is generated, a simple SAX
>>filter would do it, while it is filtering out the algorithms it could be
>>adding them to the table.
>>
>>
>
> My initial efforts at mapping encodings where based on using a simple
> mapping, ie for attributes named "coord" use this algo. In the end
> I had to go one further, which was a element.attribute lookup. Some of
> the fields in X3D have the same name but different types.
>
Since there will be only unique names in the vocabulary i do not think
any vocab represetation will help for the cases where the semantic use
is different but the same names are used.
> This is likely how I will handle compressing files in a fast manner.
>
> For maximum compression requests, my current thinking is to dynamically
> discover the datatype. Ie take the value, find the smallest
> representation possible. So "0.000000" would be stored as a byte, value
> 0. Or the string "ABCABCABCABCABC" might use a pattern matching algo
> like lzw. In this case I wouldn't use the table supported algo URL.
>
If you are using LZW you will need to use an application defined
encoding algorithm (with a URI that needs to be in the table) as such an
algorithm has not been defined as built-in.
The more semantic information you can use to help reduce the scope of
what encoding algorithm to use the better. I guess it is tricky to get
the balance right when operating at the level of SAX API rather than an
X3D specific API. A specific X3D DOM API might be the at the right
level. Other than that i cannot think how better to match an AII to what
set of encoding algorithms could be applied.
> But I expect I will have to have both as the second method is much
> slower encoding the documents.
>
Yes.
Paul.
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109