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

Leonard Daly Leonard.Daly at realism.com
Sun Mar 27 08:54:35 PDT 2016


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 
>> <mailto: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 list
> X3dom-users at lists.sourceforge.net
> https://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/20160327/6ffe25ad/attachment-0001.html>


More information about the x3d-public mailing list