[ docbook-Feature Requests-729115 ] extend the notion of formal objects

[SourceForge.net <no...@so...>]

Feature Requests item #729115, was opened at 2003-04-28 15:13
Message generated for change (Comment added) made by stefan
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=373750&aid=729115&group_id=21935

Category: DocBook XSL
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Stefan Seefeld (stefan)
Assigned to: Nobody/Anonymous (nobody)
Summary: extend the notion of formal objects

Initial Comment:
It might be useful to be able to list (and reference)
other elements
than those hardcoded 'formal objects' (figures,
examples, etc.).
It would in particular be useful to be able to mark an
element as a
'formal object' as a user.

Consider to enhance the lot generation to be more
flexible, to take
other, specially marked up elements into account.

----------------------------------------------------------------------

>Comment By: Stefan Seefeld (stefan)
Date: 2004-10-24 20:14

Message:
Logged In: YES 
user_id=764

First I have to admit that I don't fully understand all the
relevant parts of the 
docbook content model. For example, I don't understand the
distinction between an index and a LOF.
I submitted a similar RFE concerning indexes, which
meanwhile got accepted.

Let me try to explain what I have in mind with an example:

For some while I have been pondering about a system to
assist the software development process (use cases /
requirements, design / architecture documents, API manuals,
...). There exist some proprietary
tools to guide the user in the management of requirements,
which are
document based, and let users track relationships between
requirements,
specifications, and other artifacts, across documents.
I believe that docbook could be used very efficiently to do
this, though
it needs some refinements (in fact, I'm hoping that with
docbook NG / 5,
i.e. the use of relaxng this will be easier).
I'd like to annotate nodes in the docbook document so I can
refer to them
formally as 'requirements'. As I don't want to impose how
requirements are
structured, I don't think there is an easy one-to-one
mapping between
existing docbook elements and my fictive 'requirement'.
From my understanding such a 'requirement' bears some
relationship
to formal objects, as that, too, seems to be some form of
metainfo / annotation. In short, what I have in mind is to
be able to make any docbook
entity 'formal' (well, some constraints may be applied), and
then push the
actual decision about concrete formal objects into
domain-specific 'profiles' (which Norm mentioned in
conjunction with his NG redesign).

Do you think that my understanding of formal objects is
correct ? Do you
believe that the above use case makes sense and can / should
be doable
with docbook ?


----------------------------------------------------------------------

Comment By: Michael Smith (xmldoc)
Date: 2004-10-23 10:51

Message:
Logged In: YES 
user_id=118135

What mechanism would you suggest for designating custom
formal objects?

Seems like you'd first need to choose a attribute (either
condition or role), use some consistent value for that attribute
(e.g., "My Formal Objects"), then tell the stylesheets (via some
new parameter) what attribute to check for.

But then what do you do if you want to generate multiple
customer
LOF-like lists?


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=373750&aid=729115&group_id=21935