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

[Braden McDaniel]

On Tue, 2010-08-10 at 18:06 -0700, Joe D Williams wrote: 
> > adding *lots* of new elements
> 
> they aren't 'new' because the element contnet has the exact same 
> definition as the attribute value.

I suspect you'll have a tough time finding buy-in for that logic.

> > I don't think there's any inherent good in having two ways to do the 
> > same thing.
> 
> Right, they can (now) do the 'same' thing. The fact that maybe most 
> xml parsers handle the 'same' data in different ways is an artifact of 
> html, not an xml design point.

That is just patently false.  Can you show evidence that *any* modern
XML parser in wide use was designed primarily to parse HTML?

> A deep key is validation.
> 
> Besides the couple of examples where the default containerField 
> definition is not correct in the specific context and must be set by 
> the author, then the containerField is already not required for 
> authoring and for strict validation the processor can look it up in 
> the xml schema.

I don't see how this point is relevant to the discussion.

> Besides the single example where the default handlng of attribute 
> value and element content caused some 'legacy' (my quote) 'xml parser' 
> to 'run out of memory' on some very large (well beyond the spec 
> requirements) data sets then the fieldValue wrapper tag as a 
> substitute for an attribute value is not required.

Calling these XML parsers "legacy" is simply not supportable.  They're
modern codebases that are in broad use by other modern codebases.  And
furthermore, you've offered no alternative which would (hypothetically
or actually) obsolete them.

> So, to me these are fringe cases and I think best to leave things as 
> they are here until we start hearing from the medical, cad, and earth 
> use cases.

We've already heard from affected parties.  The problem has been well
defined, abundantly demonstrated, and a solution already has some
implementer buy-in.

> To me the first case is not that big a problem for authors and now 
> with the fieldValue element solving the problems for a few attributes 
> with very large number of points, colors, etc., I think that this is 
> not a big problem either.

You've now confused me.  Up until this sentence, I've had the impression
from you that you were entirely opposed to fieldValue wrappers.  I take
it that's inaccurate?  Is it accurate that you find fieldValue wrappers
acceptable and we just differ on whether containerField should be
deprecated in concert with their addition? 

> Tha is not to say there are not big problems. For instance everyone 
> agrees we need standard shadows yet we do not have it spec'd. Are we 
> at critical mass to move forward on shadows??

Do we have implementations that implementers consider worth pushing
forward?  If so, it might just be an issue of manpower (for writing spec
prose and pushing it through the process).

> >> If you want this construction then allow a node having the same ame 
> >> as the current attibute cvalue.
> >
> > I'd be fine with that, actually.
> 
> Great, we should not settle for less, but there are no significant, if 
> any, technical reasons to proceed in that direction.
> 
> http://www.hypermultimedia.com/x3d/x3dxmlsyntax/index.htm
> 
> from long ago; now does not play well in IE, followed up by an article 
> from Len.

It doesn't seem to play very well with Gecko or WebKit, either.  (Where
*does* it work?)  But in what I can make out, I'm not able to discern
just what it is you're trying to add to the discussion with this link.

-- 
Braden McDaniel <braden at endoframe.com>