forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Brondsema <>
Subject Re: [DEVOTE] Solving the skinconf riddle
Date Sat, 01 May 2004 15:26:02 GMT

On Wed, 28 Apr 2004, Nicola Ken Barozzi wrote:

> As a summary, the point of discussion is over validation or not, and how
> to do it.

And the format.

Extensability is a key concern and I think the two options that would
support it are

DTD (or relaxng) validated skinconf in a standard feature/element/property

Namespaced skinconf (only supported by relaxng, right?).

A make it easy for people to edit because it can be DTD validated and they
structure is simple and standard.  Skins can also easily declare which
features/elements/properties they support and what is required and not.
The only disadvantages that I see is that we don't have per-skin
namespaces to directly show that a certain feature is specific to a
certain skin.  And that everything has to fit into the
feature/element/property model.  Some skins might prefer a more flexible
configuration (e.g.  <footerlinks><link/>*</footerlinks> instead of
properties footerlink1 footerlink2 footerlink3 footerlink4 etc)

B This has the advantages that are disadvantages for A. Using namespaces
we directly associate features with certain skins, although then we have
an issue of when enough skins use the same feature, do we move it into the
forrest namespace?  Skins can be flexible outside the
feature/element/property model.  But only relaxng validation, and skin
declaration of configuration hints is probably more complicated.

I prefer A.  So in summary: consistent feature/element/property format
with DTD validation.

It was mentioned that we could validate against the skin feature
declarations too.  This would be good, but of course only possible within
forrest (not an editor).

Dave Brondsema : : personal : programming : student org

View raw message