[x3d-public] X3D V4 Thoughts

[Leonard Daly]

On 12/24/2015 7:07 AM, Joe D Williams wrote:
> So now we are asking the big three questions:
>
> 1. Multiple inheritance of abstract and concrete nodes?
>
> The X3D object hierarchy showing derivation and inheritance of 
> abstract and concrete nodes is currently being refined with the idea 
> of making the inheritance consistent and to offer more guidance to 
> implementors. This examination is mainly taking place using a weekly 
> phone conference
>

I don't think I asked or even mentioned this topic.


>
> 2. Why do we need wrapper ags or containerField
>
> Well, I think the schema has enough info to allow an authortime or 
> runtime system to figure out if a field (a node) is legal in the 
> context it is placed. If that were true, then we would not need 
> wrapper tags or containerField. However, it apparently is not done 
> that way and we have to allow for predefining the correct containing 
> node in a prototype, and I guess there must be some runtime issues so 
> we need to have the user code predefine its role in the structure.

See MetadataSet for a discussed example in the spec and in Don's 
examples on the website.


>
> 3. Why big data in elements rather than attributes
>
> Well, if large data is real problem, then it is relatively easy to 
> redo the schema to put whatever attribute data into an element. I 
> think I remember that a reason was that in the old days there was no 
> data validation available for element content, only attribute content.

Also thinking about XML attributes and elements has clarified over the 
last 15 years. Statements I see repeatedly are on the order "attributes 
are for element metadata", "if you are asking about size limits [for 
attributes], use elements", etc.




>
> more below ...
>
> ----- Original Message ----- From: "Leonard Daly" 
> <Leonard.Daly at realism.com>
> To: "X3D Graphics public mailing list" <x3d-public at web3d.org>
> Sent: Wednesday, December 23, 2015 8:16 AM
> Subject: [x3d-public] X3D V4 Thoughts
>
>
>> I have been doing a lot of thinking about V4 and wish to document these
>> ideas and open them up for discussion. These are not presented in any
>> particular order.
>>
>>
>> 1) All nodes that have (potentially) large attribute values
>> (IndexedFaceSet's coordIndex)
>> should (optionally) allow those fields to be expressed a children of the
>> node. For example
>>
>>    <IndexedFaceSet ... coordIndex='...'>
>>         <Coordinate>...</Coordinate>
>>    </IndexedFaceSet>
>>
>
> corrected:
>
> <IndexedFaceSet ... coordIndex='...' texCoordIndex='...'>
>       <Coordinate point='...' />
> </IndexedFaceSet>

Yes, I missed the /point/ attribute (field)


>
>
>>
>>
>> would become
>>
>>    <IndexedFaceSet ... >
>>         <CoordIndex>...</CoordIndex>
>>         <Coordinate>...</Coordinate>
>>    </IndexedFaceSet>
>
> Not quite there, but I won't try to guess.
> And, with no wrapper tags either.
> Would be nice to keep the point keyword.
> Should size matter?
> Please also consider some other examples.


This makes no sense. My whole point here is to get rid of large 
quantities of data in the attribute.
It matters because you cannot put CDATA sections into an attribute. 
Attributes are metadata about the contents. Large quantities of data are 
not metadata, especially in the case of points, coordinates, indices, 
normals, text strings, etc.

Why would it be nice to keep the point keyword?

What other examples? The few I posted were illustrative to make my words 
clearer. I was not attempting to provide justification through examples.


>
>>
>>
>>
>> This allows the transfer of large data in a node rather than an
>> attribute.
>
> True, but whether large or small should not matter how it is contained 
> for transport.

But it does make a difference when processing and especially when 
handling within the DOM.


>
>> It does make it easier to deal with large quantities (> 65K characters).
>
> Please quantify easier. Same number of characters, I think, except for 
> a few <>

DOM handling. If I want to operation on the data, I work with just the 
data as the contents of an element. I don't need to handle things as 
attributes and use the attribute methods. When on the server side, the 
data gets put into an element, not an attribute.


>
>> There are a number of nodes, including geometry,
>> interpolator, Metadata, and PixelTexture that would all benefit.
>
> Please show some more examples. How would the interpolator be written?

<CoordinateInterpolator key='0 .2 .4 .6 .8 1'>
     <Coordinates name='keyValue'>
                     <!-- Initial set -->
                     <!-- .2 set -->
                     <!-- .4 set -->
                     <!-- .6 set -->
                     <!-- .8 set -->
                     <!-- Final set -->
</Coordinates>
</CoordinateInterpolator>


I believe that this ends up closed to the object model for the content 
that the JSON effort is doing (though the names are different). Also 
note that this is an example possibility, not a specific proposal.


>
>>
>>
>>
>> 2) TimeSensor should take any number of any kind of interpolators as
>> children.
>
> Take my word for it, you probably do not want all interpolators run 
> from the same TimeSensor.

I didn't say that.


> I think you really want to group the TimeSensors and Group the related 
> Interpolators.

I want to group the related interpolators with the driving TImeSensor.

> And, what do you lose by this automation?
Nothing, since it is optional.


> The human readable and easiy synthesized event graph.
> Trying to automagically group functions by location in a structure 
> (lake a TimeSensor with children) may save a few keystrokes for the 
> TimeSensoror gozouta to Interpolator gozinta is moslty lost in extra 
> indentions.

Nothing to do with keystrokes, but grouping related and controlling 
functionality. Most of the time (> 80%, perhaps even >95%), a TimeSensor 
controls one or more interpolators. Forcing them separate does not make 
sense when working with machine generated content. Since the large 
majority of use cases involve structures like this, the source of the 
timing for the animations are clear. Specifying the ROUTEing from the 
time to the animation is redundant and potentially prone to errors.

>
> Now there is only one rule that is important, that the def must appear 
> beore the route.
>
>
>> Each interpolator would automatically have the TimeSensor's
>> /fraction_changed/ field automatically ROUTEd to the interpolator's
>> /set_fraction/ input event field.
>
>
> "automatically" is fine, but, to me, much better when clearly explicit 
> and easily readable in the user code.
> Sure you can alway invent a way to use various assets 'automagically' 
> but what happens after?
> The neat thing about the way we do it ow is that there is nothing 
> automatic, each Route completly describes what is needed.
>
> This is like the tose where I share my coords and indices and all in 
> some common area then somehow apply them to some other means to 
> actually apply them. Sames some strokes but have a more complex 
> interface.
>
>>
>>
>> 3) Standard Practice: Put ROUTE statements as children of the
>> interpolator node that provides the source data. Combining (2) and (3)
>> gives:
>>
>>    <TimeSensor ...>
>>         <PositionInterpolator DEF='Mover' ...>
>>             <ROUTE toNode='MoverTarget' toField='translation' />
>>         </PositionInterpolator>
>>    </TimeSensor>
>
> Please use set_translation.
> What ar you losing when you try to convert from existing forms? Looks 
> compicated, if possible without handwork.
>
> Me no like this style. Much better to have groups of TimeSensors, 
> Intrpolators, and ROUTEs.
> Please look at some examples of complex animations, like
>
> http://www.hypermultimedia.com/x3d/hanim/JoeSkin4EXSPYRWRJK.x3dv
>
>
>>
>>
>>
>> This would replace:
>>
>>    <TimeSensor DEF='Timer' ...></TimeSensor>
>>    <PositionInterpolator DEF='Mover' ...></PositionInterpolator>
>>    <ROUTE fromNode='Timer' fromField='fraction_changed' toNode='Mover'
>>    toField='set_fraction' />
>>    <ROUTE fromNode='Mover' fromField='value_changed'
>>    toNode='MoverTarget' toField='translation' />
>>
>
> No, it would most likely replace One timesensor with 20 interpolaters 
> and 49 routes. .
> Since all interpolators may notbe run frm the smae timesensor,
>
>
>>
>>
>> To preserve the past, this would be an optional construct.
>
> Please compose example of schema.

No. Schemas are too complex and potentially filled with errors. At this 
stage I am discussing concepts illustrated with XML examples. Schemas 
and DTDs are beyond concept discussions and trying to build even an 
excerpt is premature.



>
>
>> This collects
>> the information involved in keyframe animation in one node (TimeSensor).
>
> No, to me it locks information into an arbitrary semi-automated 
> structure with much added work for author and player.
> This looks simple for simple stuff, then dies when it gets real. How 
> about when you add an interpolator and ROUTE at runtime? (hint, much 
> more complcated for the player.)

Is it really? I am doing this with X3DOM right now. A lot depends on the 
mechanism you use to add nodes. This is all still done in the context of 
my V4 proposal. I'm not sure if that has been released to this list yet. 
I will update it and send an announcement.




>
>
>> From previous mail:
>
>>> For those few cases when a 'containerField' is required, is it
>> > reasonable to define wrapper tags.
>
> Yes, if found, that has been done.
>
>>  while making the structure of the X3D field easier to understand.
>
> First, for this topic there is one major question that has at least 
> two answers:
> What is the actual function of the wrapper tag or the containerField?

There are a few cases where a node is allowed to be a child of more than 
one field. The containerField in the child node identifies which parent 
field this node belongs to.



-- 
*Leonard Daly*
3D Systems & Cloud Consultant
X3D Co-Chair on Sabbatical
LA ACM SIGGRAPH Chair
President, Daly Realism - /Creating the Future/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20151224/8f14a455/attachment-0001.html>