> So that, documents were identified as belonging to a particular project
> (XUL for instance) and might also belong to other projects or other layers
> of that project, (UI, Specifications, Guidelines, Tutorials, etc).
Fine, but what has it to do with HTML coding guidelines to produce a
consistent layout?
> If HTML strict imposed rules on <Hn> then that might be true, but even then
> it would be true relative only to other headers within the same
> document.
Not if we have site-wide guidelines.
> To illustrate what I mean, imagine a document regarding plugins and the
> browser. Its overall project is the Browser (whether SeaMonkey is
> appropriate or not is irrelevant), it happens to be and end user document
> and it contains examples and links to another document on 4.x plugins as
> well as a reference to the plugin SDK.
>
> Using HTML the document, other than within the content or its place within
> a file system has no structured way of defining the project it belongs to,
> that it is an end user document and that it contains examples.
Yes it does, if we use a document management system - you will be able to
attach metadata to a document.
With your XML dialect, you are attempting to re-solve a well-understood
problem in website management. We should use an already-produced solution
rather than rolling our own. This would be an order of magnitude less work
than defining everything from the ground up, as you suggest, writing all
the tools, and then (and this is the really impossible bit) getting people
to use them.
We will have enough trouble getting document authors to use Mozilla
Composer rather than Netscape Composer without them having to learn a
whole new XML dialect.
Gerv
