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

[Joe D Williams]

> adding *lots* of new elements

they aren't 'new' because the element contnet has the exact same 
definition as the attribute value.

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

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.

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.

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.

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

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

Thanks and Best,
Joe

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


> On Tue, 2010-08-10 at 08:31 -0700, Joe D Williams wrote:
>> > So *why not* deprecate containerField if fieldValue wrappers are
>> > available?
>>
>> because now you can do it either way you wish.
>
> I don't think there's any inherent good in having two ways to do the
> same thing.
>
> Granted, fieldValue in general *is* itself a second way to do 
> something;
> but it's really intended for situations where the first way 
> (attribute
> values) doesn't work very well.  It so happens that contained nodes 
> fall
> into that category for reasons of syntax rather than performance.
>
> So the real question is: does containerField offer enough value over
> fieldValue to warrant keeping?  containerField is a little more 
> terse;
> but it's more complicated to parse.  "A little more terse" is not a 
> very
> compelling value proposition, in my estimation.
>
>> Anyway the fieldValue
>> is just another crutch.
>
> In the context of use for contained nodes, it's a crutch the same 
> way
> that containerField is a crutch: it's a bit of syntax to make up for 
> the
> fact that XML attributes can't contain elements (or however you 
> prefer
> to frame the problem).
>
>> 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.  But this would be a bigger change 
> to
> the syntax: you're talking about adding *lots* of new elements 
> rather
> than just repurposing an existing one.  Now, I don't personally care 
> a
> great deal about XML validation (in the canonical sense), so this 
> isn't
> a great concern to me: ensuring correctness of an element name 
> versus an
> attribute value just isn't that different.  But my guess is that the
> folks who do care about the XML element set won't like this.  And
> depending on the specifics of your plans for these elements, you 
> could
> run into *real* problems if different (X3D) nodes use the same field
> names with different field types.
>
>> Using
>> fieldValue with the name of the content and maybe its type as
>> attribute values just makes it more complex for authors.
>
> Seriously?  You think
>
>        <OuterNode>
>          <fieldValue name="outerNodeField">
>            <InnerNode/>
>          </fieldValue>
>        </OuterNode>
>
> is significantly more complex than
>
>        <OuterNode>
>          <InnerNode containerField="outerNodeField"/>
>        </OuterNode>
>
> ?
>
> The former is marginally more verbose.  But, *complex*?  I really 
> don't
> see it.
>
>> > With fieldValue wrappers, the parser knows what to expect
>>
>> Not really.
>
> Yes, really.
>
>> It has to use info in the wrapper defined by the author to
>> figure it out..
>
> Right.  Which it's *already parsed* by the time it gets to the 
> contained
> stuff.  On the other hand, if I'm parsing a contained node without a
> fieldValue wrapper, I can't evaluate the correctness of the node as 
> a
> contained element until I've parsed the containerField attribute. 
> And
> because the attributes can be in any order, this means I have to get 
> the
> XML parser to parse *all* the attributes before I can make that
> correctness determination.
>
> With a fieldValue wrapper, I can make that determination as soon as 
> I
> see the contained node element name.
>
>> 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.
>
> Schema/DTD-based parsing is not really used outside the niches of
> validation and transformation.  While those are important 
> operations,
> they're not everything.  Some people like to look at the pictures. 
> ;-)
>
> -- 
> Braden McDaniel <braden at endoframe.com>
>
>
>
> _______________________________________________
> X3D-Public mailing list
> X3D-Public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org