Ardo van Rangelrooij <[EMAIL PROTECTED]> writes: > Adam Di Carlo ([EMAIL PROTECTED]) wrote: > > It's a bit debatable how much symlink madness is required. I mean, > > for SGML stuff, people are going to be using FPIs almost exclusively. > > For instance, lets take sgml-data. Do I really have to make symlinks > > fro /usr/lib/sgml/dtd/html-1.dtd to /usr/share/sgml/html-1/ ?
> > I find that it's generally only XML stuff where the document authors > > need to accomodate (hypothetical) tools which don't understand SGML > > Open Catalog formats. Thus /usr/lib/sgml/dtd/xhtml-1.0 should > > probably be symlinked to /usr/share/sgml/xhtml-1.0. Ardo, anyone, no comment on this? > > Regarding the setup of the new structure, I wouldn't mind a bit of > > clarification regarding the structure of the HTML materials. Should I > > really make, under /usr/share/sgml: > > > > html-4.01 > > html-4.0 > > html-3.2-style > > html-3.2 > > html-3.0 > > html-2.0 > > mozilla-2.0 > > msie-3.0 > > msie-2.0 > > hotjava > > This is where the proposal of Mark Johnson would fit in nicely. You can use > > /usr/share/sgml/html/dtd > declarations URL please? > and put all the HTML materials in there. I agree it's an overkill to separate > all this out into separate directories. I suggest we use this approach. If > it really does not make it into the standard we can always rethink this. > Having > a standard and following it is a good thing, but let's be practical. Well, I could have a html-legacy directory for the < 4 stuff. > > Are we dropping the fallback derivation of the file name as found in > > section 2 of /usr/doc/sgml-base/sgml_layout.txt.gz ? > > The proposed standard doesn't say anything about this (in fact, it only talks > about the contents of the centralized catalogs and the super catalog). I > don't > see any reason yet we should drop this feature. It's not in contradiction > with > the standard. We can always drop it later if it becomes forbidden. I've always thought 'install-catalog' on Debian at least should handle this. There's really no reason why package maintainers need to be burdened. Maybe I should file a wishlist bug on sgml-base for this? > > I'm a little confused -- after this is in place, at what point is it > > safe for SP and OpenSP to stop looking in /etc/sgml.catalog and start > > looking in /etc/sgml/catalog ? > > > > I think it might make more sense for the first transition of sgml-base > > to carte-blanche migrate all the materials from /etc/sgml.catalog into > > /etc/sgml/catalog (possibly delegated to /etc/sgml/transitional.cat). > > As new packages provide catalogs, the legacy materials are removed > > from /etc/sgml/transitional.cat and provided in /etc/sgml/<file> to > > which a delegated reference is made in /etc/sgml/catalog etc as per > > the spec. > > > > Moreover, sgml-base would remove /etc/sgml.catalog and make that a > > symlink to /etc/sgml/catalog. SP and OpenSP, for instance, could be > > trained to use /etc/sgml/catalog at any point after that, using a > > versioned depends on sgml-base. > > Excellent idea! Using catalogs for the transition makes it all a lot > easier and simpler (if I understand your proposal correctly). After > the catalogs are in place and SP and OpenSP have been updated, the > other packages only have to move their stuff from /usr/lib to the > new place, update their catalogs and symlink back to /usr/lib > what's needed there until the other tools have been updated (or > am I seeing this to simplistic too). No, I think you're right. Once we've reached the point in transition where we are actively deprecating /usr/lib/ then we (a) pull /usr/lib/sgml out of the SGML_SEARCH_PATH for all SMGL/XML tools, and (b) file bugs on things that break (we're talking woody+1 here obviously). > I'm wondering which tools > look under /usr/lib/sgml, besides SP and OpenSP. Is there an > easy way to find this out? Based on 'apt-cache showpkg sgml-base' to see reverse depends on sgml-base, I see, then trimming out for just processors, I have this provisional list: openjade sgml-tools-2 sp,sgml-base opensp jade sgml-tools psgml perlsgml linuxdoc-tools This list is even probably too big. Some of these packages don't have entity managers but rather rely on other packages that do. > I expect to have something ready before the end of the week: Excellent. > - the catalog setup you described > - a new tool called `install-catalog` to manage the centralized > catalogs and the super catalog (I think it's better to keep > `install-sgmlcatalog` as it is, besides updating it for the > transition catalog) Sounds like extra work -- couldn't you just symlink the two tools together? Well, its your time :) -- .....Adam Di [EMAIL PROTECTED]<URL:http://www.onShore.com/>
