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

Don Brutzman brutzman at nps.edu
Mon Aug 9 13:52:05 PDT 2010

On 8/8/2010 9:49 PM, Braden McDaniel wrote:
> On Sun, 2010-08-08 at 18:24 -0700, Don Brutzman wrote:
>  > [summary: lookouts have sighted large icebergs ahead, port and
> starboard...]
>  >[...]
>  > > >> There's no question that containerField is made necessary by other
>  > > >> aspects of the XML encoding. Unfortunately, time has shown that
> those
>  > > >> aspects are themselves poor design choices.
>  >
>  > certainly our knowledge and skills have grown over time, which is good.
>  > however not sure what "poor design choices" means.
> It means that, considering a major motivation for XML is to make parser
> design more simple, uniform, and straightforward, design decisions that
> mix poorly with conventional XML parser design or that introduce a level
> of complexity that is hard to justify (based either on the functionality
> they enable or the complexity of alternative approaches) are bad ones.

thanks for the clarification.

not sure there are any major alternative designs, regardless of whether
the resulting design is finest possible (or maybe least-worst) approach
that adequately reconciles both XML and X3D architectural principles.
deployment is a major challenge, we can't just jettison existing work
and existing content.

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