Skip to content

start:

Introduction

This research builds on these earlier investigations into requirements for script storage in the Office Scripting Framework. The goals of this research are:

  • Understand and document the current Office XML format with regard to scripting
  • Suggest how the Office XML format would need to be changed to accommodate the new storage requirements of the Scripting Framework

Contents

Summary of earlier investigations

The scope of the initial investigations into scripting requirements was as follows:

"Scripts can be in many formats, source or binary, encrypted or obfuscated. They can be stored in many locations, eg. a filesystem or a webserver. They can be stored as files, or embedded within a file. They can be protected by security features such as digital signing.

Clients of the scripting framework (eg. StarOffice, IDEs) need to be able to access these scripts without concerning themselves with where and how the scripts are stored. The Application Scripting Framework needs to provide a set of services and interfaces which will allow these clients such access."

The analysis phase posed a number of questions and proposed tentative solutions to these. These solutions were then discussed in the dev@udk.openoffice.org mailing list in the thread "code storage, management and navigation for an office scripting framework" (April 2002). The results of these discussions are summarised below.

What should the default locations for script storage?

At the application level scripts should be stored under the Office installation directory in a "scripts" directory. Language specific directories would be created for each language supported, eg. for java: <install_dir>/share/scripts/java:<install_dir>/user/scripts/java Document scripts would be stored in a scripts directory within the documents zip file: <doc_root>/scripts/java

How do we locate scripts for display in the Binding UI?

A list of the scripts available to Office would be stored in a script registry. This registry is currently stored in the script.xlc file for application level scripts and script-lc.xml for scripts stored in documents. There is also an additional import feature which allows for adding new scripts into the registry. It was proposed that access to the script registry and for both search and import be provided via a storage API, which would allow clients other than Office (eg. an IDE) to also browse scripts in an Office installation.

What kind of metadata is associated with a script?

Our initial discussions indicated that there are two types of metadata associated with a script: deployment metadata (also called deployment descriptor) and administrative metadata. The deployment descriptor for a script is the information associated with the script which describes how to integrate it into an Office installation - where the script should be installed, what libraries it depends on etc. The information in the deployment descriptor is only needed while installing the script. The remaining metadata is used by the binding, naming and invocation mechanisms of the Scripting Framework. This will include information such as a description of what the script does, the dependencies which need to be loaded to run the script, version information for the script etc.

Contents

Solutions

The goal of these solutions is to explore how the Office XML file format used in the Office script registry could be modified to allow storage of scripts written in multiple languages and their associated metadata.

  • script
    • javale languages and their associated metadata.
      • script
        • java --> script.xlc
          • calendar --> script.xlb ? or maybe just calendar.xlb
          • Lib2 --> script.xlb ? or maybe just Lib2.xlb
          • bin --> *.class (calendar.class;lib2.class)
          • src --> *.java - All Java source File
          • res --> Resource files

So from this little hierarchy, you can see that the library Calendar could be a directory or directly a .xlb file. If the entry calendar is a directory then you would be able to have a script.xlb file detailed after and add an hierarchy (class and src) specific for that library but without the possibility of sharing any of those. Or you can have a shared class and src directory in which all the class and java files are and have all those shared between all the libraries. This would give the opportunity of just having a metadata file calendar.xlb. The problem for that solution is the clarity in the hierarchy...

First Solution

Common Class and Src directory

  • script
    • java --> script.xlc
      • calendar.xlb
      • Lib2.xlb
      • bin --> *.class (calendar.class;lib2.class)
      • src --> *.java - All Java source File
      • res --> Resource files

The script.xlc file would look like:

<library:libraries ...>
<library:library library:name="calendar" xlink:="calendar.xlb" .../>
<library:library library:name="Lib2" xlink:="lib2.xlb" .../>
</library:libraries>

The calendar.xlb file would look like:

<library:library library:name="calendar" ...>
<library:element library:name="config" ...>
<library:method library:name="SetProperty" engine="Java 1.2" library:languageName="com.sun.star.bean.Registry.Set" library:delivery="Registry"/>
</library:element>
</library:libraries>

Second Solution

One Class and Src directory per library
  • script
    • java --> script.xlc
      • calendar
        • script.xlb
        • class
        • src
      • Lib2
        • script.xlb
        • class
        • src
      • res --> Resource files

The script.xlc file would look like:

<library:libraries ...>
<library:library library:name="calendar" xlink:="calendar/script.xlb" .../>
<library:library library:name="Lib2" xlink:="lib2/script.xlb" .../>
</library:libraries>

The calendar/script.xlb file would look like:

<library:library library:name="calendar" ...>
<library:element library:name="config" ...>
<library:method library:name="SetProperty" engine="Java 1.2" library:languageName="com.sun.star.bean.Registry.Set" library:delivery="Registry"/>
</library:element>
</library:libraries>

Third Solution

We can combine both solutions.

Contents