From davep at dpawson.co.uk Thu Jun 4 22:05:41 2015 Content-Type: multipart/mixed; boundary="===============1657822749123280036==" MIME-Version: 1.0 From: Dave Pawson To: docs at lists.fedoraproject.org Subject: Re:
vs , ... [was: Re: usb-keys] Date: Mon, 16 Aug 2004 18:43:56 +0100 Message-ID: <1092678236.2674.43.camel@homer> In-Reply-To: 1092590939.3459.4473.camel@erato.phig.org --===============1657822749123280036== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Sun, 2004-08-15 at 18:28, Karsten Wade wrote: > 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 >
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. :) I'll leave that to Tammy. > = > > 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. = Essential for cross referencing. > We could have ID tags for only sections that you > wanted to xref? That was the intent of the id attribute in XML, i.e. only add it on those elements which are targets. > 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. Not even meaningful, just unique to the instance? The standard XSLT stylesheets have a configuration (split output) option to use id values as filenames. But that only applies at ... Tammy? is it sect1 elements? For any other id values, its arbitrary. > = > So ... where will the XSL get the information from for making meaningful > file names on the opposite side? From the ? Dangerous. The title content, as well as having spaces, could have all sorts of Unicode in it. That would make for bad filenames. Depends on what is currently in use. http://www.sagehill.net/docbookxsl/Chunking.html#ChunkFilenames shows the options for xslt processing. Take your pick. I'd personally let the processor pick the filenames, but I don't attach much importance to them. YMMV :-) -- = Regards DaveP. XSLT&Docbook FAQ http://www.dpawson.co.uk/xsl --===============1657822749123280036==--