[x3d-public] url MFString handling

Thu Apr 21 13:04:09 PDT 2022

➢ Let me propose that getting rid of "interpret" would suffice:

Maybe ‘resolve”? 
Meaning the file name has been found and delivered to the browser and ready to be loaded into the calling context? 
Autorefresh sort of complicates things a bit, so now I am looking for something “file found and loaded” Autorefresh must not try to reload if the loaded file content fails. 
Thanks, 
Joe

From: Andreas Plesch
Sent: Thursday, April 21, 2022 12:46 PM
To: Joseph D Williams
Cc: X3D Graphics public mailing list
Subject: Re: [x3d-public] url MFString handling

Hi Joe,

Thank you for your response which makes a lot of sense to me.

>
> 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.
>

Yes, I agree. This role should be clearly pointed out. The first file
which can be found and accessed should be considered selected for
further processing which then may lead to failure.  Unfortunately, I
think currently the spec. language is more vague.

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

says:

"All url fields can hold multiple string values. The strings in these
fields indicate multiple locations to search for data in the order
listed. If the browser cannot locate or interpret the data specified
by the first location, it shall try the second and subsequent
locations in order until a location containing interpretable data is
encountered. X3D browsers only have to interpret a single string. If
no interpretable locations are found, the node type defines the
resultant default behaviour."

Let me propose that getting rid of "interpret" would suffice:

"All url fields can hold multiple string values. The strings in these
fields indicate multiple locations to search for data in the order
listed. If the browser cannot locate the data specified by the first
string, it shall try the second and subsequent locations in order
until a location containing data is encountered. X3D browsers only
have to load a single location. If no accessible locations are found,
the node type defines the resultant default behaviour."

Happy to iterate if desired,

Andreas

>
> 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 All url fields can hold multiple string values. The strings in these fields indicate multiple locations to search for data in the order listed. If the browser cannot locate or interpret the data specified by the first location, it shall try the second and subsequent locations in order until a location containing interpretable data is encountered. X3D browsers only have to interpret a single string. If no interpretable locations are found, the node type defines the resultant default behaviour.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
>
>

-- 
Andreas Plesch
Waltham, MA 02453

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