The capability of using a web browser as a graphical frontend to OOBD opens a endless field of possibilies of how the interface can look like and how it acts. To not having all these different ways interfearing which each other, these rules should be followed.

To be prepared for later extensions, the following folder structure shall be taken as given as base for own developments. This structure is not hard coded as such, it will be mapped by the webserver to it's real physical location.

+(webroot)
|   +---lib
|   |   +---name
|   |       +---version
|   |           +--- the lib files
|   +---theme
|       +---name
|       |   +---version
|       |       +--- the theme files
|       +---(default/1)
+---yourapp
    +---MANIFEST
    +---secret
        +---yourcontent

OOBD web sites will be distributed as container files. To not generate overhead by packing the common content in each single container, the folders are packed separately

The todays webkits like jQuery, Dojo etc. consist of huge numbers of files. To not have them packed multiple time in each container, they are stored separately.

The name gives the name of the library, the version it's version, however the library provider is counting its version.

The lib content should be 1:1 to the original without any own modifications and tweaks

Modern HML designs allow a common look & feel, controlled by css, a common set of icons etc. By using themes you can easy design and maintaing a lot of app designs without updating them all individually.

The name gives the name of the theme, the version it's version, however the theme provider is counting its version.

The theme content should be 1:1 to the original without any own modifications and tweaks

The default/1 theme and version is a virtual folder. It's mapped by the webserver to the actual selected standard theme. So when using default/1 as theme, your app will look like the rest of OOBD.

in here you store everything, which is unique to your app, means not a common theme or a webkit library

Afer building it, your app container will need to contain at least some content which is public readable, like it's full name, description, Icon, descripted by the MANIFEST.

in the secret subfolder you can stored what you would like to have encrypted by the normal OOBD pgp encryption process

OOBD supplies tools to automatic translate diagnostic specifications into OOBD syntax. It would be quite anouing when these imports would have a fixed design and view. To avoid these, the process shall be as follows:

• the translation shall only transfer the data which is mandatory to supply the web elements. The output shall be pure xml, containing a xlst style sheet directive in it's header.
• the xslt style sheet shall just contain the logical layout and support logic (like some javascript magic), but no design elements. For the design, the xslt file shall reference to an theme instead. Using default/1 also here gives the common program look & feel.

to be defined

to be defined