[x3d-public] X3D V4 Thoughts

[Joe D Williams]

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

That is, there  are cases where the containng node can only allow 
certain child nodes. The containerField tells if the child node is ok 
for the containing node.

Why do we even bother to try to identify which containing field is ok 
for the node with the containerField to be a child of?

Was this attribute invented for X3D XML or was there a similar sort of 
situation(s) in VRML? If there was, then how was this done in VRML.

>> 1. Multiple inheritance of abstract and concrete nodes?
>> The X3D object hierarchy ... This examination is mainly taking 
>> place using a weekly
>> phone conference
>>
>
> I don't think I asked or even mentioned this topic.

Right, so far you are hitting on two of the top three.

>> 2. Why do we need wrapper ags or containerField
>>
>> Well, ... 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.

Fine. Again, why do we even need anything like the wrappertag or 
containerField funtionality?

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

Good. Let's try to be there with the latest thoughts and capabilities. 
.

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

Than sounds like a great basic guide to node representation. So, about 
this 'attributes are metadata' concept, in a simple shape then do you 
suggest that coordinates are data but coordindex is metadata? (that is 
just how your example was presented.) At least related data are 
treated the same. True, i remember people having trouble with the 
default handling in a standard html or XML parser due to size since 
element data was passed forward directly while attribute data was 
held. I remeber saying once that the list of coordinates was a string 
of characters, like the letters in a <p> tag then later got asked this 
same question.

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

That is a point, but I still don't think it is the prime or most 
important discussion. For most models, the size of the attr is not a 
problem.

> It matters because you cannot put CDATA sections into an attribute.

When do I wish to do this in a field that is not now an element?

> Attributes are metadata about the contents.

OK, then the only thing we goyya do is figure out shich fields of 
which nodes are metadata and which are data. Actual of potential size 
of the field should not matter.

> Large quantities of data are not metadata, especially in the case of 
> points, coordinates, indices, normals, text strings, etc.

OK, then continue through *all' the nodes and make your calls.

>
> Why would it be nice to keep the point keyword?

eer, uh, because we have always had it?

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

Well then is the justificaion is not coming from considered experience 
then ... sooner or later we need some real examples that show how this 
philosophy about attrs for metadata and elements for data works out.
There is no doubt in my mind that most any arrangement will work and 
that there will be many opportunities to discuss that big question of 
what is data and what is metadata.

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

I think accessing attrs and element content with the DOM is close 
enough to be called equivalent.

> No. Schemas are too complex and potentially filled with errors.

Sorry to hear that since I think XML schema is really an important 
tool.

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

Sorry, out of range of my interest if you are producing examples yet 
are not interested in also evaluating tools for detailed validation of 
content. In my mind, you propose a node signature, then document it 
with schema so we can see ifj we can have a working validation. No big 
problem in this and if the schema can't document the node, then we 
need to look at the node.

For X3D in HTML or XHTML, then if you don't consider starting with an 
analysis of what you can do with schema, then it is also too early to 
propose various encoding of nodes solutions. I am pretty sure you can 
arrange v4 just about any way you wish with some alternative 
constructions, just recall that you also must have an automated 
conversion process from one construction to another. I don't think 
anyone can even evaluate an alternative form without also a guaranteed 
conversion from new to old and old to new.


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

I think you want to use simlar methods to the X3D SAI. The greatest 
pride will come from stuff that validates, works fine in X3DOM, and 
also will play in a probably high(er) performance dedicated X3D 
browser.

> When on the server side, the data gets put into an element, not an 
> attribute.

Does this happen automatically?

Leonard, thanks for bringing some of this up because it is always 
appropriate to bring in questions from users.
I hope my tone is not dismissive, hopefully just being a voice for the 
existing syntax.

Thanks and Best,
Joe







----- Original Message ----- 
From: "Leonard Daly" <Leonard.Daly at realism.com>
To: "X3D Graphics public mailing list" <x3d-public at web3d.org>
Sent: Thursday, December 24, 2015 8:59 AM
Subject: Re: [x3d-public] X3D V4 Thoughts


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


--------------------------------------------------------------------------------


> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>