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] Definition Handling



Jim, I'm only going to comment on the question of subjectScheme "merging." This behavior -- that is, the ability to expand/add subjects to an already-defined subject definition -- is clearly outlined in the DITA 1.2 spec (see the schemeref topic).

We cannot remove it without breaking backward-compatibility, nor do I think we'd want to -- there are too many scenarios in which this is required.

Kris

Kristen James Eberlein
Principal consultant, Eberlein Consulting
Co-chair, OASIS DITA Technical Committee
Charter member, OASIS DITA Adoption Committee
www.eberleinconsulting.com
+1 919 682-2290; kriseberlein (skype)

On 3/26/2013 2:35 PM, Jim Tivy wrote:

Discussion in today’s meeting was subjectScheme enumerationDef behavior, union or override.  As well, we talked about keydef and keyscope.

I think we need to try for unity and simplicity on definition behavior otherwise it may get out of control where things are not specified or implemented or understood by a great number of people.  Consider this rough sketch:

 

*** all definitions within a definitionSpace are global and go into the built in “default” definitionSpace.

*** When any first named definition is encountered it is the one in effect, all others with duplicate names in that space are ignored.

*** we promote putting definitions in one file and importing them in one place within a publication to minimize or remove DITA’s need for override and merge behavoir anywhere.

      This might suggest the subjectScheme merge rules should be removed too.

 

*** if we need scoping to satisfy the reuse topic different behavoir use case, we add an override attribute to keydef <keydef keys=”foo” override=”true” />  which is in effect for the mergedmap scope of the keydef

eg:  
<topicgroup>

    <keydef keys="ProductName" override=”true”>

      <topicmeta>

        <linktext>Tractor X</linktext>

      </topicmeta>

    </keydef>

    <topicref href=""/>

  </topicgroup>

 

*** definition spaces can be imported into a named space using <importDefinitions spaceName=”foo”> (like mapref)

*** simple references to keys always refer to keys in the “default” space (including scope overrides) which is the space we have now in DITA 1.2.

*** space qualified references to keys can take the form of myspace:mykey where myspace refers to an available named space brought in by >importDefinitions>

 

Please comment as to whether this can unify our definition handling and thus make DITA simpler.

 

 

 






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