[x3d-public] [x3d] SFString/MFString Proposal [was: Agenda for X3D WG Open Meeting ...]
Joe D Williams
joedwil at earthlink.net
Tue May 23 09:46:57 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.
Well of course we know what that syntax is: a blend of x3d and more
recent or archaic (take your choice) syntax that is also capable of
being strongly typed. The x3d syntax works from the functionalty of
the object by giving an object name that represents some scenegraph
functionality, defines default data format(s), and operations with
that data and other nodes. The second form(s) (exampled here by
Leonard) start with a defined variable type then assign a
functionality to that data.
Well there must be a better descripton somewhere, but the mian idea is
that Hey, this systax may serve an important function for some
authors. Please notice that for comparable structures, the intended
functionality of these constrcts are probably close enough to allow an
author to compose the stuff using the alternaive syntax then use style
sheet too recompose the user code into x3d.
>> <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>
>> <MFVec3f DEF="ReusableTriangle" containerField="point">1.1
note improper use of containerField where the name identifies the data
type of the element not the acceptable type of the containing node,
even though its wrapper tag Coordinate. recall problems with wrapper
tags?
Note that an alternative to above as seen in the past of this list was
something like:
<MFVec3f name='Coordinate DEF="ReusableTriangle"
containerField='geometry'>1.1 2.2 3.3, 4.4 5.5 6.6, 7.7 8.8
9.9</MFVec3f>
Please recall that for the DOM and for SAI, the html browser is not
required to maintain a full live DOM image. That is, the browser does
not need to eep a live DOM, it just has to operate as if a complete
live DOM image is available to the DOM interfaces. Same for X3D SAI,
the browser is not required to maintain a complete live scenegraph,
the browser just needs to support the SAI interfaces as if the live
scenegraph is available.
Same for syntax, if you as a x3d toolamer wish to claim support for
x3d you can accept any syntax, style it to x3d and run the stuff.
Maybe it is ok to accept many possible sytaxes and as long as the
browser uses the data same as prescribed in an x3d scenegraph, then
all is ok.
Small difference we might say, but when we compare small differences
in syntaxes, like the above where "ReusableTriangle" element
represents the point attribute in x3d syntax. Could anyone show a
completed node using this syntax sowe could tell if the intent is an
user-indexed or defalut-indexed geomtery?
Anyway, if sombody liked this style of encoding, then it would be
available and with a clever glossary of structures and DEF strings
maybe could create some stuff that could be styled into x3d.
But mainly, the above example is not enough of a thought to even
consider. It only offers a small glimpse into the actual requirements
of user code to describe some geometry.
>> Of note is that "Clearer" is in the eye of the beholder, if two
>> equivalent approaches are being compared.
Please consider that the example offered above is actually not
comaparable to anything exept possibly an alternative to a part of
aome geometry node. It is not enough of an example to show features of
this alternative
Thanks,
Joe
>
> 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
>
>
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
More information about the x3d-public
mailing list