[x3d-public] Invalid geoSystem values in X3D Resources BasicGeospatial examples.

[John Carlson]

Note:

http://www.web3d.org/member-only/mantis/view.php?id=938

Sent from Mail for Windows 10

From: John Carlson
Sent: Sunday, May 13, 2018 8:14 AM
To: Andreas Plesch
Cc: X3D Graphics public mailing list
Subject: Re: [x3d-public] Invalid geoSystem values in X3D Resources BasicGeospatial examples.

The object model is expressive enough to list conforming values, yet accept others, but as far as I know (I may be wrong here), it is not expressive enough to express supported geoSystem values.   This is a problem.   How do we resolve it, and should we, if we are accepting other values?   Is it resolved in X3DJSAIL?  Should I get rid of Roy's JSON subschema for geoSystem?

John

On Sun, May 13, 2018, 7:43 AM John Carlson <yottzumm at gmail.com> wrote:
I believe the purpose of schema is to support minimally acceptable files.   It should flag files which are questionable.   If a file can be brought into conformance easily, shouldn't it be?

Yes, you should be able to ignore the results of the schema validation...at your own risk.

What is the purpose of the X3D resources examples, but to show a good example practice?  Or are we testing tools to make sure certain values are acceptable?   If that's the case, then the schema should be updated for ALL versions.

John

On Sun, May 13, 2018, 7:31 AM John Carlson <yottzumm at gmail.com> wrote:
Then the version of the document should be upgraded to 4.0 or above, and the corresponding schema updated.   I can upgrade the schema for all versions, since it is hard coded into the schema generator.   But really we need support from the object model if possible.   Right now, I have to explicitly allow it for all versions, since I use stdin/stdout instead of files.  Does the unified object model specify a version # in its contents?  When the unified object model supports "N" in a usable fashion, then I can code something into the schema, or delete the requirement to check geoSystem.

Thanks, away from computer presently, or I would check.

I don't see why Roy went to all the effort to create a schema, if we are going to ignore it?

This applies in many areas...if we merely have supported values, yet others must be accepted, why is there a standard?

I don't believe it's ambiguous in this case of X3D.   A missing "N" means Northern Hemisphere.

John

On Sun, May 13, 2018, 12:46 AM Andreas Plesch <andreasplesch at gmail.com> wrote:
http://www.web3d.org/specifications/19775-1/V3.2/Part01/components/geodata.html#Specifyingaspatialreference

lists the supported strings for the geoSystem MFString field.

The prose choosing 'supported' over 'legal' or 'conforming' could be taken to mean that other than listed strings may be allowed to be supported as well by some browsers.

However, previous discussions indicate that schemas are not sufficiently expressive to describe unknown but conforming string values.

One resolution was to explicitly allow 'N' in upcoming X3D version, and perhaps silently allow it for 3.3.

Outside of X3D UTM zones often have the N hemisphere identifier to avoid ambiguity.

Andreas




Date: Sat, 12 May 2018 19:54:17 -0400
From: John Carlson <yottzumm at gmail.com>
To: Don Brutzman <brutzman at nps.edu>,  X3D Graphics public mailing list
        <x3d-public at web3d.org>
Subject: [x3d-public] Invalid geoSystem values in X3D Resources Basic
        Geospatial examples.
Message-ID: <5af77ea8.1c69fb81.7da1f.13e3 at mx.google.com>
Content-Type: text/plain; charset="utf-8"

Don, These files contain "N" in geoSystem, which I believe is not valid, and should be removed (default is Northern Hemisphere,  in the standard, I believe. "S" can be specified?not in this case).

Is there a tool which hasn?t been changed which is 
_______________________________________________
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/20180513/3fad798e/attachment-0001.html>