[x3d-public] url MFString handling

Joseph D Williams joedwil at earthlink.net
Thu Apr 21 12:17:30 PDT 2022


>  I am trying to add support and wonder how to deal
> with corner cases.

What are the corner cases? If the first is not found, then try the next, until no choices, then whatever the node should do, mostly nothing because it is like nothing is there. For example if no viewpoints or anchors found in the list, then nothing happens. A browser might automatically offer something to the user, but not stop. A good author would have made sure appropriate content is there.

This is an authoring problem , not a user problem. 😊

If no interpretable locations are found, the node type defines the resultant default behaviour.

The results are undefined if the URL refers to a file that is not a supported file type, or if the file contains invalid content.

(order of precedence determines priority):

So, if none of the named file is not there, then generally, no action taken. 

At runtime for inline, I don’t see how or why the x3d browser would be responsible for checking whether the file being loaded is a legal scene before loading it. We would assume, that like for jpeg or script the author would validate the scene to be loaded. 

How about the script node? To publish, you might list the url location first, but also put in the source code for if the file location is not available. But if I put the actual source code first then the file url location second, the browser should certainly not try to load the second  choice if the first script fails due to syntax or execution problems. 

This urls feature really only handles problems with finding the file and delivering contents, not dealing with the validity of actual contents of the file. 

As for json and gltf, same thing. Runtime expects the delivered data to  be legal contents as defined by the author. If the data is wrong, like some stuff not matching, then, something else fails, not the loading process. 

Thanks for all on this, Andreas, 
Joe

From: Andreas Plesch
Sent: Thursday, April 21, 2022 10:06 AM
To: X3D Graphics public mailing list
Subject: Re: [x3d-public] url MFString handling

Are there suggestions on how to handle back-up "#viewpoint" style urls
for Anchor in case Viewpoints with matching def names do not exist ?

https://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/networking.html#Anchor

paragraph nine explains that in this case:

"In this case, if the node derived from X3DViewpointNode is not found,
no action occurs on activation."

This seems to mean that back-up #viewpoint urls should not be tried so
that no action can occur. Would that make the most sense ?

I actually cannot think of a use case for back-up #viewpoint urls, so
that case may be intentionally left ill defined and open to browser
implementations.

Any feedback welcome,

Andreas

On Tue, Apr 19, 2022 at 9:34 PM Andreas Plesch <andreasplesch at gmail.com> wrote:
>
> x3dom currently lacks support for back-up urls to use if the first
> urls do not work. I am trying to add support and wonder how to deal
> with corner cases.
>
> The spirit of the spec. here is pretty clear:
> https://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/networking.html#X3DUrlObject
>
> says that a url which cannot be located or if the retrieved data
> cannot be interpreted should be skipped. Subsequent urls are then used
> as back-ups.
>
> Currently, x3dom checks if an inline x3d url can be parsed as xml and
> if so if it has a Scene element.
>
> The first corner case happens if there is a X3D element but it does
> not contain a Scene element. This could be interpreted to mean an
> empty X3D document with an empty Scene, or that it perhaps should be
> skipped as not interpretable. I would probably favor skipping as this
> would normally happen by mistake.
>
> The second corner case is a Scene element without content. Should such
> X3D be considered interpretable ?  I think x3dom is currently set up
> to parse it without error resulting in an empty Scene, probably with
> default NavigationInfo and Viewpoint. So this could be considered
> interpretable and not be skipped.
>
> https://www.web3d.org/x3d/content/examples/X3dSceneAuthoringHints.html#urls
>
> says a result needs to be "legal". But legal is by definition what is
> provided in the spec., eg. comes down to being interpretable.
>
> The tooltip at https://www.web3d.org/x3d/content/X3dTooltips.html#Inline.url
>
> does not seem to further clarify.
>
> Any feedback appreciated,
>
> Andreas
>
> --
> Andreas Plesch
> Waltham, MA 02453



-- 
Andreas Plesch
Waltham, MA 02453

_______________________________________________
x3d-public mailing list
x3d-public at web3d.org
http://web3d.org/mailman/listinfo/x3d-public_web3d.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20220421/91174c0b/attachment.html>


More information about the x3d-public mailing list