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

[Andreas Plesch]

Hi,

Joe, thanks for taking this in and a step further.

On Mon, Mar 28, 2016 at 2:43 PM, Joe D Williams <joedwil at earthlink.net>
wrote:

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

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 ?


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

Yes, this is my thinking as well.

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

ok.


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

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 ?


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

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.


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

Yes, hopefully we can a find fairly simple solution to formalize use of an
id attribute.

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.


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

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.

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

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 ?

Andreas


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


-- 
Andreas Plesch
39 Barbara Rd.
Waltham, MA 02453
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20160328/4d95c91c/attachment-0001.html>