<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 12/24/2015 7:07 AM, Joe D Williams
wrote:<br>
</div>
<blockquote
cite="mid:C311A973DC1A441F98B676057B93EBEF@joe1446a4150a8"
type="cite">So now we are asking the big three questions:
<br>
<br>
1. Multiple inheritance of abstract and concrete nodes?
<br>
<br>
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
<br>
<br>
</blockquote>
<br>
I don't think I asked or even mentioned this topic.<br>
<br>
<br>
<blockquote
cite="mid:C311A973DC1A441F98B676057B93EBEF@joe1446a4150a8"
type="cite">
<br>
2. Why do we need wrapper ags or containerField
<br>
<br>
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.
<br>
</blockquote>
<br>
See MetadataSet for a discussed example in the spec and in Don's
examples on the website.<br>
<br>
<br>
<blockquote
cite="mid:C311A973DC1A441F98B676057B93EBEF@joe1446a4150a8"
type="cite">
<br>
3. Why big data in elements rather than attributes
<br>
<br>
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.
<br>
</blockquote>
<br>
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.<br>
<br>
<br>
<br>
<br>
<blockquote
cite="mid:C311A973DC1A441F98B676057B93EBEF@joe1446a4150a8"
type="cite">
<br>
more below ...
<br>
<br>
----- Original Message ----- From: "Leonard Daly"
<a class="moz-txt-link-rfc2396E" href="mailto:Leonard.Daly@realism.com"><Leonard.Daly@realism.com></a>
<br>
To: "X3D Graphics public mailing list"
<a class="moz-txt-link-rfc2396E" href="mailto:x3d-public@web3d.org"><x3d-public@web3d.org></a>
<br>
Sent: Wednesday, December 23, 2015 8:16 AM
<br>
Subject: [x3d-public] X3D V4 Thoughts
<br>
<br>
<br>
<blockquote type="cite">I have been doing a lot of thinking about
V4 and wish to document these
<br>
ideas and open them up for discussion. These are not presented
in any
<br>
particular order.
<br>
<br>
<br>
1) All nodes that have (potentially) large attribute values
<br>
(IndexedFaceSet's coordIndex)
<br>
should (optionally) allow those fields to be expressed a
children of the
<br>
node. For example
<br>
<br>
<IndexedFaceSet ... coordIndex='...'>
<br>
<Coordinate>...</Coordinate>
<br>
</IndexedFaceSet>
<br>
<br>
</blockquote>
<br>
corrected:
<br>
<br>
<IndexedFaceSet ... coordIndex='...' texCoordIndex='...'>
<br>
<Coordinate point='...' />
<br>
</IndexedFaceSet>
<br>
</blockquote>
<br>
Yes, I missed the <i>point</i> attribute (field)<br>
<br>
<br>
<blockquote
cite="mid:C311A973DC1A441F98B676057B93EBEF@joe1446a4150a8"
type="cite">
<br>
<br>
<blockquote type="cite">
<br>
<br>
would become
<br>
<br>
<IndexedFaceSet ... >
<br>
<CoordIndex>...</CoordIndex>
<br>
<Coordinate>...</Coordinate>
<br>
</IndexedFaceSet>
<br>
</blockquote>
<br>
Not quite there, but I won't try to guess.
<br>
And, with no wrapper tags either.
<br>
Would be nice to keep the point keyword.
<br>
Should size matter?
<br>
Please also consider some other examples.
<br>
</blockquote>
<br>
<br>
This makes no sense. My whole point here is to get rid of large
quantities of data in the attribute. <br>
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.<br>
<br>
Why would it be nice to keep the point keyword?<br>
<br>
What other examples? The few I posted were illustrative to make my
words clearer. I was not attempting to provide justification through
examples.<br>
<br>
<br>
<blockquote
cite="mid:C311A973DC1A441F98B676057B93EBEF@joe1446a4150a8"
type="cite">
<br>
<blockquote type="cite">
<br>
<br>
<br>
This allows the transfer of large data in a node rather than an
<br>
attribute.
<br>
</blockquote>
<br>
True, but whether large or small should not matter how it is
contained for transport.
<br>
</blockquote>
<br>
But it does make a difference when processing and especially when
handling within the DOM.<br>
<br>
<br>
<blockquote
cite="mid:C311A973DC1A441F98B676057B93EBEF@joe1446a4150a8"
type="cite">
<br>
<blockquote type="cite">It does make it easier to deal with large
quantities (> 65K characters).
<br>
</blockquote>
<br>
Please quantify easier. Same number of characters, I think, except
for a few <>
<br>
</blockquote>
<br>
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.<br>
<br>
<br>
<blockquote
cite="mid:C311A973DC1A441F98B676057B93EBEF@joe1446a4150a8"
type="cite">
<br>
<blockquote type="cite">There are a number of nodes, including
geometry,
<br>
interpolator, Metadata, and PixelTexture that would all benefit.
<br>
</blockquote>
<br>
Please show some more examples. How would the interpolator be
written?
<br>
</blockquote>
<br>
<CoordinateInterpolator key='0 .2 .4 .6 .8 1'><br>
<Coordinates name='keyValue'><br>
<!-- Initial set --><br>
<!-- .2 set --><br>
<!-- .4 set --><br>
<!-- .6 set --><br>
<!-- .8 set --><br>
<!-- Final set --><br>
</Coordinates><br>
</CoordinateInterpolator><br>
<br>
<br>
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.<br>
<br>
<br>
<blockquote
cite="mid:C311A973DC1A441F98B676057B93EBEF@joe1446a4150a8"
type="cite">
<br>
<blockquote type="cite">
<br>
<br>
<br>
2) TimeSensor should take any number of any kind of
interpolators as
<br>
children.
<br>
</blockquote>
<br>
Take my word for it, you probably do not want all interpolators
run from the same TimeSensor.
<br>
</blockquote>
<br>
I didn't say that.<br>
<br>
<br>
<blockquote
cite="mid:C311A973DC1A441F98B676057B93EBEF@joe1446a4150a8"
type="cite">I think you really want to group the TimeSensors and
Group the related Interpolators.
<br>
</blockquote>
<br>
I want to group the related interpolators with the driving
TImeSensor.<br>
<br>
<blockquote
cite="mid:C311A973DC1A441F98B676057B93EBEF@joe1446a4150a8"
type="cite">And, what do you lose by this automation?
<br>
</blockquote>
Nothing, since it is optional.<br>
<br>
<br>
<blockquote
cite="mid:C311A973DC1A441F98B676057B93EBEF@joe1446a4150a8"
type="cite">The human readable and easiy synthesized event graph.
<br>
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.
<br>
</blockquote>
<br>
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.<br>
<br>
<blockquote
cite="mid:C311A973DC1A441F98B676057B93EBEF@joe1446a4150a8"
type="cite">
<br>
Now there is only one rule that is important, that the def must
appear beore the route.
<br>
<br>
<br>
<blockquote type="cite">Each interpolator would automatically have
the TimeSensor's
<br>
/fraction_changed/ field automatically ROUTEd to the
interpolator's
<br>
/set_fraction/ input event field.
<br>
</blockquote>
<br>
<br>
"automatically" is fine, but, to me, much better when clearly
explicit and easily readable in the user code.
<br>
Sure you can alway invent a way to use various assets
'automagically' but what happens after?
<br>
The neat thing about the way we do it ow is that there is nothing
automatic, each Route completly describes what is needed.
<br>
<br>
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.
<br>
<br>
<blockquote type="cite">
<br>
<br>
3) Standard Practice: Put ROUTE statements as children of the
<br>
interpolator node that provides the source data. Combining (2)
and (3)
<br>
gives:
<br>
<br>
<TimeSensor ...>
<br>
<PositionInterpolator DEF='Mover' ...>
<br>
<ROUTE toNode='MoverTarget' toField='translation'
/>
<br>
</PositionInterpolator>
<br>
</TimeSensor>
<br>
</blockquote>
<br>
Please use set_translation.
<br>
What ar you losing when you try to convert from existing forms?
Looks compicated, if possible without handwork.
<br>
<br>
Me no like this style. Much better to have groups of TimeSensors,
Intrpolators, and ROUTEs.
<br>
Please look at some examples of complex animations, like
<br>
<br>
<a class="moz-txt-link-freetext" href="http://www.hypermultimedia.com/x3d/hanim/JoeSkin4EXSPYRWRJK.x3dv">http://www.hypermultimedia.com/x3d/hanim/JoeSkin4EXSPYRWRJK.x3dv</a>
<br>
<br>
<br>
<blockquote type="cite">
<br>
<br>
<br>
This would replace:
<br>
<br>
<TimeSensor DEF='Timer' ...></TimeSensor>
<br>
<PositionInterpolator DEF='Mover'
...></PositionInterpolator>
<br>
<ROUTE fromNode='Timer' fromField='fraction_changed'
toNode='Mover'
<br>
toField='set_fraction' />
<br>
<ROUTE fromNode='Mover' fromField='value_changed'
<br>
toNode='MoverTarget' toField='translation' />
<br>
<br>
</blockquote>
<br>
No, it would most likely replace One timesensor with 20
interpolaters and 49 routes. .
<br>
Since all interpolators may notbe run frm the smae timesensor,
<br>
<br>
<br>
<blockquote type="cite">
<br>
<br>
To preserve the past, this would be an optional construct.
<br>
</blockquote>
<br>
Please compose example of schema.
<br>
</blockquote>
<br>
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.<br>
<br>
<br>
<br>
<blockquote
cite="mid:C311A973DC1A441F98B676057B93EBEF@joe1446a4150a8"
type="cite">
<br>
<br>
<blockquote type="cite">This collects
<br>
the information involved in keyframe animation in one node
(TimeSensor).
<br>
</blockquote>
<br>
No, to me it locks information into an arbitrary semi-automated
structure with much added work for author and player.
<br>
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.)
<br>
</blockquote>
<br>
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.<br>
<br>
<br>
<br>
<br>
<blockquote
cite="mid:C311A973DC1A441F98B676057B93EBEF@joe1446a4150a8"
type="cite">
<br>
<br>
<blockquote type="cite">From previous mail:
<br>
</blockquote>
<br>
<blockquote type="cite">
<blockquote type="cite">For those few cases when a
'containerField' is required, is it
<br>
</blockquote>
> reasonable to define wrapper tags.
<br>
</blockquote>
<br>
Yes, if found, that has been done.
<br>
<br>
<blockquote type="cite"> while making the structure of the X3D
field easier to understand.
<br>
</blockquote>
<br>
First, for this topic there is one major question that has at
least two answers:
<br>
What is the actual function of the wrapper tag or the
containerField?
<br>
</blockquote>
<br>
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. <br>
<br>
<br>
<br>
<div class="moz-signature">-- <br>
<font class="tahoma,arial,helvetica san serif" color="#333366">
<font size="+1"><b>Leonard Daly</b></font><br>
3D Systems & Cloud Consultant<br>
X3D Co-Chair on Sabbatical<br>
LA ACM SIGGRAPH Chair<br>
President, Daly Realism - <i>Creating the Future</i>
</font></div>
</body>
</html>