Hi Thomas,
I think a better possibility is to map topic/@type to
section/@otherclass (and setting @class="other") during assembly. In
DocBook 5.2, the @class attribute is added to section to support legal
sections. The @class attribute already exists on the article element,
so that would work if you map your topics to articles instead of
sections. The topic element does not have an @class attribute, so there
is no conflict there.
I see @type and @class as semantically equivalent for classifying
elements. They differ from @role, which I interpret as applying to a
specific instance of an element. So an instance of an element can be a
member of a class but also carry a specific role for the given output.
The @class and @otherclass mechanism that is used several times in the
DocBook schema is a bit awkward, but it is designed to support
enumeration of @class, especially through customization of the schema.
That enforcement of enumeration during authoring is important in some
use cases. Other use cases that don't require such enforcement can use
@otherclass in a looser classification scheme.
Bob Stayton
b...@sagehill.net
On 8/5/2021 5:00 AM, Thomas Schraitle wrote:
Hi,
currently, I'm playing around with DocBook assemblies. I've created an
assembly file, referenced some modules and a structure. The modules and
structure is not really important, but the module. The structure
declares to render the <topic> into a <section>.
The module contains a <topic> element, but I also used a type attribute.
As the TDG says, it "identifies the topic type" I use it to distinguish
between a concept, task, or any other types. IMHO, that's a good fit, right?
When I start the assembly process with the assembly.xsl stylesheet, the
realized document renders the <topic> element into a <section>. So far,
so good.
However, as the <topic> contained a type attribute, this attribute is
passed onto the <section> as well. Unfortunately, type is not allowed on
a <section>, so the validation fails.
I have some possible scenarios:
a) deal with the removal of type inside the assembly file?
Would <transforms> be feasible for this task? Or should
that be better done outside?
b) use a post-processing (XSLT) step and remove the annoying
attribute manually?
c) allow type in <section>?
would require to amend the DocBook schema.
d) customize assembly.xsl and remove type?
e) anything else?
What would you choose?
Would like to hear your opinion. Thank you!
--
Gruß/Regards
Thomas Schraitle
---------------------------------------------------------------------
To unsubscribe, e-mail: docbook-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: docbook-h...@lists.oasis-open.org
