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

Joe D Williams joedwil at earthlink.net
Fri May 19 00:14:51 PDT 2017


>     <Coordinate>
>         <MFVec3f DEF="ReusableTriangle" containerField="point">1.1 
> 2.2 3.3, 4.4 5.5 6.6, 7.7 8.8 9.9</MFVec3f>
>     <Coordinate>

Whatever this is it is completely outrageous.

Joe


----- Original Message ----- 
From: "Don Brutzman" <brutzman at nps.edu>
To: "Leonard Daly" <Leonard.Daly at realism.com>; <x3d-public at web3d.org>; 
"x3d WG" <x3d at web3d.org>
Sent: Wednesday, May 17, 2017 9:27 AM
Subject: Re: [x3d] [x3d-public] SFString/MFString Proposal [was: 
Agenda for X3D WG Open Meeting ...]


> Thanks for further discussions on teleconference today, that helped.
>
> On 5/9/2017 9:43 PM, Leonard Daly wrote:
>> I am going to attempt to answer the questions posed by Don. If 
>> something is missing it was inadvertently excluded. The proposed 
>> structure is extracted and included here for easy of discussion:
>>
>> 1:
>> <Node text="entity-encoded text"></Node>
>>
>> OR
>>
>> 2:
>> <Node>
>>       <text>text-string</text>
>>       <text>text-string</text>
>>       <text>text-string</text>
>>       <text>text-string</text>
>>       <text>text-string</text>
>> </Node>
>>
>> Where (1) is a single-valued string (either SFString or the first 
>> element of an MFString)
>> and (2) is an MFString with (in this listing) five elements.
>>
>> Q: Is such a redesign of the XML tree possible?
>> A: This might be a rhetorical question as it was immediately 
>> answered. Of course it is possible. There is nothing in XML that 
>> would prohibit this proposed structure.
>
> Correct.  Many XML tree designs are possible.
>
>> Q: Are 2-way conversion mappings possible?
>> A: I don't see why conversion from the existing V3.3 definition is 
>> not mapable to this proposed definition. While I do not doubt that 
>> there is a mapping backwards, I wonder why that would be pursued.1
>
> Round trip mapping shows completeness and correctness.
>
> Backwards compatibility to the greatest extent possible is a design 
> requirement.  That way we know that all X3D 3 content, tools, etc. 
> might be representable.
>
>> 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 believe you have given a motivation - hoping to make things 
> clearer.
>
> Your rationale does not mention that thousands of working examples 
> are available, and no unrepresentable-content examples have been 
> identified.  This point has been made many times.  I believe that it 
> should be part of all discussions like this, so that we can focus on 
> functional improvements.
>
> Rephrasing: what technical problem are you trying to fix?
>
>> Q: [wasn't specifically asked, but just used without comment] 
>> Container fields.
>> A: I think 'container' fields in many (maybe even in all) cases 
>> were incorrect. V4 is an opportunity to correct that.
>
> Correct what?  You are still not saying.  The system works.
>
> It seems as if many of your points are trying to take us back circa 
> 2000.  Comprehensive list of design issues:
>
> Wrapper Tags Considered Harmful
> http://www.web3d.org/x3d/content/examples/Basic/development/WrapperTagsConsideredHarmful.html
>
>> Q: [not quite sure where the questions are in this] "Am thinking 
>> that if you really want a data holder for flexible re-use, then 
>> using existing X3D datatype names makes more sense than a 
>> role-based name.  But major concerns immediately appear.  Such an 
>> approach adds more code everywhere, and more complex validation, 
>> and changes to converters, and a much greater potential-error 
>> surface.  So we'd probably need to be very sparing with it... but 
>> it would be possible to list some example cases that might be 
>> improved (not fixed), so tradeoff evaluation is conceivable. "
>> A: The goal is not a flexible reusable container, but a clearer way 
>> of representing the data.
>
> Of note is that "Clearer" is in the eye of the beholder, if two 
> equivalent approaches are being compared.
>
>> A: Not sure what is meant by "more code everywhere". Generally 
>> using spell-out tag names and clear data structure makes clearer 
>> code, documentation, and is less error-prone.
>
> Meaning: much code already exists, and it works.  So adding more 
> syntax adds more code.  That includes the entire validation chain.
>
>> A: I am not sure how it makes validation more complex -- I just 
>> don't know enough to answer.
>
> The X3D XML DTD and X3D XML Schema would require pretty much 
> complete rewriting.  Perhaps a skeleton of structure could be used 
> to start that effort.
>
> Checkpoint:  these tools that get impacted have taken years of 
> effort to develop and test and confirm correct.
>
>> A: Converters are going to need to change anyway, it might as well 
>> be done all at once.
>
> Incremental changes are much different than complete changes.
>
> Nothing happens all at once, development and testing and 
> verification requires much effort.
>
> Nearly all of our file encodings and language bindings are 
> intertwined - now as evidenced by Object Model for X3D (OM4X3D).
>
> Similarly, as Roy noted today, this kind of encoding modification 
> impacts all DOM invocations as well.
>
>> A: It is not obvious that the "error surface" is increased
>
> If you change the majority of tools, and all the examples, you have 
> a much greater error surface.
>
>> Q: "Finally, not evident what you are trying to express with extra 
>> | characters in <![CDATA|[ etc.  "
>> A: Those are not my typing. It was introduced by my email client 
>> (Thunderbird) or some other point in the email from me to you. All 
>> of the CDATA references should be the normal expression [remove 
>> spaces between each character]
>> < ! [ C D A T A [ contents-of-character-data ] ] >
>>
>>
>> Leonard Daly
>
> Thank you for clarifying that point.  I will look at those again.
>
> [...]
>
> I suspect that the Metadata* nodes might be improvable by a small 
> modification of default containerField values.  That discussion is 
> on different threads (and Mantis issues).
>
> Another design vector worth further consideration was 2 messages 
> back in the thread:
>
> [... my response 8 May]
> http://web3d.org/pipermail/x3d-public_web3d.org/2017-May/006651.html
>> Might a hybrid be useful?  Conceivably... for a special case.  For 
>> example, when some geometry nodes have large index arrays or value 
>> arrays, those aren't always easy to adapt DEF/USE constructs into 
>> different roles.  Perhaps elements corresponding to X3D field types 
>> might be a useful alternative encoding when building large scenes - 
>> similar to your <Coordinate><point> example but maybe more general 
>> like
>>
>>     <Coordinate>
>>         <MFVec3f DEF="ReusableTriangle" containerField="point">1.1 
>> 2.2 3.3, 4.4 5.5 6.6, 7.7 8.8 9.9</MFVec3f>
>>     <Coordinate>
>>
>> Am thinking that if you really want a data holder for flexible 
>> re-use, then using existing X3D datatype names makes more sense 
>> than a role-based name.  But major concerns immediately appear. 
>> Such an approach adds more code everywhere, and more complex 
>> validation, and changes to converters, and a much greater 
>> potential-error surface.  So we'd probably need to be very sparing 
>> with it... but it would be possible to list some example cases that 
>> might be improved (not fixed), so tradeoff evaluation is 
>> conceivable.
>
> Another example that might better illustrate this point is to take 
> an IFS and ILS that share the same Coordinate node but have 
> different index arrays.  I'll work on that.
>
> all the best, Don
> -- 
> Don Brutzman  Naval Postgraduate School, Code USW/Br 
> brutzman at nps.edu
> Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA 
> +1.831.656.2149
> X3D graphics, virtual worlds, navy robotics 
> http://faculty.nps.edu/brutzman
>
> _______________________________________________
> x3d mailing list
> x3d at web3d.org
> http://web3d.org/mailman/listinfo/x3d_web3d.org 




More information about the x3d-public mailing list