<div dir="auto">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?<div dir="auto"><br></div><div dir="auto">Yes, you should be able to ignore the results of the schema validation...at your own risk.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">John</div></div><br><div class="gmail_quote"><div dir="ltr">On Sun, May 13, 2018, 7:31 AM John Carlson <<a href="mailto:yottzumm@gmail.com">yottzumm@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>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.</div><div dir="auto"><br></div><div dir="auto">Thanks, away from computer presently, or I would check.</div><div dir="auto"><br></div><div dir="auto">I don't see why Roy went to all the effort to create a schema, if we are going to ignore it?</div><div dir="auto"><br></div><div dir="auto">This applies in many areas...if we merely have supported values, yet others must be accepted, why is there a standard?</div><div dir="auto"><br></div><div dir="auto">I don't believe it's ambiguous in this case of X3D.   A missing "N" means Northern Hemisphere.</div><div dir="auto"><br></div><div dir="auto">John</div><div dir="auto"><br><div class="gmail_quote" dir="auto"><div dir="ltr">On Sun, May 13, 2018, 12:46 AM Andreas Plesch <<a href="mailto:andreasplesch@gmail.com" target="_blank" rel="noreferrer">andreasplesch@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div><a href="http://www.web3d.org/documents/specifications/19775-1/V3.2/Part01/components/geodata.html#Specifyingaspatialreference" rel="noreferrer noreferrer" target="_blank">http://www.web3d.org/specifications/19775-1/V3.2/Part01/components/geodata.html#Specifyingaspatialreference</a></div><div dir="auto"><br></div><div dir="auto">lists the supported strings for the geoSystem MFString field.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">However, previous discussions indicate that schemas are not sufficiently expressive to describe unknown but conforming string values.</div><div dir="auto"><br></div><div dir="auto">One resolution was to explicitly allow 'N' in upcoming X3D version, and perhaps silently allow it for 3.3.</div><div dir="auto"><br></div><div dir="auto">Outside of X3D UTM zones often have the N hemisphere identifier to avoid ambiguity.</div><div dir="auto"><br></div><div dir="auto">Andreas</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote" dir="auto"><div dir="ltr"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Date: Sat, 12 May 2018 19:54:17 -0400<br>
From: John Carlson <<a href="mailto:yottzumm@gmail.com" rel="noreferrer noreferrer noreferrer" target="_blank">yottzumm@gmail.com</a>><br>
To: Don Brutzman <<a href="mailto:brutzman@nps.edu" rel="noreferrer noreferrer noreferrer" target="_blank">brutzman@nps.edu</a>>,  X3D Graphics public mailing list<br>
        <<a href="mailto:x3d-public@web3d.org" rel="noreferrer noreferrer noreferrer" target="_blank">x3d-public@web3d.org</a>><br>
Subject: [x3d-public] Invalid geoSystem values in X3D Resources Basic<br>
        Geospatial examples.<br>
Message-ID: <<a href="mailto:5af77ea8.1c69fb81.7da1f.13e3@mx.google.com" rel="noreferrer noreferrer noreferrer" target="_blank">5af77ea8.1c69fb81.7da1f.13e3@mx.google.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
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).<br>
<br>
Is there a tool which hasn?t been changed which is <br>
</blockquote></div></div></div>
_______________________________________________<br>
x3d-public mailing list<br>
<a href="mailto:x3d-public@web3d.org" rel="noreferrer noreferrer" target="_blank">x3d-public@web3d.org</a><br>
<a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer noreferrer noreferrer" target="_blank">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a><br>
</blockquote></div></div></div></blockquote></div>