MHonArc v2.5.0b2 -->
dita message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [dita] Topic vs Domain Specialization
Hi Eliot,>In particular, I'm curious as to why DITA needs
the domain declaration
>and why the class value distinguishes topic-level specializations from
>domain-level specializations through the use of "+" or "-"
as the
>leading character.Conref cannot accurately predict whether two paragraphs
have equivalent content models without knowing which domains have been
integrated into the two topic types. The domain attribute provides a way
for processes to determine when two elements of the same type, possibly
even in the same topic type, have different content models. See the topic
on "content reference attribute" in the spec for details.Generalization has different default behavior for
domain elements versus type elements. See the topic on generalization in
the spec for details.This all comes out of the need to share and include
markup across structures without declaring new names for the shared elements
or impairing reuse of their content. If two topic types have the same element
but have created different content models, you need to know how to map
them when you reuse between them or generalize from one to the other. Mappings
between topic types or map types and their ancestors are provided in the
root-level class attribute; mappings between domains in use and their ancestors
(not necessarily in use in the instance, but in use by the document type)
are provided in the root-level domains attribute.Hopefully this explains why we have the topic on "information
types and domains" (to be renamed to "structural specialization
and domain specialization") in the "Specialization in content"
section, rather than in the "Specialization in design" section
(per your original request to separate out the use of specialization in
document instances from the syntax tricks that we require for design modules
to be reusable across document types).
Michael Priestley
mpriestl@ca.ibm.com
Dept PRG IBM Canada phone: 416-915-8262
Toronto Information Development
I've read through the original IBM DITA distribution
writeups on topic
and domain specialization and I'm having a hard time seeing a
fundamental difference between the two forms of specialization.
I do understand that they represent different *degrees* of effort such
that specializing a topic to a new topic type requires more thought and
typing than does specializing p or ph to a domain-specific type. I also
recognize that there are two clearly distinct specialization use cases
(as discussed below).
But the practical result is the same in both cases: a new concrete
document type with specialized element types.
In addition, the core mechanism for the specialization is the same and
the constraints on specialization are the same.
Note that I'm purposely ignoring all the syntax tricks used in the
current DITA DTD declaration sets--these may be useful practical syntax
tricks but they cannot have any affect on the *semantics* of the
resulting specialized document type. Therefore I consider them to be a
distraction from the primary goal of understanding the basic semantics
and rules of specialization.
What I see the DITA spec saying is that there are two basic
specialization use cases:
- You don't need new topic types but you do need new "content"
types
(where by "content" I mean "the stuff you can put in the
topic body" and
by "topic" I mean "topic and its direct children")
- You do need new topic types, and as part of that you may or may not
also need new content types
DITA also recognizes that a given set of domain-specific
specicalizations may be useful in different contexts, so it is useful to
modularize their declarations.
I agree with all of these observations.
DITA is also observing, correctly I think, that in many cases the only
useful semantic difference between documents is at the content level
where you need either specialized mentions (specializations of ph) that
refer to instances of domain-specific things or you need specialized
structures for containing structured data about domain-specific things
(e.g., characteristics data for laser printers).
That is, some business-specific requirements can be met by specializing
*only* at the content level and some can only be met by specializing at
the topic level. This is a fact, so I'm not disagreeing with this
distinction as a practical one and useful one.
However, I'm not seeing how this distinction does or should lead to two
fundamentally different types of specialization *mechanism*. It may lead
to different specialization *practice*, but the underlying mechanism
should be the same, or at least have a common underlying base mechanism.
In particular, I'm curious as to why DITA needs the domain declaration
and why the class value distinguishes topic-level specializations from
domain-level specializations through the use of "+" or "-"
as the
leading character.
That is, I'm not seeing how the processing of a given element in terms
of its specialization hierarchy would differ simply because it's a
domain element or a topic element.
So what essential bit of understanding am I missing?
I'm also thinking that a lot of these issues of domain vs. topic
specialization, specialization constraints, and domain modularization
become a lot clearer and easier to work with when using XSD schemas,
where you do have explicit declarative ways to define specialization
constraints and to do specialization. I've done some experimental work
along these lines but I'm not quite ready to share the results--I need
to get some more experience and do some more thinking about the
implications of the approach I've taken because I'm not 100% sure it's
the best approach. I also need to develop generic examples of what I've
so far done for a specific client.
I think that one possible issue here is that the limitations of DTD
syntax have forced the original DITA developers to depend on syntax
tricks and conventions when they really need formal, declarative ways to
do things.
Cheers,
Eliot
--
W. Eliot Kimber
Professional Services
Innodata Isogen
9390 Research Blvd, #410
Austin, TX 78759
(512) 372-8122
eliot@innodata-isogen.com
www.innodata-isogen.com
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]