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