[x3d-public] [x3dom-users] DEF to ID mapping

[Joe D Williams]

Hi,
Nice thinking Andreas. As Leonard explained, a DEF is not an id. X3D 
user code running in (X)HTML doesn't need id for every node.

Integrating an id into X3D for use in (X)HTML documents means that at 
minimum an id is necessary for any node that is referenced from an 
'external' HTML script, meaning a script that accesses the DOM tree 
from outside the <X3D> ... </X3D> user code boundaries. So, if a user 
chooses to control the X3D user code using DOM interfaces in the 
'external' HTML script, then an id is required for each element 
addressed by the DOM user code. Thus, there is no need for concern 
about id attributes if the X3D code is not accessed by the DOM. The 
SAI operates normally just as the X3D author intended (with some 
exceptions that must all be noted such as no Script, and some other 
limitations that have not been figured out yet).

If I am right about the above, then DEF needs to be allowed as an 
attribute in X3D code used in (X)HTML so that the SAI can operate as 
expected, and id needs to be allowed in X3D files so that 'external' 
(X)HTML scripts can access the DOM tree. For (X)HTML integration, the 
(limited) SAI uses the DEF and the 'external' DOM script uses the id. 
In 'true' X3D processors the id, if found, is simply not used or even 
usable for anything

If the X3D file does not use SAI Script or an SAI feature not figured 
out yet then no problem, just copy and paste the code following the 
simple instructions.

If the author is converting a scripted X3D file created and developed 
for use in the DOM for running in a true X3D processor, then the user 
must convert the DOM script to use SAI features, using an SAI script 
if necessary.

Likewise if a user is converting a file created and developed for an 
X3D processor using SAI, then scripts and some other features must be 
converted from X3D SAI into X3D DOM.

So, to me this DEF vs id is not a big deal. DEFs will probably be 
ignored by an (X)HTML processor and ids will probably be ignored by an 
X3D processor. The key here for (X)HTML is no SAI scripting allowed, 
and various other details, many of which will have a template-like 
script solution, which should be simplified in the long run.

I don't see where a script developed for an (X)HTML processor will be 
run by an X3D processor without changes, and vice-versa. For the 
current time, until we can use SAI scripts directly, I don't see where 
we can contrive a solution for complete transportability between X3D 
applications and (X)HTML applications. For now, for X3D applications 
that require scripting to run in (X)HTML and for X3D applications that 
run using SAI scripts have different features, structures, and 
environments so require special considerations (more than simple 
transcoding) in order to run the same way in different spaces.

Overall, I think it is very important to get a complete list of 
standard X3D SAI features that are not implemented in X3D DOM and then 
to create the (X)HTML scripting templates to provide those features. 
We know there are other problems. like duplicate names and namespace 
considerations, and these are mostly problems that need solving in the 
(X)HTML environment, not in the X3D environment. I mean we know that 
'standard' X3D timers and interpolators and routes work as expected in 
X3D user code running in the (X)HTML environment, but which features 
of X3D, like scripts, sensors, etc., don't work or require some 
(X)HTML scripting?

Thanks and Best,
Joe





----- Original Message ----- 
From: "Andreas Plesch" <andreasplesch at gmail.com>
To: "Leonard Daly" <Leonard.Daly at realism.com>
Cc: "x3dom mlist" <x3dom-users at lists.sourceforge.net>; "X3D Graphics 
public mailing list" <x3d-public at web3d.org>
Sent: Monday, March 28, 2016 8:19 AM
Subject: Re: [x3d-public] [x3dom-users] DEF to ID mapping


> Hello,
>
> first, let's assume that it is possible to delay introducing a new 
> HTML
> encoding by recognizing that xhtml is an application of xml (
> http://www.w3.org/TR/html5/the-xhtml-syntax.html#xhtml). Since html 
> is much
> more widely used than xhtml, it would be desirable to also have a 
> HTML
> encoding but I think given limited resources it is wise divide and 
> conquer
> as much as possible.
>
> Here is an attempt to organize what was discussed into distinct 
> options.
>
> There are two principal options:
>
> 1. Replace DEF with ID
>
> This would be a straightforward renaming of the DEF attribute as an
> encoding of the DEF statement to ID.
>
> 2. Allow ID in parallel to DEF
>
> There are then these alternatives:
>
> A. ID mirrors DEF
>
> The value of the ID attribute in the encoding is always is the same 
> as DEF.
>
> B. ID can differ from DEF
>
> ID can have a different value than DEF but there may be rules for 
> default
> values. x3dom has such rules.
>
> There may be other options which can be added to this list
>
> Discussion
>
> The options have implications for scene graph vs. encoding 
> specifications,
> x3d backward compatibility and x3dom compatibility.
>
> Option 1
>
> As the simplest option, it is attractive. A simple change in the XML
> encoding spec. may be all what is needed. The scene graph spec. does 
> not
> need to be affected.
>
> The drawback is loss of complete backward compatibility. However, it 
> is not
> difficult to replace or start using ID in place of DEF. Also, x3dom 
> and
> some x3dom apps would need to be updated. The required changes 
> should be
> minor but would need to be made
>
> Option 2A
>
> It is probably possible to define this option in the XML encoding 
> spec.
> alone. Considering first encoding of an abstract scene graph to XML 
> format,
> it would mean to express the DEF statement in two attributes with 
> the same
> value. This may seem unusual but would be necessary. Considering the 
> more
> common case of decoding XML data to a scene graph data structure 
> next, it
> would be expected that most commonly only one of the two attributes 
> is
> given in the XML source. In this case, the DEF statement's name 
> would
> become the value of the given attribute. However, the case where ID 
> and DEF
> are both given and are colliding would also need to be handled 
> either by
> giving one attribute preference or by leaving the decoding behaviour
> explicitly undefined.
>
> The case where only the DEF the attribute is given poses the 
> question if in
> this case the value of the ID attribute should be specified in the 
> encoding
> spec. . It is a question because the spec. strictly only deals with
> encoding and decoding from and to the x3d scene graph, and ID would 
> not be
> part of the scene graph. I think the expectation by authors would be 
> that
> the id attribute would have an implied value which is the same as 
> the DEF
> attribute.
>
> The advantage of this option is better backward compatibility since
> existing XML encoded scenes could be used as is.
>
> The drawback is that it is somewhat confusing to have two attributes 
> with
> identical values and function. Another drawback that some x3dom apps 
> would
> need to be updated but fewer than for option 1. Also x3dom would 
> need to be
> updated somewhat.
>
> Option 2B
>
> This option may require introducing an additional ID field to the 
> scene
> graph spec, for most (or all) nodes (and statements ?), as well as 
> defining
> an expression of this field in the xml (and other) encoding spec. 
> The sole
> function of this field would be to provide an additional label which 
> may or
> may not the be same as the DEF name. The id label can then be used 
> by APIs
> such as the DOM API to access a node (or statement?).
>
> There then may be rules to define a default value for the ID field 
> or
> create (an implicit) DEF name.
>
> x3dom has rules which are DOM centric, eg. ID defines DEF:
>
> a) If both ID and DEF are given the ID field will have a different 
> values
> from the DEF name.
> b) If only DEF is given, the ID field's default value is the empty 
> string.
> c) If only ID is given, a DEF statement with a name equal to the ID 
> value
> is implicitly created.
>
> X3D centric rules would be:
>
> a) If both ID and DEF are given the ID field will have a different 
> values
> from the DEF name.
> b) If only DEF is given, the ID field value is the DEF name.
> c) If only ID is given, no DEF statement or name is created.
>
> neutral rules would be:
>
> a) If both ID and DEF are given the ID field will have a different 
> values
> from the DEF name.
> b) If only DEF is given, the ID field value is the empty string.
> c) If only ID is given, no DEF statement or name is created.
>
> The advantage of this option is good backward compatibility with 
> both
> existing x3d and x3dom scenes scenes and apps, if the x3dom rule set 
> is
> adopted. Also x3dom would not need to be updated. Other x3d browser 
> only
> need to be updated if they want to provide id functionality to an 
> API.
>
> The drawbacks are required, somewhat deeper changes to the x3d scene 
> graph
> spec. However, it may be possible to define these changes in a 
> global way
> in sufficiently precise manner. Also, it may be confusing to some 
> x3d dom
> authors to have two attributes with very similar function. However, 
> this is
> how x3dom currently works so many are used to it.
>
> The SAI could but does not need to be updated to take advantage of 
> the new
> ID field.
>
> My favorite is currently option 2A, for which I gave initial spec. 
> language
> to consider.
>
> Andreas
>
>
>
>
>
> Scene graph and encoding spec are affected.
> On Mar 27, 2016 11:56 AM, "Leonard Daly" <Leonard.Daly at realism.com> 
> wrote:
>
>> I forgot to add to the discussion of encoding. There will need to 
>> be a new
>> specification or major sub-part of the existing XML encoding to 
>> support X3D
>> in HTML. This is necessary because
>>
>> 1) Assuming that X3D in HTML will follow the same style as HTML
>>   a) case does not matter for element (node) or attribute (field) 
>> names
>>   b) unrecognized elements are silently ignored
>>   c) there is no <?xml... or <!DOCTYPE... or other XML header 
>> statements
>>   d) there may be need to identify additional reserved names (e.g., 
>> HTML,
>> BODY)
>> 2) There needs to be at least two types of X3D content
>>   a) embedded within HTML
>>   b) external to HTML (e.g., for use as Inline) but still 
>> compatible with
>> the HTML encoding
>>
>> For the most part the HTML encoding will look a lot like the XML 
>> encoding.
>> It might even be possible to lift much of the text from the 
>> existing XML to
>> start the HTML document.
>>
>>
>> As another note, the JSON encoding has a little different 
>> constraints
>> because case does matter in JavaScript. There may be additional
>> considerations.
>>
>>
>> Leonard Daly
>>
>>
>>
>>
>> Andreas,
>>
>> Leonard,
>>
>> thanks for the background. This is very helpful. Let me see how I
>> understand the background.
>>
>> On Thu, Mar 24, 2016 at 11:37 AM, Leonard Daly < 
>> <web3d at realism.com>
>> web3d at realism.com> wrote:
>>
>>> Andreas,
>>>
>>> When the XML encoding spec was written (about the turn of the 
>>> century
>>> now...) we anticipated the use of 'id' in nodes. It was never used 
>>> as a
>>> field name for that reason. [Note: I will use ID instead of 'id' 
>>> below.]
>>>
>>
>> Ok. it was anticipated that an additional id attribute was used in 
>> xml
>> (xhtml) nodes defining a x3d scene ? So there should be a way to 
>> make such
>> a scene spec. conforming ?
>>
>>
>> http://www.web3d.org/documents/specifications/19776-1/V3.3/Part01/definitions.html
>>
>> ID is the name of a data type.
>>
>>
>> http://www.web3d.org/documents/specifications/19776-1/V3.3/Part01/concepts.html#DEFAndUSEAttributeSyntax
>>
>> DEF is an attribute of type ID.
>>
>>
>>> It is good practice not to reuse names that must be unique within 
>>> a
>>> namescope/namespace, even external to that scope. So while there 
>>> are no
>>> explicit provisions preventing it, DEF names and ID values should 
>>> not
>>> appear within the same scene; however, I don't think it can be 
>>> stated that
>>> it is never the case.
>>>
>>
>> Well, currently, conforming x3d scenes cannot have an ID value, 
>> right ?
>> They can just have DEF values of type ID.
>>
>>
>> Rereading what I wrote, I realize that it is not clear enough. 
>> Trying
>> again...
>>
>> So while there are no explicit provisions preventing it, the names 
>> used
>> for DEF and the values used for ID should be duplicated within the 
>> scene.
>> E.g., DEF='foo' and ID='foo' (except for the same node) should not 
>> be used.
>> Remember this is a recommendation and not a requirement.
>>
>>
>>
>>
>>
>>>
>>> DEF functions a little different than ID. DEF is name-scope 
>>> limited. Each
>>> X3D occurrence of a file defines its own name scope. Also each 
>>> PROTO or
>>> CreateX3dFromString/Url is its name scope. If an X3D file contains
>>> DEF='foo' and it is Inlined multiple times, each occurrence of 
>>> 'foo' is
>>> different from any other occurrence of 'foo'. This is also a 
>>> historical.
>>> Until X3DOM, X3D always ran in it's own environment. In X3DOM, it 
>>> is
>>> running in the DOM environment. X3DOM takes care to prefix DEF 
>>> names to
>>> prevent collisions.
>>>
>>
>> Inlining the same file multiple times is a good case to consider. 
>> x3d has
>> IMPORT/EXPORT to avoid collisions, and x3dom has namespacename.
>>
>>
>> Correct IMPORT/EXPORT allow you to "rename" a name-scoped DEF name 
>> from
>> child scene to the parent scene using a different DEF name in the 
>> parent's
>> name scope
>>
>> -- main.x3dv
>> DEF F1 Inline {url: "foo.x3d"}
>> IMPORT F1.bar AS f1Bar
>> DEF F2 Inline {url: "foo.x3d"}
>> IMPORT F2.bar AS f2Bar
>> DEF F3 Inline {url: "foo.x3d"}
>> IMPORT F3.bar AS f3Bar
>>
>>
>> --- foo.x3d
>>         :
>>         :
>> <EXPORT localDEF='FooNode' AS='bar' />
>>         :
>>
>>
>> So in 'main.x3dv' f1Bar refers to 'FooNode' in the first inline of
>> foo.x3d. There are three separate copies of the foo.x3d content and 
>> each
>> can evolve separately. The 'namespacename' attribute of the X3DOM 
>> <Inline
>> ... /> node works the same way except there is no need to EXPORT 
>> anything
>> from foo.x3d. The entire contents of foo.x3d is available to its 
>> parent. If
>> there is no value for 'namespacename' then there is no DOM entry 
>> for those
>> nodes. I do not know what happens if the main level Inlines a file1 
>> without
>> specifying namespacename and file1 Inlines file2 and specifies
>> namespacename.
>>
>>
>>
>>
>>
>>>
>>> For ID, what is needed is globally (within the HTML page) unique 
>>> values,
>>> including any Inlined, generated, or inserted nodes. I don't think 
>>> it is
>>> possible to require that across all X3D code. Even if there was 
>>> some sort
>>> of international registry, it would still fail if an X3D file was 
>>> Inlined
>>> more than once. X3DOM avoids the name conflict issue by requiring 
>>> the
>>> developer to create a prefix.
>>>
>>
>> It is necessary for ID to be unique on the web page (globally). 
>> Both x3d
>> and x3dom have mechanisms to make this easy for scene or web page 
>> authors.
>> In theorym x3dom could implement IMPORT/EXPORT instead of using
>> namespacename.
>> It may a good idea to adopt namespacename in the x3d spec. as well.
>>
>>
>> This is a mater of philosophy. X3DOM allows the entire contents to 
>> be
>> exposed to the DOM. IMPORT/EXPORT only allow what the Inlined node 
>> wishes
>> to allow at the node level. It is not possible to control access at 
>> the
>> field level unless the content creator takes special care during
>> construction. OO languages usually provide mechanisms to 
>> reveal/protect
>> variables and methods. Other languages (e.g., Perl) expose 
>> everything, but
>> have adopted conventions to "protect" internal data. JavaScript (at 
>> least
>> as of V5) is of the second category. I think X3D for HTML should 
>> follow the
>> same conventions as the version of ECMAScript that is
>> used/supported/required.
>>
>>
>>
>>
>>
>>> I think it would be good to only have a single node label. If you 
>>> have
>>> different values for DEF and ID, there is always the confusion as 
>>> to which
>>> one goes (or does) what. If they are the same value, why have two 
>>> labels.
>>>
>>>
>> Completely agree. It does not make sense to have two labels for the 
>> same
>> function.
>>
>>
>>> Perhaps DEF can be deprecated and ID be used going forward for all
>>> encodings. If both are specified, then ID overrides DEF.
>>>
>>>
>> Yes, this is the (big) question. If not for backward compatibility, 
>> I
>> think simply stop using DEF and instead using ID would help a lot.
>> Perhaps, it is time take this fork in the road. The problem is it 
>> would
>> make all x3d scenes which use DEF invalid. Replacing all 
>> occurrences of DEF
>> with ID is not difficult, however.
>>
>> Another interim solution may be to define an implicit ID attribute 
>> in the
>> spec. which always has the value of the DEF field.
>>
>> To make this discussion more concrete, here is a proposal:
>>
>>
>> http://www.web3d.org/documents/specifications/19776-1/V3.3/Part01/concepts.html#NodeAndFieldStatementSyntax
>>
>> could be amended by:
>>
>> A node instance can be given a label using the attribute DEF 
>> followed by
>> an equals sign and the quoted name of the node, as provided by the 
>> DEF
>> statement. In addition, for DOM compatibility reasons, an 
>> additional
>> attribute with the name ID is expressed implicitly which has the 
>> same
>> value. This ID attribute is not part of the x3d scene graph but it 
>> is part
>> of the fully parsed xml data structure and allows access to the 
>> element by
>> the DOM API.
>>
>>
>> In a quick review and think, I am not sure if the above statement 
>> causes a
>> conflict with the definition of DEF in 19776-1 4.3.4 (link above). 
>> To me,
>> something does not feel right. I am not sure if it is my lack of
>> understanding and full appreciation of your statement or a 
>> premonition of a
>> conflict or extra complexity.
>>
>>
>> Leonard Daly
>>
>>
>>
>>
>>
>> Feel free to criticize this proposal. Hopefully, the process can be
>> constructive.
>>
>> -Andreas
>>
>>
>>
>>
>> --
>> *Leonard Daly*
>> X3D Co-Chair
>> Cloud Consultant
>> President, Daly Realism - *Creating the Future*
>>
>>
>> ------------------------------------------------------------------------------
>> Transform Data into Opportunity.
>> Accelerate data analysis in your applications with
>> Intel Data Analytics Acceleration Library.
>> Click to learn 
>> more.http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140
>>
>>
>>
>> _______________________________________________
>> X3dom-users mailing 
>> listX3dom-users at lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/x3dom-users
>>
>>
>>
>> --
>> *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
>