[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
> <MFVec3f DEF="ReusableTriangle" containerField="point">1.1
> 2.2 3.3, 4.4 5.5 6.6, 7.7 8.8 9.9</MFVec3f>
Whatever this is it is completely outrageous.
----- 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:
>> <Node text="entity-encoded 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
> 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
>> 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]
>> 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
>> <MFVec3f DEF="ReusableTriangle" containerField="point">1.1
>> 2.2 3.3, 4.4 5.5 6.6, 7.7 8.8 9.9</MFVec3f>
>> 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
> 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
> X3D graphics, virtual worlds, navy robotics
> x3d mailing list
> x3d at web3d.org
More information about the x3d-public