Geoffrey,

Specification for the definition of a website based on xml, css, and 
xsl documents. We do not assume the use of Javascript or other 
client-side technologies.

This discussion only concerns websites, and is therefore not as general
as the collaborative portals you are concerned with.

We are concerned only with the generation of static pages.
----------------------------------------------------------------------
The user interacts with a website through a series of pages.
These pages can be viewed on a variety of devices (desktop PC, PDA, 
large screens, small screens, etc.) using a variety of browsers 
(Netscape, Opera, Explorer). 

----------------------------------------------------------------------

These pages take the form of data, stored in some type of database. The
web site is formed from collections of pages whose layouts are
similar. For exmple, home pages of faculty may have similar backgrounds and 
navigation menus, although the content may change.

----------------------------------------------------------------------

For the variety of devices we are targetting, we will construct the 
pages to be displayed (as html, wml, xml, etc.) and store them on 
a file system in a directory structure.  The XML element <directory> 
will be reserved for this purpose. 

----------------------------------------------------------------------

A page is constructed from objects. Objects might be menus, footnotes, 
title bars, navigation bars, text documents, etc.  There may be an 
infinite number of them. The items are reusable in the sense that they
may appear on any page. This is not unlike javabeans or active X 
controls. They will be defined in a browser-independent manner in 
an XML document, one per object.  

Each object has associated with it an XSLT and a CSS file. The XSLT file
allows the XML specification to be transformed to conform to the 
client device. The CSS file is responsible for the styling of the page.
Both these files are browser dependent.  XSL and CSS files may 
contain switch statements to accomodate multiple browsers, or may 
contain information for only a single browser.  An issue with CSS 
files is reusability.  Netscape 4.7 may have one CSS file, but 
Netwscape 4.5 may have to change a subset of a class definition.
One should not have to have multiple CSS files for this type of situation.
Therefore, we propose to store CSS information in a CSSXML file
with a structure similar to 

<general>
.class1 {font: arial; color: red; size: 12pt;}
.class2 {position: absolute; left: 200; top: 100;}

<Netscape 4.7>
.class1 {font: helvetica; color: magenta}
.class2 {position: none}
  <Netscape 4.5}
     .class1 {font: times-roman}
  <Netscape 4.5/}
</Netscape 4.7>

</general>


The innermost element defintions would overide the outer ones. Thus, 
the font in Netscape 4.5 would override that of Netscape 4.7, although
the color would remain magenta.
Similarly, Netscape 4.7 behavior overrides some of the .class2 values 
in <general>.  <general> defines the default template.

The CSSXML file would be processed by a perl/xsl or other file
with an argument that specifies the destination browser along with 
its version and the target operation system.  This scheme is quite
extensible.

At least one CSSXML file is associated with each object.

<< How to insure compatibility between the CSSXML file and the particular object?
Perhaps ignore attributes that don't apply? >>

----------------------------------------------------------------------

Once objects have been defined, they are used to form one or several pages.
A page is formed from a collection of objects.  A page might have a title, 
a navigation bar, a left menu bar, and a lower navigation bar (it could be
the same as the upper navigation bar). 

We propose to define a page as an XML file with the following structure: 

<object 
   xsl="file.xsl" 
   xml="file.xml" 
   css="file.cssxml" 
   type="objtype"   
   id="objid"
   name="objname"  
/>

The xml, type, and id attributes are required since they define the object.  
The id attribute must be unique among all objects in a given page. Therefore, 
their name will be computed from the specified value with the name of the 
file preprended (or some other unique identifier).

****************************************************************************
<<<< The xsl and css files may either be absent, or if present can be overwritten.
It is not clear how this will happen. What is the hierarchy to follow? >>>
****************************************************************************

Each page consists of an XML, CSSXML, and XSL file.  For example, 

index.xsl, index.xml, index.cssxml .

The index.xml file is thus: 

<page>
  <object xsl=".." xml=".." css=".." type=".." id=".." name="..">
  <object xsl=".." xml=".." css=".." type=".." id=".." name="..">
  <object xsl=".." xml=".." css=".." type=".." id=".." name="..">
  <object xsl=".." xml=".." css=".." type=".." id=".." name="..">
  <object xsl=".." xml=".." css=".." type=".." id=".." name="..">
</page>

The xsl and cssxml files do not necessarily have the same basename, but
they often will.

****************************************************************************
<< NEED DEFAULTING MECHANISM >>
<< SHOULD xsl and css always be considered in pairs >>
<< HOW TO PREVENT arbitrary tag naming in css files that are inconsistant
  with the rest of the files? >>
****************************************************************************

Given this structure, the entire website can be stored in a single
file under the assumption that the files are stored in a directory
hierarchy.  Here is the XML file for the website:

<website>
  <directory>
     <page>
     </page>
       ...
     <page>
     </page>
  </directory>
      ...
  <directory>
  </directory>
</website>

ATTRIBUTES

<website>
   name
   template
   css
   xsl

<directory>
   name
   template
   css
   xsl
   css

<page>
   name
   template
   css
   xsl
   type
   id


----------------------------------------------------------------------
Page layout is fully included inside the page.xml document.

There might be some advantage to putting the page object content inside
the <website> file, but that would make the file less clear.  Doing
it is just a matter of postprocessing.


****************************************************************************
ISSUES:

1. Where and how are the various objects stored?
2. How are defaults resolved.  For example,
     a. the xsl attribute is missing from an <object>
     b. the css attribute is missing from a  <directory>
3. Any attribute should be replaceable by a named argument. For example, 
   xsl="arg:main_xsl".  When the website is created, one simply 
   runs a script: 

      create_web_site arg:main_xsl=main.xsl ...

Alternatively, all the arguments can be stored in a file, e.g.
   website1.def, website2.def, ...  in the form

   arg:main_xsl=main.xsl
   arg:mx_xml=junk.xml
     ...

and the website creation is invoked as (for example)


   create_web_site < website1.def

   
****************************************************************************