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.

http://www.w3.org/TR/skos-reference/#L4307.

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.

cheers

Jim

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
To: DITA TC
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.

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

dita message