[x3d-public] dual use of script tag in HTML environment

[Andreas Plesch]

More relevant references, this time on the x3d side, and a thought
experiment:

http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/scripting.html#Scriptlanguages
:
MIME type is provided by the server serving the URL.

http://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/networking.html#ScriptingLanguageProtocols
http://www.web3d.org/documents/specifications/19777-1/V3.3/Part1/concepts.html#SupportedScriptURLs
in-line protocol defined by special "ecmascript:" URL protocol definition

MIME type for external script is application/ecmascript (not
application/x-vrmlscript anymore) : required or recommended ?

Question: also explicitly allow additional MIME types:
application/x-vrmlscript or/and application/x-x3dscript etc. ?

http://www.web3d.org/documents/specifications/19776-1/V3.3/Part01/concepts.html#EncapsulatingScriptNodeCode
defines CDATA child construct as additional value for url MFString url
field .

http://www.web3d.org/documents/specifications/19776-1/V3.3/Part01/EncodingOfNodes.html#Script
encoding

Thought experiment for a backward compatible specification:

Introduce a 'type' field for the script node:
SFString [in, out] type "application/ecmascript" [MIME type]

The type field defines the MIME type for the provided script, similar to
the type attribute of the HTML script element. In case an external script
is referenced, the MIME type returned by the external resource, if any,
takes precedence. In case of an inline script provided with the ecmascript:
protocol identifier, the field's value defines the MIME type. It is
possible to provide any of the MIME types for script content defined in
http://www.web3d.org/documents/specifications/19777-1/V3.3/Part1/concepts.html#MIMEType
to ensure its recognition. Other values may lead to undefined behaviour,
prevent execution of the script.
[Perhaps the following would belong to the XML encoding standard? ] Note
that in a HTML environment the script element is typically first
interpreted by an HTML browser. It is recommended to use an explicit type
field value of 'application/x-vrmlscript' in this case. This value prevents
the HTML browser from executing the script but then allows the X3D browser
to interprete and execute it using the SAI.

Would such a new type field be (largely) backward compatible ?

-Andreas



















On Thu, Sep 22, 2016 at 3:21 PM, Andreas Plesch <andreasplesch at gmail.com>
wrote:

> Here some relevant resources with regards to the script element and its
> dual use:
>
>
> HTML5 spec. of script element:
>
> https://www.w3.org/TR/html5/scripting-1.html#script
>
>
> HTML5 spec. of the mime types which must be recognized and executed by web
> browser
>
> https://www.w3.org/TR/html5/scripting-1.html#support-the-
> scripting-language
>
> The same section also specifies a few mime types which must not be
> executed by the browser. For example, 'application/xml' will never be
> interpreted and executed by a browser.
>
>
> http://www.bitmanagement.com/developer/spec/vrmlscript/
> vrmlscript.html#Protocol
>
> http://www.bitmanagement.com/developer/spec/vrmlscript/
> vrmlscript.html#MIMEtype
> 1996 SGI vrmlscript MIME type recommendation.
>
>
>
> On Wed, Sep 21, 2016 at 11:30 PM, Andreas Plesch <andreasplesch at gmail.com>
> wrote:
>
>> https://andreasplesch.github.io/cobweb_dom/tests/x3d_script.xhtml
>>
>> Since the script tag is already claimed by HTML, there is a conflict with
>> the XML encoding of the x3d script node when x3d nodes are considered page
>> DOM elements.
>>
>> Nevertheless, in the page above, both types of JavaScripts, 'regular' web
>> page and 'special' x3d, function correctly. The sphere is controlled by a
>> SAI script whereas all other actions are driven by HTML scripts.
>>
>> This is possible because a HTML script element with a type attribute
>> which is not recognized as an ecmascript related mime type is not executed
>> by the web browser. In the example I used application/x-vrmlscript which at
>> some point was the recommended mime type. But application/SAIscript would
>> also have the desired effect, for example.
>>
>> Cobweb, on the other hand, is not bothered by the type attribute and
>> proceeds to execute the script as a x3d script.
>>
>> This solution to allow dual use of the script tag would be understood by
>> web developers because the script tag with special type attributes is used
>> fairly widely to protect data content from being interpreted by the browser
>> in some way.
>>
>> While this is practical today, what would be required in the standard to
>> allow such a type attribute in the XML encoding of the x3d script node?
>> Since this type attribute would not represent a field, perhaps only the XML
>> encoding standard would be affected?
>>
>> Andreas
>>
>> --
>> Andreas Plesch
>> 39 Barbara Rd.
>> Waltham, MA 02453
>>
>
>
>
> --
> Andreas Plesch
> 39 Barbara Rd.
> Waltham, MA 02453
>



-- 
Andreas Plesch
39 Barbara Rd.
Waltham, MA 02453
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20160923/84b9bf1f/attachment-0001.html>