> So, make sure that you are being appropriately generic when it's > required, to avoid unnecessary maintenance later. Using the application > (menu) name instead of the command (CLI) name is helpful. Does this > make things clear as mud, then? Well, to clarify, here's what's giving me trouble at the moment. How would the following be marked up? Restart the smb service: service smb restart I'd like to standardize on referring to services by the names of their init scripts in contexts like this in order to avoid having to refer to httpd as "The Apache HTTP Server", which is technically the correct name for it. Obviously "service smb restart" is a <command>, but what about that initial "smb"? Technically it's neither a <command> nor and <application> because by its self it is neither a GUI nor a CLI app. Then again, neither is "Text Editor", though the convention if not the docbook spec seems to accept using it within <application>... but "smb" is, if anything, CLI so... you see how this gets complicated. A similar problem arises when dealing with "system-config-network". This is both a CLI <command> and the proper name of the app that gets run when <application>Internet Configuration Wizard</application> (or whatever it is from the menus) is selected. I'm becoming convinced that <application> and <command> as currently defined are just inadequate for a number of scenarios, all of which could be dealt with by treating <application> as the proper name of an application/service/command and <command> as something one might run from the CLI. I don't expect the docbook standard to be revamped on my account, but can anyone offer a better way of addressing these problems without breaking convention? --Brad
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-docs-list@xxxxxxxxxx To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-docs-list
