<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
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<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, 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 the HTML encoding<br>
<br>
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.<br>
<br>
<br>
As another note, the JSON encoding has a little different
constraints because case does matter in JavaScript. There may be
additional considerations.<br>
<br>
<br>
Leonard Daly<br>
<br>
<br>
<br>
<br>
<blockquote cite="mid:56F74B70.9060604@realism.com" type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
<div class="moz-cite-prefix">Andreas,<br>
<br>
</div>
<blockquote
cite="mid:CAKdk67sY_PBXUycNtgBTLshgyYgO15+XoYAD8MVwx4F5JULK2Q@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>Leonard,<br>
<br>
</div>
thanks for the background. This is very helpful. Let me see
how I understand the background.<br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Thu, Mar 24, 2016 at 11:37 AM,
Leonard Daly <span dir="ltr"><<a
moz-do-not-send="true" href="mailto:web3d@realism.com"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:web3d@realism.com">web3d@realism.com</a></a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>Andreas,<br>
<br>
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.]<br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>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 ?<br>
</div>
<div><br>
<a moz-do-not-send="true"
href="http://www.web3d.org/documents/specifications/19776-1/V3.3/Part01/definitions.html">http://www.web3d.org/documents/specifications/19776-1/V3.3/Part01/definitions.html</a><br>
<br>
</div>
<div>ID is the name of a data type.<br>
<br>
<a moz-do-not-send="true"
href="http://www.web3d.org/documents/specifications/19776-1/V3.3/Part01/concepts.html#DEFAndUSEAttributeSyntax">http://www.web3d.org/documents/specifications/19776-1/V3.3/Part01/concepts.html#DEFAndUSEAttributeSyntax</a><br>
<br>
</div>
<div>DEF is an attribute of type ID.<br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div> 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.<br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Well, currently, conforming x3d scenes cannot have an
ID value, right ? They can just have DEF values of type
ID. <br>
</div>
</div>
</div>
</div>
</blockquote>
<br>
Rereading what I wrote, I realize that it is not clear enough.
Trying again...<br>
<br>
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.<br>
<br>
<br>
<br>
<blockquote
cite="mid:CAKdk67sY_PBXUycNtgBTLshgyYgO15+XoYAD8MVwx4F5JULK2Q@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div> <br>
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.<br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Inlining the same file multiple times is a good case
to consider. x3d has IMPORT/EXPORT to avoid collisions,
and x3dom has namespacename. <br>
</div>
</div>
</div>
</div>
</blockquote>
<br>
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<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
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.<br>
<br>
<br>
<br>
<blockquote
cite="mid:CAKdk67sY_PBXUycNtgBTLshgyYgO15+XoYAD8MVwx4F5JULK2Q@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div> <br>
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.<br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>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. <br>
</div>
<div>It may a good idea to adopt namespacename in the x3d
spec. as well.<br>
</div>
</div>
</div>
</div>
</blockquote>
<br>
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.<br>
<br>
<br>
<br>
<blockquote
cite="mid:CAKdk67sY_PBXUycNtgBTLshgyYgO15+XoYAD8MVwx4F5JULK2Q@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div> <br>
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.<br>
<br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Completely agree. It does not make sense to have two
labels for the same function.<br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div> Perhaps DEF can be deprecated and ID be used
going forward for all encodings. If both are
specified, then ID overrides DEF.<br>
<br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>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.<br>
</div>
<div>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.<br>
<br>
</div>
<div>Another interim solution may be to define an implicit
ID attribute in the spec. which always has the value of
the DEF field. <br>
<br>
</div>
<div>To make this discussion more concrete, here is a
proposal:<br>
</div>
<div><br>
<a moz-do-not-send="true"
href="http://www.web3d.org/documents/specifications/19776-1/V3.3/Part01/concepts.html#NodeAndFieldStatementSyntax">http://www.web3d.org/documents/specifications/19776-1/V3.3/Part01/concepts.html#NodeAndFieldStatementSyntax</a><br>
<br>
</div>
<div>could be amended by:<br>
<br>
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.<br>
</div>
</div>
</div>
</div>
</blockquote>
<br>
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.<br>
<br>
<br>
Leonard Daly<br>
<br>
<br>
<br>
<br>
<blockquote
cite="mid:CAKdk67sY_PBXUycNtgBTLshgyYgO15+XoYAD8MVwx4F5JULK2Q@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> <br>
</div>
<div>Feel free to criticize this proposal. Hopefully, the
process can be constructive. <br>
</div>
<div><br>
</div>
<div>-Andreas<br>
</div>
<div> </div>
</div>
</div>
</div>
</blockquote>
<br>
<br>
<div class="moz-signature">-- <br>
<font class="tahoma,arial,helvetica san serif" color="#333366">
<font size="+1"><b>Leonard Daly</b></font><br>
X3D Co-Chair<br>
Cloud Consultant<br>
President, Daly Realism - <i>Creating the Future</i> </font></div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
<a class="moz-txt-link-freetext" href="http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140">http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140</a></pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
X3dom-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:X3dom-users@lists.sourceforge.net">X3dom-users@lists.sourceforge.net</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/x3dom-users">https://lists.sourceforge.net/lists/listinfo/x3dom-users</a>
</pre>
</blockquote>
<br>
<br>
<div class="moz-signature">-- <br>
<font class="tahoma,arial,helvetica san serif" color="#333366">
<font size="+1"><b>Leonard Daly</b></font><br>
3D Systems & Cloud Consultant<br>
X3D Co-Chair on Sabbatical<br>
LA ACM SIGGRAPH Chair<br>
President, Daly Realism - <i>Creating the Future</i>
</font></div>
</body>
</html>