Re: Playing with the spec

[Jorge Godoy <godoy@conectiva.com.br>]

On Mon, Mar 06, 2000 at 03:20:04PM -0600, Manoj Srivastava wrote:
> 
>  Jorge> This specification is being suggested to easy the maintenance
>  Jorge> and integration with other tools.
> 
>         As an end user fo the specification, I do not find the
>  directory structure actually easing my task (I am involved in
>  determining policy for one of the Linux distributions). 

Please, tell us what could easy things to you. As I said, we are
accepting comments and suggestions on the layout we've proposed. 

>  Jorge> The suggested directories were using version numbers to
>  Jorge> minimize the interference with original's filenames. We don't
>  Jorge> want to patch already written catalogs so that they can look
>  Jorge> at our directory and be correct.
> 
>         But this makes it harder for folks who already have local
>  policies, and already massage the packages to fit into that local
>  policy.

But then, how would you deal with the problem of multiple DTDs? Let me
say that I have documents based on DocBook DTD 2.4, DocBook DTD 3.0
and DocBook DTD 3.1. Filenames are the same (http://www.nwalsh.com has
a link to these). How would you separate them? If we replace the
files and keep only DocBook DTD 3.1 then documents marked up with 2.4
would be broken. 

>  Jorge> No using version numbers and placing all the files on the same
>  Jorge> directory would be intrusive with new packages and with
>  Jorge> already written ones. We'd have to, e.g., change all existing
>  Jorge> docbook catalogs from the DTDs and stylesheets.
> 
>         I'd have to put that in perpective. It is possible that some
>  catalog files for some packages would have to be changed anyway --
>  there is no way the standard can accomodate all the DTD packages,
>  past, present, and future (and not all package authors are going to
>  automatically conform to this standard, espescially if we over
>  specify requirements).

Please, analise this with the information about multiple versions of
DTDs I've talked above. It would make things harder too keep. 

>  Jorge> It's  common to find catalogs using relative paths. It's not specified
>  Jorge> their root directory, but they use directories within where they are
>  Jorge> or in some relative way that is common to have them installed. We'd
>  Jorge> have to patch these too. 
> 
>         How hard is it to actually change the catalogs? I can supply a
>  simple little perl script that can easily handle the change. 

It's not hard at all. But, the minimal changes we have to do, the
better. Please, let me take a look on such script. 

Changes: you've changed filenames and directories. The informations
about these changes is in the difference between files from the
original package and files with new names and locations (you can
either parse the package building specs --- there will be trouble if
you do this --- or the contents of the files). 

>  Jorge> Using version numbers to each DTD or stylesheet that we use is not too
>  Jorge> hard to maintain and we can benefit from the already made catalogs
>  Jorge> with little or none changes on it.
> 
>         And if docbook is all you are looking for, perhaps that is
>  reasonable. But from the perpective of a distribution developer, this
>  would mean a rapidly burgeoning dir structure that is not
>  reasonable. 

Please, make a suggestion on what could be changed.

>  Jorge> That was my main intention when I've suggested using version numbers. 
> 
>         For the docbook people, this sounds reasonable. On a broader
>  SGML/XML perpective, this is not.
> 
>         And if a few preinstalled vatalogfiles are all that we have to
>  care about, I don't find this argument compelling at all.

This catalog is created on the fly. It's based on OpenCatalog
specs. When you install a new package, it calls certain scripts and
passes the position of it's catalog and it's version number. Then, a
reference to it is added to the main catalog. 
You'll have to know where to look for this catalog anyway.

--
Godoy.	<godoy@conectiva.com.br> 

Setor de Publicações
Publishing Department                   Conectiva S.A.