Re: LSB SGML/XML appendix: finding the DTD
Norman Walsh <ndw@nwalsh.com> writes:
> / Eric Bischoff <e.bischoff@noos.fr> was heard to say:
> [...]
> | mechanisms. And it would also mean that Norm and OASIS specialized
> | committees efforts on XML catalogues were useless. I'm not sure they
> | would appreciate. So far I've always attempted that the LSB
> | appendix on SGML and XML is only a more specific subset of what
> | OASIS committees had decided.
I'm aware that my proposal is political incorrect, absolutely :))
> |
> | Norm? Help !!! ;-)
>
> Uhm, ok. :-)
>
> I really think using the URLs as part of the filename is a grotesque
> hack. But I don't dispute that it would achieve a useful goal.
I agree, this is less elegant that catalogs.
> You're basically using the filesystem as a sort of odd catalog.
Exactly.
> Entity resolvers, such as the catalog based ones that OASIS is working
> on, have features and benefits beyond the simple redirection of DTDs.
I realize that catalogs is sofisticated solution.
And, still, I'll be "politically incorrect" - forgive me, please -
do we really need sofisticated solutions to do 99% of the common tasks?
> 1. They work across all platforms. The LSB and Linux distributions may
> not particularly care about Windows or the Mac, but users do and
> stylesheet authors do, and implementors of tools often do.
For Win and Mac some quoting scheme for filenames should be sufficient.
And this is implementors job only, not authors.
> 2. They're much more flexible than what you're proposing. It's possible,
> for example, to test Version X+1 of a DTD by creating a special catalog
> that points the Version X public (or system) identifiers to Version X+1
> and running all your existing documents through it.
>
> In a multi-user environment, you can't go f*cking with the symlinks to
> achieve this because you'll break everyone else's environment while
> you're testing.
>
> 3. Users can update them without being able to write to protected parts
> of the filesystem.
ad 2,3 : I'm perfectly aware of these issues. I did not mention
about it to not complicate the discussion, but it is obvious that some
support for per-user ~/.xmlcache, that takes precedence over
system-wide files, is also necessary.
Being a power-user and having proper files in that dir, one could do
the same as can be done wiyh catalogs in you example (with cp command
instead of editing catalog, that's the difference). I realize that
given example is simple and you could easily think some other for
which xmlcache is too limited and catalogs are ok.
Nevetheless, "\C-r 99%" ;)
> 4. They work for both URIs and external identifiers. For example, I'm
> going to be sorely tempted to change
>
> <xsl:import href="/sourceforge/docbook/xsl/html/docbook.xsl"/>
>
> to
>
> <xsl:import href="urn:publicid:something:I:construct"/>
>
> once the urn:publicid namespace is accepted and the catalog mechanism
> is widely deployed. (Speaking of the urn:publicid namespace, the most
> recent draft[1] outlines our plan for getting public identifiers
> properly into the web architecture.)
Using proper quoting, xmlcache could map _any_ string to path.
> 5. Catalogs have the backing of a standards body. They work for both SGML
> and XML. And they will be supported by commercial tools (XMetaL and Epic,
> at least, presumably).
>
> You've got to get implementors to change things to support either
> catalogs or your filesystem hacks. I think you're likely to get a lot
> more support for the former than the latter. And the latter is an ugly
> hack. IMHO, of course.
Both solutions could co-egzists in peace if maintainer of the program
is interested to implement them both and add a switch (either
compile-time or run-time) :)
I still agree this looks ugly. But can be just "what most people need"(TM) :)
Hope to hear your opinion
Best Regards,
Rafal
--
Rafał Kleger-Rudomin (klakier@pld.org.pl)
Reply to: