Suggestion: Add type byte for NumAttr

[GoogleCodeExporter]

In my own parser I have currently difficulties implementing Numeric Attributes 
properly. I'm wondering why there is no byte which specifies the type of the 
attribute value, e.g. float/uint8/... Instead the parser has to know about 
these values beforehand. If a value is unknown it will likely be skipped or 
truncated by the parser.

If there would be a byte indicating the type, my whole parser code would get a 
lot easier and shorter. Moreover parsers could always read unknown attributes, 
without any problems.

Would love to here some thoughts about this. What were the original 
requirements when this portion of the spec was made?

Original issue reported on code.google.com by pr...@ibbgdv.de on 13 Aug 2012 at 5:04

[GoogleCodeExporter]

The numeric properties only have meaning if the parser knows what they are for. 
For example, a numeric property with ID 1 might mean "color" for one block, but 
something else for another block. If the parser understands a particular 
property (e.g. color) on a block, it will also know what type to expect. 
Therefor, there is no reason to have the type specified as part of numeric 
attributes. If the parser doesn't know the type, it also won't know what the 
meaning of the property is.

Original comment by bengtric...@gmail.com on 14 Aug 2012 at 10:58

• Changed state: Invalid

[GoogleCodeExporter]

I understand the specs and how NumAttr currently works, already implemented 
this in my parser :)

I'm just unhappy with how we deal with unknown properties. The parser will 
always fail on its own without further information how to interpret the values. 
If multiple users add different custom attributes to any block, the parser will 
always need to be adapted to handle these. If user A sends a file with custom 
properties to user B, user B won't be able to do anything with these properties.

How would the current way work for the end user? When I export/import an awd 
file I would somehow need additional information for custom attributes. Seems 
rather messy to me. Ideally I think all parsers should be able to handle 
unknown properties on their own. I think there are a lot of valid real world 
scenarios where this would be really helpful.

Original comment by pr...@ibbgdv.de on 15 Aug 2012 at 9:20

[GoogleCodeExporter]

You might understand how NumAttr works, but I think you are misunderstanding 
the purpose of it, judging from this issue report and your last reply, or you 
misunderstood my reply. I'll try to be more clear:

NumAttr is not a user extensibility feature. It's a way for the format to 
evolve, and to have optional (but well-defined) properties on blocks and other 
elements, without breaking compatibility. Some properties are required, and 
they are just a sequence of well-defined (in the spec) values, such as the 
number of materials on a mesh, or the number of sub-geometries on a geometry. 
Numeric attributes are similar to these in semantics, but optional. I'm not 
sure what you mean by the end-user, but the only entities that are required to 
care about NumAttr are standard AWD encoders and parsers.

Think about it for a second. Say a property called "UV rotation" is introduced 
in AWD 2.1 as a float on material blocks (entirely hypothetical) and that it's 
property ID is 101. Although this property does not exist in AWD2.0, older 
parsers of that version of the format will still be able to see this property 
(ID=101, len=4) but it won't be able to read it, because it doesn't know it's 
type. It could be an uint32, or a float32, a string or whatever, so the parser 
can't reliably read it for what it is. So far, you are correct.

However, you seem to imply that if it just knew the data type, the 2.0 parser 
would be able to make sense of the value. This is where you're wrong, and I 
can't see how you come to that conclusion. Because even if the parser knew that 
it was a float, it would still not know what the actual meaning of the property 
is. It would know that it's ID=101, that the length is 4 bytes, that the type 
is float, and that the value (now readable) would be for example 0.5. But what 
would it do with this value? Nothing, because it wouldn't know that it should 
be interpreted as the rotation of the UV space. It could be the scale, the 
opacity, or anything else for all that the parser knows.

Therefor, there is no need for a type field in numeric attributes. Parsers who 
understand the attribute already know the type, and parsers that don't know 
enough about a particular attribute to know it's type also wouldn't know what 
to do with the value even if it could have been read. All that these parsers 
need to know is the length of the value to be able to skip it.

You say that the parser will fail. The parser should not fail when it 
encounters an unknown NumAttr, it should just skip it and read the next one. 
That's the key of AWD's forwards and backwards compatibility.

User attributes however, which are meant as a user extensibility feature, do 
need to have a type field, and they have it. User attributes are something that 
the encoders are allowed to specify themselves, which is why that type of 
property also has a namespace field to avoid collisions. User attributes are 
not meant to be interpreted by the parser, but by the environment in which the 
parser runs, and that's the major difference between user attributes and 
numeric attributes.

The reason for even having two types of attributes (UserAttr, NumAttr) is so 
that one can be made suitable for user extension (string names, namespaces, 
value type specified) whereas others can be made as compact as possible (2-byte 
key for 65536 possibilities, no type).

Does that make more sense now?

Original comment by bengtric...@gmail.com on 15 Aug 2012 at 10:10

[GoogleCodeExporter]

Yep, this clears a lot of things up for me. Upon giving this more thought I see 
how knowing the data type won't help in any way. Skipping the attribute is 
indeed the correct solution.

I somehow overlooked the section on User Attributes and just used my NumAttr 
class, which is obviously wrong. I guess this is where my "confusion" comes 
from.

Thanks for your reply!

Original comment by pr...@ibbgdv.de on 15 Aug 2012 at 10:27