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

[Don Brutzman]

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