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

Braden McDaniel braden at endoframe.com
Sun Aug 8 21:49:27 PDT 2010

On Sun, 2010-08-08 at 18:24 -0700, Don Brutzman wrote: 
> [summary:  lookouts have sighted large icebergs ahead, port and starboard...]
> On 8/6/2010 8:18 AM, Alan Hudson wrote:
> > On 8/5/2010 6:59 PM, Tony Parisi wrote:
> actually Braden wrote the second-level quote, i believe:

(I did.)

> >  >> 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.

> >  >> fieldValue wrapper nodes were talked about some months ago as an
> >  >> approach to resolve issues with overly large attribute values. These
> >  >> wrappers also render containerField unnecessary; and in light of their
> >  >> availability, it probably makes sense to deprecate containerField.
> well, <fieldValue> element certainly is an interesting alternative possibility.
> especially since that functionality has already been implemented as part of
> ProtoInstance.  this would seem to minimize "language bloat" issues.
> so the idea is appealing.  has anybody yet:
> - implemented it in a player, or estimated the work-effort involved?

I think I recall reading that this is implemented in InstantReality.

> - written an entry for the X3D v3.3 proposed changes wiki?
> - written potential prose for the specification?
> http://www.web3d.org/membership/login/memberwiki/index.php?title=X3D_v3.3_Specification_Changes
> p.s. discussion topic for next Wednesday's call:  can this wiki go open?

Hm... My impression from reading discussions of this was that it had
people pushing it forward; that it was considered a "must have" feature
for very large datasets.

Can someone comment on the current state of this effort?


> for jumbo attributes, it was pointed out that parsing problems are a
> problem of the implementation, not X3D or XML design.

Did you or anyone else ever produce counterexamples of XML parsers that
process very large attributes efficiently?  Seems that if the XML
parsers commonly in use exhibit the problem, it's immaterial whether or
not the problem is fundamental to the design XML.

Braden McDaniel <braden at endoframe.com>

More information about the X3D-Public mailing list