[x3d-public] Scripts and Proto-X in V4

[John Carlson]

Vincent,

I believe effort should be spent on a second implementation of Proto-X
nodes and Scripts so they can be standardized.  If they require eval and
lack of a real script node and are somewhat difficult to debug, so be it.

John

On May 21, 2017 9:57 PM, "Vincent Marchetti" <vmarchetti at kshell.com> wrote:

The second piece of the v4 puzzle would be a new profile for web-browser
X3D that would only include those parts of X3D that we know how to
standardize, omitting Script and Proto-X nodes that are still topics of
debate. I am aware that implementations such as Cobweb+Andreas Plesch work
have made great progress in implementing hte Script and ProtoX nodes, and
those implementations can continue to offer those, but they may not be
ready to be burned into a standards document.


Vince Marchetti





> On May 21, 2017, at 12:23 PM, Leonard Daly <Leonard.Daly at realism.com>
wrote:
>
> I have been thinking about the conversation last week regarding MFString
and the idea of splitting up the attribute elements into child elements.
This message deals with the XML (and future HTML) encoding.
> Dick stated that he was against the idea because it treated MFString
differently than other MF fields. After much thought I realized that
MFString is already treated differently than other MF fields. In
particular, MFString field elements are required to be double-quoted and
separated by whitespace. 19776-1 5.1.2 uses the term "whitespace" without
providing further definition of whitespace.[1] I presume that would include
the normal definition of "whitespace" to include all characters which
render as "horizontal or vertical space in typography" (
https://en.wikipedia.org/wiki/Whitespace_character)[2].
>
> If that same policy were applied to all MF fields, then each element of
the field would need to be double-quoted. For example using the MFVec3f
'point' point='"0 0 0" "1 0 0" "0 1 0" "0 0 1" "1 1 0" "1 0 1" "0 1 1" "1 1
1"' because each triple is a single element of the MFVec3f field. This is
not the case, so it differs from MFString. If the argument goes that
elements of MFString may contain any character so a special structure is
needed to 'contain' the individual elements so one element doesn't bleed
into another; then there is no reason to make containment explicit using
the existing mechanisms in XML -- child elements. This has the further
advantage of separating the elements into a form that can be dealt with at
the XML level instead of the application level.
>
> SVG deals with multi-line (aka multi-element) text using child elements.
See the example at https://www.w3schools.com/graphics/tryit.asp?filename=
trysvg_text4 where the SVG tag 'text' contains the tag 'tspan' to offset
(vertically and horizontally) multiple lines of text.
> Moving MFString elements into separate child elements also allows other
facilities of XML to be used to handle the characters previously reserved
as attribute and element delimiters.
>
> [1] If there is another place in the document that defines whitespace it
should either be referenced from here or moved to this section.
> [2] This section (3rd paragraph) also states that MF fields are "written
... enclosed in quotations...". I believe that the quotations reference is
part of the XML standard for encoding attributes and should be removed from
here. Otherwise, MF fields would need to be encoded as (using MFFloat as an
example) key='"0. .1 .2 .3 .4 .5 .6 .7 .8 .9 1."'
>
> --
> Leonard Daly
> 3D Systems & Cloud Consultant
> LA ACM SIGGRAPH Chair
> President, Daly Realism - Creating the Future
> _______________________________________________
> x3d mailing list
> x3d at web3d.org
> http://web3d.org/mailman/listinfo/x3d_web3d.org


_______________________________________________
x3d mailing list
x3d at web3d.org
http://web3d.org/mailman/listinfo/x3d_web3d.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20170522/21fdd2c1/attachment.html>