<style>@font-face{font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;}</style><font face="Calibri"><p dir="ltr">Well, I am not sure if I can contribute much more to the discussion.</p>
<p dir="ltr">It might be a coincidence but I noticed that x3dom has a custom option to render to texture which can be used for mirror effects or mapping to curved projection surfaces, or stereo view. So things get reinvented if there is no easy way to first just ignore but not repel, then tentatively allow and finally absorb experimental features into a format for content.</p>
<p dir="ltr">I think a majority of x3dom's nodes have custom fields in addition to 'id' driven by application needs. Should we keep calling models using these nodes x3d based models or x3dom models ? The answer may be yes until there is a DTD for x3dom ?<br>
But there is also the html model of validation.</p>
<p dir="ltr">To me, a mode of validation which is able to ignore unknown elements would be very useful. From what I understand it may be possible to add a DTD fragment which catches all such elements and declares them as valid but I would not know how to. Or have a 'add to user node/attribute dictionary' for each unidentified element.</p>
<p dir="ltr">Andreas<br><br></p>
<br><br>On September 24, 2015, at 7:06 PM, Roy Walmsley <roy.walmsley@ntlworld.com> wrote:<br><br><br></font><html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0cm;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";
mso-fareast-language:EN-GB;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";
mso-fareast-language:EN-US;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-GB link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Andreas,<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Thank you for raising this discussion in the first place. It has been enlightening for me in a number of ways.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>With my example I did have nodes that contained all the original material properties and the additional ones for Infrared rendering. I also had additional Viewpoint nodes that specified the type of rendering to be undertaken. Also, we weren’t rendering to the screen directly, but rendering to texture. This meant that, at any instant, we could have as many viewpoints ‘simultaneously’ rendered as we desired, and they could be any mix of Infrared or Visual. Then we could display as many viewpoints in separate windows as we desired. We did have a separate viewer that did render directly to screen. Then we could choose to render either Infrared or visual. We knew the models with custom content were not pure VRML, and we simply said they were Open Inventor / VRML based.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Turning to X3DOM now. You are probably aware that the Web3D Consortium is working on a new version of the specification (V4.0) to cover usage of X3D in HTML5. This will address some of the issues you are noting. In my opinion, though, there is still likely to be a significant gap between X3DOM and the new X3D Specification set, since X3DOM does not conform to X3D in quite a number of ways. The Consortium hopes to release the first public draft of V4.0 for 19775-1 at the end of the year.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>The point you raise about ‘id’ usage and errors is noted. Scripts are likely to be one of the areas in the new version where there may be changes. Time will tell.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Regards,<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Roy<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Andreas Plesch [mailto:<a href="mailto:andreasplesch@gmail.com">andreasplesch@gmail.com</a>] <br><b>Sent:</b> 24 September 2015 21:46<br><b>To:</b> Roy Walmsley<br><b>Cc:</b> X3D Graphics public mailing list; John Carlson<br><b>Subject:</b> Re: [x3d-public] X3D file conformance philosophy<o:p></o:p></span></p><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal style='margin-bottom:12.0pt'>Wow, thanks again for engaging in this discussion. First, let me acknowledge that there is a lot of value in having a way to strictly define a format using DTD and Schema, and that it is important for any long-term viability to require extensions to follow the provided mechanisms.<o:p></o:p></p></div><div><p class=MsoNormal style='margin-bottom:12.0pt'>Also, I was not really aware that validation is a term reserved for a specific action in XML processing which probably does not exactly match what I would have associated with the term.<o:p></o:p></p></div><div><p class=MsoNormal style='margin-bottom:12.0pt'>But, to use your example, would it not be useful to be able claim that your infrared scenes have correct (allowable?, viable?) VRML content, say if you included a switch to choose between infrared and regular materials which would allow approximate rendering in regular VRML renderers but at the same time allow special purpose rendering with a custom renderer ? Without going through the DTD extension/registration process ? In fact, you may have referred to your scenes as VRML informally. Should there be way to formally designate such a scene as viable (valid) VRML but not strictly conforming (pure) ?<o:p></o:p></p></div><div><p class=MsoNormal>What triggered this discussion for me was my attempt to use x3d-edit for x3dom scenes which at first glance does not seem unreasonable. I was just surprised to find out that the little 'id' attribute which is required for x3dom elements to work with scripts triggered so many validation errors that there was a "too many errors to report" (or similar) message. My expectation was simply that the validator would be silent about items which it does not need to be concerned about. Of course, I did not realize that the validator needs to be concerned about everything due to the strict conformance rules.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal style='margin-bottom:12.0pt'>Perhaps the real issue is the (perceived?) difficulty of writing a correct DTD and/or Schema with the result that those rarely materialize. But this would be a XML issue not a X3D issue although it has these consequences.<o:p></o:p></p></div><div><p class=MsoNormal>I would argue that an exclusive approach to conformance becomes a significant problem if it slows adoption and helps to maintain the gap between x3d, the format, and x3dom, probably the most widely used x3d browser, currently.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>-Andreas<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>On Thu, Sep 24, 2015 at 2:20 PM, Roy Walmsley <<a href="mailto:roy.walmsley@ntlworld.com" target="_blank">roy.walmsley@ntlworld.com</a>> wrote:<o:p></o:p></p><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Andreas,</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>John raised an additional point that is also worth expanding on.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>One of the general aims of the Web3D Corporation is round-trip-ability. What this means is starting off with a file in one encoding, converting it to a second encoding, and the converting it again back to the first encoding. It is expected that the resulting file, while not textually identical, will have identical functionality and display identically.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Another general aim is maximising compatibility. Both backwards and forwards. This maximises the lifetime of authored content.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Another general aim is maximising reuse and portability of authored scenes.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>You can see that custom content is going to scupper these aims. So I personally believe that the specification, in defining what is a ‘conforming’ X3D file, is essentially correct and should be maintained (although see below for one exception).</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Let me quote an example of ‘custom content’ from my own experience. I was a co-developer of a 3D simulation. This was begun many years ago, so used Open Inventor, and then VRML. The difference for us was that we wanted to render in the Infrared spectrum, not visual. That meant, not only modifying the rendering process, but also creating additional nodes to characterise materials in ways appropriate to Infrared rendering. We accepted that we could not use any standard viewer, but would have to write our own. Now, with the advance of time and the standardization of X3D one course of action open to me would be to update the additional custom VRML nodes we created to X3D nodes. I could then create an extension to the Schema and DTD, covering the new nodes, and have it registered. This would also include a new COMPONENT definition. See 4.10 Component and profile registration <a href="http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/concepts.html#componentprofilereg" target="_blank">http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/concepts.html#componentprofilereg</a>.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Now, you are right about f. in that case, but e. is OK. With that one proviso my custom content becomes conforming X3D. Standard browsers would immediately recognise they couldn’t display my custom content through the COMPONENT statement. Any other implementer could extend their browsers to cover my custom content if they so desired. My custom content then becomes more widely usable.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Returning to the issue of the validator, I believe it should point out all the things it finds as errors. After all, you don’t have to fix them! And you probably have to check fully every time. We all know how easy it is introduce typos! And one would assume that the majority of the X3D file is conforming with only a relatively small portion that is custom content. Or are you thinking something different here? Perhaps you could illustrate the sort of ‘custom content’ you are referring to. And why you believe it to be a significant problem.</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Best regards,</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Roy</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> John Carlson [mailto:<a href="mailto:yottzumm@gmail.com" target="_blank">yottzumm@gmail.com</a>] <br><b>Sent:</b> 24 September 2015 17:04<br><b>To:</b> Andreas Plesch<br><b>Cc:</b> X3D Graphics public mailing list; Roy Walmsley<br><b>Subject:</b> Re: [x3d-public] X3D file conformance philosophy</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p>One thing to consider is schema based conversion from one encoding to another.<o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>On Sep 24, 2015 10:20 AM, "Andreas Plesch" <<a href="mailto:andreasplesch@gmail.com" target="_blank">andreasplesch@gmail.com</a>> wrote:<o:p></o:p></p><div><div><div><div><div><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt'>Hm,<o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt'>to me a validation tool is simply not able to reason about or make any judgement about nodes and fields it does not know anything about (other than that it does not know them). So to me the main (perhaps only) point of a validation tool is to pick up out of bound fields, missing DEFs for routes, missing required nodes, and such. And existing tools do that well, I think.<o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt'>So, yes, I think a reduced activity tool would be very useful, and there may be a way to disable warnings about unknown elements in the validator bundled with x3d-edit. Could it be done ?<o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt'>I think the existing phrasing in the spec. for conformance captures well what valid x3d content is, except for items e), f) and perhaps h) in <br><br><a href="http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/conformance.html#ConformanceX3Dfiles" target="_blank">http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/conformance.html#ConformanceX3Dfiles</a><o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt'>which would not relate to validity if understood in a more inclusive sense.<o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt'>A concern may be that it would not be possible to flag '<Tansform>' as syntax error which is clearly desirable. And as a consequence all unknown elements have to be defined as syntactically incorrect.<br><br>But would it not make sense to separate this concern from concerns which actually can be addressed more specifically by what is contained in the spec. such as out of bound fields ? Have two buttons, one for possible syntax errors, and one for deeper, x3d related checking ?<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt'>Best regards,<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Andreas<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><div><div><div><div><div><div><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>On Thu, Sep 24, 2015 at 8:46 AM, Roy Walmsley <<a href="mailto:roy.walmsley@ntlworld.com" target="_blank">roy.walmsley@ntlworld.com</a>> wrote:<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt'>Andreas,<br><br>Referring to your final comment below I would say that a validation tool that does not complain about nodes and fields it does not know would make that tool largely useless! After all, apart from picking up out of bounds field values, or detecting missing required content, the point of a validation tool is to complain about things it doesn't recognise. How else does it tell you about errors? Validators, if they are well written, will already tell you what sort of problem they have found, i.e. the equivalent of your classification of deviations.<br><br>It sounds like you either need a reduced activity validation tool, or else to teach your validation tool about the extra things that you permit in your X3D authored files.<br><br>Finally I would raise two questions: What is valid X3D content? How does a validation tool definitively categorize custom content from errors in valid X3D content?<br><br>Best regards,<br><br>Roy<br><br>-----Original Message-----<br>From: Andreas Plesch [mailto:<a href="mailto:andreasplesch@gmail.com" target="_blank">andreasplesch@gmail.com</a>]<br>Sent: 24 September 2015 13:13<br>To: Roy Walmsley<br>Cc: X3D Graphics public mailing list<br>Subject: Re: [x3d-public] X3D file conformance philosophy<br><br>Roy,<br><br>you bring up many good points. I completely agree that there are many ways to extend the standard.<br><br>This includes the option for browsers to provide DTD and Schema for extensions which quite a few browsers support. However, in practice this is rarely done.<br><br>You are right that validation software can only detect deviations from the standard as a reference. But I think it could be designed to classify deviations into ones which contradict references and ones which it cannot further analyse because reference documents do not provide the necessary information. In fact, many validators may already do that.<br><br>So what could be done ?<br><br>In order to be more inclusive, Web3d could introduce a definition of validity in parallel to conformance which would allow more documents to claim that they have valid x3d content alongside custom content.<br><br>I think, in practice all I may be looking for is for a validation tool which does not complain about nodes and fields it does not know.<br><br>Andreas<br><br>On September 24, 2015, at 5:13 AM, Roy Walmsley <<a href="mailto:roy.walmsley@ntlworld.com" target="_blank">roy.walmsley@ntlworld.com</a>> wrote:<br><br>Andreas,<br><br>I would also offer the following consideration into the debate, continuing with the current terminology just for the sake of maintaining clarity of understanding between us.<br><br>Let's say I am a software engineer developing software that validates an X3D file, utilising either or both of the DTD and the Schema. I design my software to detect 'deviations' in X3D files from the DTD/Schema reference documents. When such 'deviations' are found, how are they to be reported? My software isn't going to know if a 'deviation' is an author's intention or simply a mistake. It can only report (notwithstanding very clever heuristics) that the X3D file is not valid, pointing out the errors.<br><br>Of course, the author also has the option of creating extensions to the Schema and or DTD that cover the differences. These would allow software validators to pass an X3D file containing extensions above and beyond the specifications.<br><br>Of course, when we are talking DTD and Schema we are also talking XML. Which, of course, stands for Extensible Markup Language. So an author already has the option to make their own private additions.<br><br>And then, an author can just create their X3D file with additions, and ignore error messages from validation tools.<br><br>So, from the perspective of the Web3D Corporation (and here I am only expressing my own personal opinion), what can be done? The Corporation does not wish to control authors content, merely to provide a standard to enable the widespread use and distribution of 3D graphics content. While this naturally has limits, it also includes methods to permit individual author extensions. HTML is standardized, with validators. It too provides methods for extension of the basic standards. Perhaps for HTML these are more well known, whereas for X3D they are less publicized.<br><br>Best regards,<br><br>Roy<br><br>-----Original Message-----<br>From: Andreas Plesch [mailto:<a href="mailto:andreasplesch@gmail.com" target="_blank">andreasplesch@gmail.com</a>]<br>Sent: 24 September 2015 04:51<br>To: Roy Walmsley<br>Cc: X3D Graphics public mailing list<br>Subject: Re: [x3d-public] X3D file conformance philosophy<br><br>Roy, thank you for your thoughtful response.<br><br>Of course, authors who choose to include non-standard elements are not able to have an expectation that the content renders as intended in all browsers. In a sense, labeling such content as not conforming is redundant. To me, perhaps a better use of the label 'conforming' would be simply an assurance that used nodes and fields which are actually standardized conform to the standard, eg. <Box size='square' /> would be not conforming.<br><br>So I am still not quite sure what the benefit is of considering foreign elements in terms of conformity.<br><br>From a semantic point of view, perhaps a better fit would be purity or fidelity. A pure x3d file consists exclusively of standardized components.<br><br>Validity would be another concept which to me signals a tolerance. All x3d standardized components in a valid x3d file conform to the standard but it may also contain other (xml) content.<br><br>Considering that part of the success of html is often seen as due to its nonchalance towards unspecified content, this kind of dry discussion is probably more relevant than it seems.<br><br>Andreas<br><br>On Wed, Sep 23, 2015 at 6:51 PM, Roy Walmsley <<a href="mailto:roy.walmsley@ntlworld.com" target="_blank">roy.walmsley@ntlworld.com</a>> wrote:<br><br>Hi Andreas,<br><br><br><br>You have expounded an interesting view.<br><br><br><br>What if Conformance did not apply in the restricted sense. An X3D author would be able to create files that had additional undefined (and non-conforming) content. Browser implementers they would be then be free to support whatever extras they wished and still be classed as ‘conforming’. So, suppose an author creates an X3D file with extras that is supported on one particular browser. If the author were to share the file with others they may be restricted to only using the one particular browser that supports those particular extras. Other ‘conforming’ browsers would be unable to display the content.<br><br><br><br>Obviously, it is desirable that X3D authors, should they wish, be free to share their X3D files with other users. The concept of restricted conformance ensures that if that same file is loaded into other conforming browsers then the display will be the same, reproducing the authors intentions.<br><br><br><br>There are mechanisms already available for authors to generate conforming content that has additional features. The first and most obvious is the use of Prototypes. The second is to have definitions for additional nodes, both in terms of specification and validation tools such as DTD and Schema. These can be registered and made publicly available if it is envisaged that they will have sufficiently wide usage. Of course, there is ways the ultimate third case, whereby additional features are incorporated into the specifications. Anyone can present drafts for consideration to the Web3D Consortium, provided they have at least two implementations to support the new features.<br><br><br><br>So my personal view is that it is better to retain the restricted conformance testing. But I am always open to further discussion ….<br><br><br><br>Best regards,<br><br><br><br>Roy<br><br><br><br>From: x3d-public [mailto:<a href="mailto:x3d-public-bounces@web3d.org" target="_blank">x3d-public-bounces@web3d.org</a>] On Behalf Of Andreas Plesch<br>Sent: 23 September 2015 18:55<br>To: X3D Graphics public mailing list<br>Subject: [x3d-public] X3D file conformance philosophy<br><br><br><br>Using the x3d validator and quality assurance tools which come with x3d-edit, it will become quickly apparent that an x3d file is deemed conforming (or syntactically correct) only after it passes a series of very strict tests which are defined here:<br><br><a href="http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/conformance.html#ConformanceX3Dfiles" target="_blank">http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/conformance.html#ConformanceX3Dfiles</a><br><br><br><br>For example, referencing a field of a node which is not listed in the spec. but is supported by a x3d browser (say "id") will put the x3d file in the unconforming category. Is this correct ?<br><br>Similarly, referencing nodes and behaviours which are not explicitly defined in the spec. will break conformance.<br><br>This is in contrast to the concept of validity of html files which are deemed valid even if they include elements not defined in the spec.<br><br>So, what is the philosophy of having a narrow definition of file conformance ?<br><br>It may be that it defines minimum functionality for a x3d browser.<br><br><br><br>A x3d browser is said to be conforming when it allows browsing of a conforming file as a minimum requirement.<br><br>But this convention would still apply if a conforming file could include custom (non-spec.) nodes and fields which a conforming browser would be allowed to ignore.<br><br><br><br>Another way to think about the usefulness of strict conformance may be to explore the consequences of restricting tests for conformance only to nodes, fields, behaviours and such with which the spec. is actually concerned. What would break if ignoring all other elements in browsers and parsers would be considered conforming ?<br><br>In my view, a strict view of file conformance shifts responsibility from the browser to the x3d content author. To me, this is a somewhat inverted view which may need to be reconsidered.<br><br><br><br>-Andreas<br><span style='color:#888888'><br><br>--<br><br>Andreas Plesch<br>39 Barbara Rd.<br>Waltham, MA 02453<br><br><br><br><br>--<br><br>Andreas Plesch<br>39 Barbara Rd.<br>Waltham, MA 02453<br><br></span><o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><br><br clear=all><br>-- <o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Andreas Plesch<br>39 Barbara Rd.<br>Waltham, MA 02453<o:p></o:p></p></div></div></div></div></div></div></div></div></div></div></div><p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt'><br>_______________________________________________<br>x3d-public mailing list<br><a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a><br><a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" target="_blank">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a><o:p></o:p></p></div></div></div></div><p class=MsoNormal><br><br clear=all><br>-- <o:p></o:p></p><div><p class=MsoNormal>Andreas Plesch<br>39 Barbara Rd.<br>Waltham, MA 02453<o:p></o:p></p></div></div></div></div></body></html>