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

Andreas Plesch andreasplesch at gmail.com
Mon Mar 28 08:19:30 PDT 2016


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*
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20160328/0919b03a/attachment-0001.html>


More information about the x3d-public mailing list