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

[Joe D Williams]

> So *why not* deprecate containerField if fieldValue wrappers are 
> available?

because now you can do it either way you wish. Anyway the fieldValue 
is just another crutch. If you want this construction then allow a 
node having the same ame as the current attibute cvalue. Using 
fieldValue with the name of the content and maybe its type as 
attribute values just makes it more complex for authors.

> With fieldValue wrappers, the parser knows what to expect

Not really. It has to use info in the wrapper defined by the author to 
figure it out.. That is less direct than naming the field correctly 
and directly. And really, for xml all the info the parser needs to 
know is (shold be) in the schema, not embedded by the author in the 
user code.

Joe


----- Original Message ----- 
From: "Braden McDaniel" <braden at endoframe.com>
To: <x3d-public at web3d.org>
Sent: Monday, August 09, 2010 11:20 PM
Subject: Re: [X3D-Public] containerField is should or must ? large 
attributes; compression


> 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>
>
>
> _______________________________________________
> X3D-Public mailing list
> X3D-Public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org