Prior art via scripts?

Have I found proof of prior art for plugins?

PLUG-IN : A definition in HTML (for our purposes).

    A PLUG-IN is an application downloaded from a remote location. The
    location of the application is specified by explicit reference in the HTML
    source. The PLUG-IN application is executed by a user-agent which
    enables the PLUG-IN to interactively insert/display/modify 
    visual (or audible etc.) content.

Surely it does not matter whether the visual content is graphical or textual. Also, the format of the downloadable PLUG-IN is immaterial. So the PLUG-IN application could be in a humanly readable form (e.g a script) or otherwise(machine code/virtual machine binary format).

If you accept the above, then you must agree that a remote script referenced in an HTML document constitutes a PLUG-IN if that script can be executed by a user-agent which allows the script to interactively display content.

Here is a link to an HTML language definition and an extract from it :

http://www.w3.org/MarkUp/htmlplus_paper/htmlplus.dtd



...

I would like to acknowledge the influence of the TEI DTDs
     which proved very helpful in restructuring the DTD.

     Dave Raggett <dsr@hplb.hpl.hp.com> 5th April 1994  
...

<!--
The form contents are sent to the server upon pressing a submit
button. Forms can be associated with scripts, e.g. to make one
selection field effect which options are enabled for other fields.

Clicking on a selection or typing into a text field result in events
which are processed by the script. Event handlers are associated
with each field or with the form itself. The script language is
deliberately restricted to avoid any security issues.

Fields can be disabled (greyed out) or marked as being in error.
The MESSAGE element may be used by the server to set error messages.
Servers can store state information in forms with hidden input fields.
These are not displayed and can be used to hold transaction handles etc.
-->

<!ELEMENT FORM - - ((%main;)*, MESSAGE?) -(FORM) -- forms can't be nested -->
<!ATTLIST FORM
        id      ID      #IMPLIED
        action  %URL;   #IMPLIED -- defaults to URL for current doc --
        method  CDATA   #IMPLIED -- GET, PUT, POST, DELETE etc. --
        enctype CDATA   #IMPLIED -- encoding type for form transfers --
        script  %URL;   #IMPLIED -- locally executed event handlers --
        charset CDATA   #IMPLIED -- eg "ISO-2022-JP" for japanese -->

...


Correct me if I'm wrong, but the above DTD indicates that a script from a remote location can be executed on the client-side by the user-agent. The script is interactive via event handlers.

If you can find a user-agent that adheres to the above language specification and the scripts that it executes can alter/insert visual content, then you have a plug-in. Voila!

Of course, the date in which the 'script' attrubute has been added to the HTML language defn. would have to be verified. Although plugins, embedded objects or what ever you prefer to call them aren't usually thought of in this way, there is no reason why a script can't be a plugin.

It would be more difficult to find prior art for a user-agent downloadable application extension which itself processes an embedded object. Though you could argue that 'type' information for the embedded script is determined in the script URL (e.g file extension).

Andy Arme

andy@arme.co.uk