[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFC Implementation of SGML/XML Proposal for LSB in Debian



Ardo van Rangelrooij <ardo@debian.org> writes:

> Adam Di Carlo (adam@onshore.com) 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 Carlo....adam@onShore.com.....<URL:http://www.onShore.com/>



Reply to: