[x3d-public] [x3d] SFString/MFString Proposal [was: Agenda for X3D WG Open Meeting ...]

[Leonard Daly]

Yves,

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 
(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), 
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.


Leonard Daly



>> 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.
>
> Yves
>
>

-- 
*Leonard Daly*
3D Systems & Cloud Consultant
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/20170510/d6e66e35/attachment-0001.html>