<section> vs <sect1>, ... [was: Re: usb-keys]

[Karsten Wade]

On Sat, 2004-08-14 at 12:07, Dave Pawson wrote:
> On Fri, 2004-08-13 at 21:25, Karsten Wade wrote:
> 
> > It is probably and properly lost in the annals of Red Hat documentation
> > history as to exactly why this format decision came about ... and as for
> > sed being your friend, I can tell you it gets harder when you have a
> > really big doc that has lots of <xref> tags throughout with hard-coded
> > LINKEND to IDs full of s1-, s2-, s3- and so forth.
> 
> XSLT will resolve all of them, forward and reverse if needed.
> 
> The source of the problem as I see it is the dual use of id attributes.
> Just because the stylesheets have an option of using sect1 id values
> as file names, it doesn't mean we have to.

I think the reasoning behind it is that when you are reading/editing a
very large guide with many sections, it's easy in the HTML to tell what
<section> you are in by referencing the HTML file name that came from
the ID tag.  I think this was more daunting to resolve using DSSSL, so a
process work around was configured inside Red Hat.  Since it is not so
daunting, perhaps we should just eliminate the process and customize our
XSL.  Lot easier to maintain than getting dozens of writers to make
accurate ID tags. :)

> id values should simply be document unique points used for cross
> reference. No more. As the schema says, they are optional. 

It is nice for xref.  We could have ID tags for only sections that you
wanted to xref?  Again, the ID needs to be only meaningful enough for
the author to figure out what it is, since, as you say, we can have XSL
give meaningful file names separately from the ID tag.

So ... where will the XSL get the information from for making meaningful
file names on the opposite side?  From the <title>?

- Karsten
-- 
Karsten Wade, RHCE, Tech Writer
a lemon is just a melon in disguise
http://people.redhat.com/kwade/
gpg fingerprint: 2680 DBFD D968 3141 0115  5F1B D992 0E06 AD0E 0C41