Am Mit, 2003-08-27 um 11.33 schrieb Sven Neumann:

> Any help page could then refer to the freetype plug-in by using

>   <link xmlns:ft=""; ft:href="top" />

> As you can see, the namespace prefix is irrelevant, we can choose
> "ft:" here to keep the notation short. Of course if multiple links to
> the freetype plug-in are needed, the namespace can be declard in the
> top-level element and the link would simply become

>   <link ft:href="top" />

> I am not sure how much work is needed to teach the help-browser about
> a new link type and XML namespaces but I think it might be worth the
> effort. This architecture should allow us to do some nifty stuff and
> it will assure that no conflicts will ever arise from help registered
> by third-party plug-ins.

You possibly also though about how to generate these? It's not just
about introducing a new tag to XHTML but somehow you also need to
express these in the DocBook source.

At the moment I don't see how this could even remotely work as there's
simply no way to express relative links which are not resolved at latest
at transformation time. There is a way to arbitrarily map references
using an external map (which can be autogenerated from DocBook source
and I'm actually abusing to generate the mapping for the helpbrowser)
however this means:
a) the documentation has to be in DocBook (or a new mapper has to be
   made somehow which could be tricky at least for say HTML directly)
b) all referenced documentation has to be know when the docs are
   transformed which is impossible for obvious reasons.

> My proposal would also allow to split the help between the GIMP core
> and the plug-ins we ship with GIMP. Just as we do for i18n now, where
> there are translation domains for the core, the plug-ins and
> script-fu, there could be help domains for the core, the standard
> plug-ins and individual domains for Script-Fu, Python and Perl
> scripts.

Nice idea but tricky to impossible to get right. This map to anything
proposal will *only* work if you have some means to do the
transformation online (which I'm not opposed to but you are) *or*
someone has to teach the helpbrowser about those mappings *and* special
crappery has to be installed to not make the XSLT processor barf and
produce the "right" results.

I'm absolutely against the idea of generating invalid XHTML (read: I
will not do this). If this is the way to go it has to be representable
in valid XHTML.


Attachment: signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Reply via email to