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: Re: [dita] Conformance and Feature Optionality/Flexibility


Ogden, Jeff wrote:

> I'd like to take some sections of "Inheritance of attributes and 
> metadata in maps" and "Topic properties in topics and map" from Chapter 
> 3 on “DITA markup” in the /DITA 1.1 Architectural Specification/ and see 
> how they fit into this approach.
> 

> In particular the specification says:
> 

> “Some of the attributes and metadata in a map can be inherited based on 
> the structures in the map.
> 
> Inheritance is additive except where this would cause a conflict. When 
> there is a conflict, the value
> defined closest (most specifically) to the topicref takes effect.”
> 
> [There is a list of the specific attributes and metadata elements are 
> inheritable.]
> 
> “You can associate topic metadata with a topic or branch of topics in a 
> map. By default metadata in the
> map supplements or overrides metadata in the topic. If the lockmeta 
> attribute is set to ″no″, then the
> metadata in the map will not take precedence over the metadata in the 
> topic, and conflicts will be
> resolved in favor of the topic.”
> 
> The above statements describe behaviors that fit into the “element type 
> and attribute definitions” feature category.

> The behaviors are mostly of concern to “renderers”, but could also apply 
> to “editors”, “information management systems”, and “source-to-source 
> transformers”.

> I’m less sure about which “defined processing requirements” category the 
> behavior falls into, but suggest “required but variable” as the best 
> fit. I can imagine that some may feel that “rendition-defined with 
> defaults” is the better fit.  I don’t think either “required and 
> invariant” or “rendition-defined” without defaults are appropriate for 
> this case.

> Am I approaching this is the right way?

I think so.

> Did I pick the right “feature” and “processor type” categories?

I think that this feature applies to all processor types. That is, all
the DITA features that define the rules for determining effective values
are relevant to all processor types, simply because they all either
contribute to the determination of values or act on the values.

> Which processing requirements category is the right one for this case?

I think this is "required but variable". In particular, this aspect of
DITA is defining the rules for determining the effective values of
attributes and elements. It is essential that all processors use the
same effective values for a given data set, but what they do with those
effective values is still variable.

My analysis is that features that define effective values are all
required but variable. So this feature is of a kind with conref= and
keyref=.

The language in the spec using the terms "must" and "shall" is another
indicator of requiredness.

Cheers,

Eiot

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


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