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

[Braden McDaniel]

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>