[X3D-Public] containerField is should or must ? largeattributes; compression

Don Brutzman brutzman at nps.edu
Tue Aug 24 02:50:23 PDT 2010


On 8/23/2010 12:29 PM, Joe D Williams wrote:
>  > What are you guys thinking???
>
> not sure, can you give an example of some x3d code?
> what you gave for color and vec is not x3d although a style sheet
> transformation will do it.

i think Dave was trying to show that you get ridiculously verbose
in an XML encoding if you really want to.
  
> The container fieldValue is not meant to carry a bunch of attributes,
> just to serve when the field of strongly typed attribute values is
> "too big" for the parser in use.

point of information:  when you use fieldValue, you lose all benefits
of validation of values.  that is because no single schema/dtd rules
can handle all of the datatypes at once.  thus any garbles in a
fieldValue array won't be detected by XML validation and get happily
passed to the X3D player, causing an obscure run-time failure for
the poor user.

> The count attribute is added due to collada influence, but the @name
> is the same as the attribute name it is replacing and the contained
> data is of the same type, as found in the schema/dtd.

count is superfluous/invalid, name is essential (and required by schema/DTD)

> Back to Behr example, the 9 is corrected to a 3 and the count can be
> ommitted.
>
>  >> <IndexedTriangleSet>
>  >> <fieldValue count="3" name="index">
>  >> 0 1 2
>  >> </fieldValue>
>  >> <Coordinate>
>  >> <fieldValue count="3" name="point">
>  >> 0 0 0, 1 0 0, 0 1 0
>  >> </fieldValue>
>  >> </Coordinate>
>  >> <Color>
>  >> <fieldValue count="3" name="color">
>  >> 0 0 1, 1 0 0, 0 1 0
>  >> </fieldValue>
>  >> </Color>
>  >> </IndexedTriangleSet>
>
> Again, not the recommended coding practice except where needed due to
> processing problems.

fieldValue is at least appealing in that it is already well defined and in use
for ProtoInstance initializations by existing browsers.

i understand the arguments, but still no one has responded to say
just what problem is being fixed, and where we draw the line beyond
the already-defined spec maximums. for example, all of the online
NISTConformance examples that test max point counts etc. work OK.
so does our goal now become 1 million values? 10 zillion? perhaps
someundefined upper limit? how do we measure success for this feature?
are we insisting that more values get parsed than a graphics card can
evenhandle?

nor has anyone worried about these problems reported retesting their
parsers, reporting bugs on their parsers, trying more efficient
parsers, etc.  the XML spec is clear that large attributes are allowed
and proper parser behavior is expected.

nor has anyone reported comparison results with .x3db parsing, which
would likely make text parsing of mega-length arrays that are in
.x3d or .x3dv or .wrl encodings look pretty darn inefficient.

so it remains highly questionable that we would change the spec to
support a feature that is somewhere beyond current spec scope,
provoked by code shortfalls, and to support a capability that is
not even quantitatively defined.  by such reasoning we might add
any number of other changes, if the threshold for spec approval
is set so informally.

bellicose indeed!  (good word Dave)

all the best, Don
-- 
Don Brutzman  Naval Postgraduate School, Code USW/Br      brutzman at nps.edu
Watkins 270   MOVES Institute, Monterey CA 93943-5000 USA  +1.831.656.2149
X3D, virtual worlds, underwater robots     http://faculty.nps.edu/brutzman




More information about the X3D-Public mailing list