On Wed, Aug 29, 2001 at 01:17:53PM -0400, Mark Johnson wrote:
> It sounds to me like the plan is to have, say, the xsl stylesheets at
> a persistent URL:
>
> http://docbook.sourceforge.net/release/xsl/{$VERSION}/...
>
> And since Norm also keeps the current version at
>
> http://docbook.sourceforge.net/release/xsl/current/...
>
> the latter would work fine for debian as the URI to map to the local
> installation via the 'rewriteSystem' element (debian doesn't put
> version numbers [yet, anyway] in the stylesheet directory trees.)
>
> Am I on the right track here in interpreting the thread??
Seems we are speaking about the same thing, yes :-)
> I'm not sure I understand Daniel's point about catalog/directory
> structure templates, though. If he means that
> (1) we all agree on the same relative sub-directory structure, and
> (2) that the agreed upon structure mirrors that of the
> upstream distribution,
>
> then I wholeheartedly agree. Point (2) is actually part of our
> proposed policy for debian. On the other hand, based on the lsb-sgml
> spec discussions, it seems very unlikely that the various
> distributions can agree on a common sub-directory structure.
Well they don't have to. the point of XML Catalog is that they
are really flexible. But it would be a good idea to try to keep
the same tree structure at least for DocBook for the moment because
that's the most proeminent one for our documentations system and I
would hate to have to explain that on Debian things are located in
one place, in another place on SuSE and a third one on RedHat. I don't
like much answering to this kind of user support....
However, the good thing is that even if this happen people should
be able to author and process the documents in an identical way as
long as they keep their system identifier to be the standard ones.
(I will personally shoot any Gnome documentation found with file:///
for the DOCTYPE or the stylesheet PI once the framework is in place
- in the meantime I just make noise).
> Maybe this one will have to be decided via the 'effective practice'
> model, where the least problematic solution is the one most widely
> adopted. I dunno.
>
> BTW, this discussion is very timely for me, as I'm in the process of
> packaging Norm/Sun's resolver classes. I also have to think hard about
> an XML Catalog system/structure to propose to the debian folks. The
> catalog structure in the current (stalled) draft of the SGML LSB spec
Well I made some noise in June to not have the SGML proposal shipped as
is in the LSB, and it seems the use of an Addendum is now accepted by
most parties, this need to be (re)written of course...
> has some problems that I'd rather not propagate. (Sounds like Daniel
> is going through the same process in implementing his libxml
> stuff. Daniel: BTW, do you ever come to RedHat Central in North
> Carolina? I'm 10 minutes away from the place... It'd sure be nice to
> get some face time on this stuff.)
/me is in France, I was in Raleigh in July but don't expect to
go there soon.
> Finally, I, too, have experienced funniness in http connections to
> sourceforge AND to oasis. But that won't really be an issue if users
> have local installations of this stuff and use catalogs. Isn't that
> the whole point of having catalogs, anyway? The cache mechanism
Well that's a large part of it. But not the whole point :-)
> I may be able to offer to have Duke host something like a
> docbook-everything-release mirror, as they're big on establishing an
> edu presence on the XML scene. Since they've enthusiastically agreed
> to become the new home of the local TriXML site & meetings, and I'm
> about to propose that they make a stronger committment to support the
> LSB-sgml-xml spec work, I could also request that we host a mirror of
> the various docbook-related releases. (Heck, I own the
> docbookstuff.org domain anyway...)
Well, the point is not to get N URIs but a single one as identifier,
the decision for this one is I think in the hand of the DocBook Commitee,
or Norm. Once said mirrors are alway a good things ... And fixing
the LSB-sgml-xml would definitely benefit from some sponsoring (web site
phone bridge for calls, etc...).
> Feedback, please.
Sure :-)
I think :
- that we are getting slightly off-topic for this list
(apologies for the non-Linux users out there though they
certainly have similar issues, Sun should probably look
at it considering the Gnome setup will affect them).
- that we should resurrect the LSB work on those issues
- that I would feel more comfortable when this got tested a bit
more (If you could get some testing on the Debian side for
the catalog hierarchy I suggested well this wouldmake me feel
more confident in pushing such a solution).
Virtual cookie to whoever restart the discussion on the LSB list ...
Daniel
--
Daniel Veillard | Red Hat Network http://redhat.com/products/network/
[EMAIL PROTECTED] | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>