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;}
  <browser name="netscape" version="4.7">
  .class1 {font: helvetica; color: magenta}
  .class2 {position: none}
    <browser name="netscape" version="4.5"}
      .class1 {font: times-roman}
    </browser>
  </browser>
</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.

The CSSXML file would get translated to a .css file combined with javascript.
css files are processed on the client side. It will therefore be interspersed
with if statements after browser detection, and a correct css file constructed
on the fly. This reconstruction would occur for every file readin by the browser.

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? >>

The CSSXML file will be divided into fragments, that can be accessed by individual 
page fragments. This is done to allow multiple page fragments (e.g. menus or text)
to access the same cssfragment. Conversely, a page fragment can refer to 
multiple class fragments.  Note that a css fragment is a collection of css statements.
For example: 

<fragment name="fred">
.class1 {font: arial; ...}
.class2 {...}
#id1 {...}
  <browser name="netscape" version="4.3" OS="macintosh">
     .class1 {font: time-roman}
      <browser version="4.7">
         .class1 {color: magenta;}
      </browser>
  </browser>
</fragment>

<fragment name="gordon">
...
  <browser ...>
  </browser>
  <browser ...>
  </browser>
</fragment>
...

*********************************************************************
QUESION: when constructing website, what is the .css file actually 
sent with a page?  It should be the collection of all css fragments
associated with that page, with duplications removed perhaps. So, 
each page will have its .css file constructed, and there may be
a lot of duplication (although generated in batch mode). This decreases
effectiveness of caching, or increases the amount of cache used by 
the client since a css file is downloaded with each page.  Is this
reasonable?
************************************************************************

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

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: 

<fragment
   xsl="file.xsl" 
   xml="file.xml" 
   type="objtype"
   id="objid"               (perhaps not required)
   name="objname">
     <css name="name1"/>
     <css name="name2"/>
<fragment/>

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>
  <fragment xsl=".." xml=".." css=".." type=".." id=".." name=".." role="..">
      <css name="name1"/>
      <css name="name2"/>
  <fragment xsl=".." xml=".." css=".." type=".." id=".." name=".." role="..">
      <css name="default"/>
  <fragment xsl=".." xml=".." css=".." type=".." id=".." name=".." role="..">
</page>

If present, the css attribute to <fragment> will refer to a default location from which 
definitions should be taken.  The <css> element refers to one or more css style fragments
to be applied to the particular <fragment>. 

A "default" css fragment will be reserved for use by the files.

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 inconsistent
  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>
     <css/> ... <css/>
  <directory>
     <css/> ... <css/>
     <page>
     </page>
         <css/> ... <css/>
       ...
     <page>
     </page>
  </directory>
      ...
  <directory>
  </directory>
</website>

ATTRIBUTES

<website>
   name   (name of web site, mandatory)
   template (default template file for site, mandatory)
   css  (file, mandatory)
   xsl  (file, mandatory)

<directory>
   name (directory name, relative path, mandatory)
   template        (??? what is a directory template?)
   css  (file, optional)
   xsl  (file, optional)
   css  (???)

<page>
   name    (desired page name, mandatory)
   template   (name of xml file with placeholders that map with 
                the role attribute of fragments)
   css  (file, optional)
   xsl  (???)
   type   (???)
   id     (perhaps not required?)

<fragment>  (inside <page>)
  <fragment xsl=".." xml=".." css=".." type=".." id=".." name=".." role="..">
  name  (fragment name, mandatory)
  xml    (file path name, mandatory)
  xsl    (file path, mandatory)
  css    (???)
  type   (text, audio, video, ...: mandatory)
  id     (???)
  role   (used to place inside a page template, optional)


<fragment>  (inside a CSSXML file)
   ...
   <browser> 
      ...
      <browser> ... </browser>
   </browser>
</fragment>

<fragment>
   name   (name of css fragment)
</fragment>

<browser>
   name   (browser name)
   version (browser version)
   OS     (operating system)
   device (device type: handheld, desktop, phone)
</browser>

----------------------------------------------------------------------
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

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