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

[Braden McDaniel]

On Mon, 2010-08-09 at 13:52 -0700, Don Brutzman wrote: 
> 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.

IMO, just about anything that avoids injecting the parent field name
into the child's domain would have been preferable to "containerField".
But I tend not to think in terms of constrained node sets.  Not that
this matters a whit now.

I perceive a compelling case for general "fieldValue" wrappers
irrespective of "containerField".  But it just so happens that
fieldValue wrappers do containerField's job better than containerField.
(With fieldValue wrappers, the parser knows what to expect--rather than
having to do correctness checking ad hoc as with containerField.) So
*why not* deprecate containerField if fieldValue wrappers are available?

> deployment is a major challenge, we can't just jettison existing work
> and existing content.

How do you perceive existing content would be "jettisoned" by the
proposed changes?  The typical response to this sort of (generally
reasonable) wariness has been that code with these new features would be
decorated with an incremented X3D version number.  I'd expect that to
apply in this case, as well.

-- 
Braden McDaniel <braden at endoframe.com>