OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Confirmation of Understanding: Exactly One Level of SpecializationIn A Given Vocabulary Module

In my DITA for Publishers map domain I have pairs of topicref types, one for
referencing topics of a given type and one for referencing maps of the same
type, e.g,. part and part-mapref.

I had implemented numbering of parts in EPUBs based on the topicref type
(e.g., a pubmap-d/part topicref causes the referenced topic to be labeled
"Part x.").

However, it wasn't working in a map that used part-mapref topicrefs to point
to submaps for parts. WTF?

Of course, on reflection, I realized that the effective topicref in the
resolved map in that case is pubmap-d/part-mapref, not pubmap-d/part. Doh!

Currently both "part" and "part-mapref" are defined in the same vocabulary

One solution, and I think the appropriate solution in my case, is to have
part-mapref be a further specialization of pubmap-d/part.

I want to confirm that this necessarily requires a separate vocabulary
module because a given module can only express one level of specialization,
meaning that I *cannot* have both of these declarations in the same module:

<!ATTLIST part CDATA "+ map/topicref pubmap-d/part " >
<!ATTLIST part-mapref CDATA "+ map/topicref pubmap-d/part
pubmap-d/part-mapref " >

I'm asking because in this case there is no particular value otherwise in
having a separate module just for the mapref variants of the topicrefs and
it would make semantic sense (in the sense of "all these element types are
really part of the same unit of vocabulary definition and management) to
have a single model. That is, my mapref variants are really a syntactic
convenience for authors that should have exactly the same base semantic as

I'm pretty sure that the rules are clear but I just want to make sure that
I'm not seeing a rule that isn't actually there.

[Alternate solutions to my practical problem include:

1. Extending my code to match either pubmap-d/part or pubmap-d/part-mapref
2. Eliminating the separate *-mapref variants and require authors to
manually set the @format attribute when referencing a map.

(1) implies a potential explosion in processing complexity that can be
avoided by multiple levels of specialization.

(2) is what I was trying to avoid by my original design.



Eliot Kimber
Senior Solutions Architect
"Bringing Strategy, Content, and Technology Together"
Main: 512.554.9368

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]