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: @domains Attribute Details


Per my comment and subsequent action to try to collect all the @domains
specific rules in one place, I have combed the spec for any mention of the
syntax details of @domains.

Here is my analysis of the rules and where they are currently specified or
alluded to:

1. For structural modules, the structural type hierarchy SHOULD be listed
[2.1.4.2, 2.1.4.2.2, 2.1.4.3.1]:

(topic concept)
(map bookmap)

[Side note: These declarations appear to be missing from the DTD versions of
the specialized topic and map types but are in the XSD versions.]

2. If a structural type depends on one or more domains, those are listed
following the structural type [2.1.4.3.8.1.3]:

(topic concept myProgrammingConcept pr-d)

The implication being that topic type myProgrammingConcept must always be
integrated with the programming domain and uses one or more element types
from the programming domain directly in myProgrammingConcept content models.

3. Each separately-integrated domain module is listed with its ancestor
modules [2.1.4.3.8]:

(topic pr-d)
(topic pr-d cpp-d)
(map mapgroup-d my-topicheads-d)

4. Constraint modules are listed with the structural or domain module they
constrain [2.1.4.4.1]:

(topic noMixedContentTopic-c)
(map noReltable-c)

Note: The current spec language actually says:

The replacement text for the entity must be of the form "(tagname
qualifierTagname-c)", where tagname is the name of the element type to which
the constraints apply, qualifier is as for the module filename (e.g.,
"strict"), and Tagname is the element type name with an initial capital
(e.g. "Topic")

But I understand "tagname" in this context to mean "structural root type".
Or is the intent that if a constraint module only constrains "p" then then
the @domains spec would be "(p  noMixedContentP-d)"?

5. Attribute domains list their ancestor attribute (@props or @base) and use
"a(" to distinguish them from element-type modules [2.1.4.3.8.1.5]:

a(props myPropsAtt)
a(base myBaseAtt)

I think this covers everything--have I missed anything?

Technical Detail Question:

In 2.1.4.4.2 there is this example:

<xs:attribute name="domains" type="xs:string"
default="(topic noBasePhrase-c)
(topic strictTopic-c)
(topic strictTopic-c hi-d basicHighlight-c)"/>

Is the third domains spec in error, in that it should be "topic hi-d
basicHighlight-c"? If it's not in error, what is it saying? Or should the
second spec not be there (since it's redundant with the third)?

Assuming my analysis above is correct, I will update topic 2.1.4.3.4 Domain
usage declaration (the @domains attribute) with the above details and
replace text thereby made redundant with an xref to the @domains attribute
topic.

Cheers,

Eliot


-- 
Eliot Kimber
Senior Solutions Architect
"Bringing Strategy, Content, and Technology Together"
Main: 512.554.9368
www.reallysi.com
www.rsuitecms.com



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