Re: DOCBOOK-APPS: comments on "Using the DocBook XSL Stylesheets"

[Adam DiCarlo <adam@onshored.com>]

Daniel Veillard <veillard@redhat.com> writes:

> On Sun, Dec 15, 2002 at 05:09:27PM -0600, Adam DiCarlo wrote:
> > Sidenote: I really don't see what the big deal is though with mixing
> > XML and SGML stuff in /usr/share/sgml -- most of the tools I happen to
> > use work perfectly with both, and I haven't seen any big problems with
> 
>   If you give an SGML entity declaration to an XML parser in most case
> the syntax is not XML and the parser has to stop with a fatal error.

This is just a question of matching each file with the right SGML
concrete reference declaration.

> I have seen big problems. If your tool works perfectly with both it
> probably mean they are SGML tools or not compliants.

No. It's is because I always get it right. :) If you tried to load the
SGML ISO entities from and XML doc, that means you're using the wrong
public identifier.

How is this problem any more likely or less likely given the rather
irrelevant local issue of whether the files are shared under a common
dir or not?

> The formers will have a hard time with xml:base, xinclude, an in
> general any stuff added to XML which wasn't present in SGML.

Well, I haven't checked, but hopefully these tools are sophisticated
enough to use some sort of entity resolution (XML catalogs or SGML
open catalogs).  I know that the XML spec does not require entity
resolution, but personally I can't conceive of any robust document
instancing system that doesn't give you any indirection between public
identifiers for well-known shared objects and where they are on the
filesystem.

Assuming you have the entity registration and resolution working on
the infrastructural side, again, where the files are stored on the
filesystem is a non-issue, and merely a question of what works for
most sysadmins.  And I have a hard time really deciding between
whether /usr/share/xml is really a win for sysadmins or not.

-- 
...Adam Di Carlo..<adam@onshore-devel.com>...<URL:http://www.onshored.com/>