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

Hi Kris


Yes, I read the spec a while back on merging.

This is a small part of my rough proposal and was mentioned for consistency and is a bit of a sideshow – I would be fine if you split that sideshow off or killed it.  It comes from a vague wondering on the idea of a distributed taxonomy where different  subjectSchemes add part of the taxonomy.

I have not encountered that idea yet (but am open to hearing about it) – as I add pieces to my own taxonomy.

I have heard about different taxonomies for different folks around the same subject matter – development uses different terms than sales and I can understand that.  But merging in – not so sure.

SKOS has a taxonomy mapping layer, but that is an attempt to map between conceptSchemes – like mapping from dev terms to sales terms.



Anyhow, this should likely be a separate discussion or no discussion from the other points in the proposal.

Merging in general, however, is related to enumerationDef merging, or not, which is also under discussion.





From: dita@lists.oasis-open.org [mailto:dita@lists.oasis-open.org] On Behalf Of Kristen James Eberlein
Sent: March-26-13 12:37 PM
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.


Kristen James Eberlein
Principal consultant, Eberlein Consulting
Co-chair, OASIS DITA Technical Committee
Charter member, OASIS DITA Adoption Committee
+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


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


        <linktext>Tractor X</linktext>



    <topicref href="">



*** 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.






--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

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