[x3d-public] [x3d] SFString/MFString Proposal [was: Agenda for X3D WG Open Meeting ...]
Leonard.Daly at realism.com
Wed May 10 07:33:44 PDT 2017
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.
From the one example I quickly found
the SVG uses many, many (on the order of 180,000) 'path' elements to
create individual lines (e.g.,
<path class="lt1" d="M302.72,-60.77L299.12,-60.77"/>
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.
>> On 10 May 2017, at 06:43, Leonard Daly <Leonard.Daly at realism.com> 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.
> 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.
3D Systems & Cloud Consultant
LA ACM SIGGRAPH Chair
President, Daly Realism - /Creating the Future/
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the x3d-public