At 15:55 09/01/2001 +0000, Gervase Markham wrote:
> > 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?
Absolutely nothing I have very little interest in layout, but considerable
interest in content. I've said before to conflate the submission of
content with the delivery of content is wrong, the two are separate.
>
> > 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.
Err, that just isn't true. How does using <H1> get enforced? The tag <H3>,
for example, couldn't mean the level of a document, end-user, developer,
distributor because there's no further modifier all it can show is relative
structure within one document. Would it make sense to abstract all content
between <h3> tags from all documents? That's the kind of horizontal
structuring I'm talking about.
> > 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.
You mean metadata outside the body of the document? That is better than
nothing but it itsn't as useful as marking up the content logically. Where
is the metadata to come from? It seems a basic mistake to separate the
content from the logical structure especially when its easier not to.
>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.
No, the XML dialect is an example of an implementation and exactly the kind
of implementation that XML was designed for, DocBook is another, HTML is
not a solution to this problem because its devoid of structural
tags. There's only one tool that's needed and that is a small refashioning
of an existing parser and in the case of DocBook even that isn't
required. Nobody need use any additional tools to contribute
documents. As far as maintenance of already marked up documents is
concerned, editing the content and so on, the text remains sufficiently
transparent for the original author to edit whilst ignoring the markup.
>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.
They don't have to, I've already said that, they may learn and use it if
they wish but there's no need to compel them. Relatively few people need
to be involved in marking up documents whether it uses a novel XML variant
or DocBook.
Simon
>Gerv
===============================================
The more exotic the Project name the more ordinary the Product
S.P.L.
