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

[John Carlson]

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
>>> <http://www.web3d.org/documents/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/3f223a6a/attachment.html>