Talk:DOM future work

From COLLADA Public Wiki
Jump to: navigation, search

Hexbinary clarification

Re this paragraph:

Currently HexBinary is defined as a daeCharArray. But it needs to be a two-dimensional array daeTArray< daeTArray< daeUChar > * >. This is because hexbinary is a string of characters encoded in hex. 1A2B3C is 3 bytes (characters). The COLLADA Schema uses a list of HexBinary. So “1A2B3C 4D5E6F” requires two three-character arrays.

I'm not following this. Is "...because hexbinary is a string of chars..." a statement of the way it currently is, or of how it should be, and are we referring to the DOM or to COLLADA schema here? And is "1A2B3C is 3 bytes (characters)" simply an example to go along with the previous statement? Also I don't follow how the last sentence follows from the previous sentence--if collada schema uses a list of hexbinary, then isn't 1A2B etc. a list of 5 hexbinary items? Maybe the distinction between DOM hexbinary and collada schema hexbinary just isn't clear? Elf 13:59, 21 March 2007 (PDT)

"The reason for this is that in XML Schema a single hexBinary particle is itself a string of bytes (character array), 1A2B3C is 3 bytes (characters). The COLLADA schema uses a list of hexbinary, therefore an array of array of characters, “1A2B3C 4D5E6F” requires two three-character arrays." Alorino 12:19, 27 March 2007 (PDT)

  • THIS SIMPLY ISN'T SO. The Collada DOM code doesn't work this way. It uses binary representations. It is currently a bug, it outputs signed integer data that is probably 32bit. It's true that when calling setCharData it should be provided hexadecimal characters, however the array itself (which is said needs to be 2D) is binary data and should be. Perhaps calling it an array of Char is wrong. These arrays hold floats and things like this, not char data. Therefore this should be an array of raw memory, and furthermore I can find nothing that suggests the <hex> encoded image permits spaces in its data, nor does xs:HexBinary appear to. By which I mean, maybe the spaces are whitespace, but not that they represent an image or anything like this. I am probably going to pick this codebase up and run with it before long. To say no one uses "images" is ridiculous. No one uses them because a bug is preventing it--Mick P. (talk) 11:10, 7 March 2016 (UTC)
    • Ah! I understand what's wrong here. I've updated the Article to reflect where there is a misunderstanding between what elements hold what types. The <hex> element holds hexBinary, not the list_hex_binary_type. That is a user defined type. Also <hex> does not have to hold character data. Probably no native elements hold actual characters. The confusion comes from mention of <image> in the article.--Mick P. (talk) 09:21, 8 March 2016 (UTC)

SID schema enhancement request

In the SID resolvers section of this page, you suggest changes to teh COLLADA schema. Has this been submitted to COLLADA's bugzilla? Elf 14:03, 21 March 2007 (PDT)

Good Point. I just checked and it looks like this isn't a bugzilla bug. I know its been brought up in the teleconferences and people agree its a good idea. I will create a bug report/feature request for it now. Alorino 12:19, 27 March 2007 (PDT)