<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">Yves,<br>
      <br>
      I am not looking for an explosion of tags -- that would be to
      define each point in a Coordinate as an individual element. I
      specifically disavowed that position in my original post. <br>
      <br>
      From the one example I quickly found
(<a class="moz-txt-link-freetext" href="https://upload.wikimedia.org/wikipedia/commons/1/12/%D0%9F%D1%80%D0%B8%D0%BC%D0%B5%D1%80_%D1%87%D0%B5%D1%80%D1%82%D0%B5%D0%B6%D0%B0_%D0%B2_SVG_%D1%84%D0%BE%D1%80%D0%BC%D0%B0%D1%82%D0%B5.svg">https://upload.wikimedia.org/wikipedia/commons/1/12/%D0%9F%D1%80%D0%B8%D0%BC%D0%B5%D1%80_%D1%87%D0%B5%D1%80%D1%82%D0%B5%D0%B6%D0%B0_%D0%B2_SVG_%D1%84%D0%BE%D1%80%D0%BC%D0%B0%D1%82%D0%B5.svg</a>),
      the SVG uses many, many (on the order of 180,000) 'path' elements
      to create individual lines (e.g.,<br>
      <br>
      <blockquote><tt><path class="lt1"
          d="M302.72,-60.77L299.12,-60.77"/></tt><br>
      </blockquote>
      <br>
      This is very similar to what I have proposed with the exception
      that the data of the element be carried in the element value, not
      an attribute. My point for putting this in the value is to allow
      the use of CDATA to make the handling of strings more obvious.
      This also should apply to URLS as the above URL uses Greek
      characters.<br>
      <br>
      <br>
      Leonard Daly<br>
      <br>
      <br>
      <br>
    </div>
    <blockquote type="cite"
      cite="mid:A1475B4B-0354-4CC6-8391-01C170FC7B74@gmail.com">
      <blockquote type="cite">
        <pre wrap="">On 10 May 2017, at 06:43, Leonard Daly <a class="moz-txt-link-rfc2396E" href="mailto:Leonard.Daly@realism.com"><Leonard.Daly@realism.com></a> wrote:

Q: What problem are you trying to fix? 
A: There were three reasons provided in the original proposal. I will also add that this topic has generated numerous discussions on the public and WG lists since it was first introduced in V3.0. The rate of threads is (if memory is correct) about once per year. After 15+ years of X3D V3, this rate of discussion (and the extensive discussion in each occurrence) tells me that the documentation is not sufficient. After 4 versions of the standard, that tells me that it may not be possible to write sufficiently clear documentation and that the better solution would be to change the representation.
</pre>
      </blockquote>
      <pre wrap="">
I can't agree here. The documentation is problematic now and could be made formally correct if one states clearly what belongs to the XML standard and is kept outside the scope of X3D-XML, and what's the value stored in attributes.

Whether the result will be easy to understand for a novice is another question. Multilayer formats are bound to be complex; that's in itself a good reason to keep it as is and avoid loading it with exceptions and backward compatibility considerations. Storing structured data in an XML string is debatable, but certainly not specific to X3D. Coordinates in SVG, for instance, are also stored in long strings to avoid an explosion of tags.

Personally I don't see any decisive argument to change the encoding. It's only the standard wording which calls some adjustments.

Yves


</pre>
    </blockquote>
    <p><br>
    </p>
    <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>
        LA ACM SIGGRAPH Chair<br>
        President, Daly Realism - <i>Creating the Future</i>
      </font></div>
  </body>
</html>