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] Inheritance vs Cascade: Propagation?



I don't often chime in on these discussions but metadata is one area in 
which I believe there is room for improvement in DITA.  The real 
solution is probably something for a later version but there is some 
relevance here.

I think it is important to make a distinction between 
cascading/inheritance/propagation at the time of content creation vs 
during content maintenance and/or reuse.  It also makes a difference if 
it is map to map vs map to topic.  At the time of content creation 
cascading of set values is useful.  If, however, you are combining 
existing content (map or topic) with new content or a new aggregation 
then any form of imposition of new metadata values on the existing 
content is not likely to be appropriate.  Because aggregation is 
normally a human supervised activity there should be a choice provided 
for a human to act upon in line with business rules that recognize 
rights and authority.  That is primarily an implementation issue so the 
wording in the standard probably requires options in the normative 
language and guidance in the informative language.

Longer term, I believe that more metadata needs to be associated rather 
than embedded to accommodate these sorts of issues as well as being able 
to accommodate the removal of CoP specific metadata that is currently 
embedded but that has little relevance to the new CoPs beginning to 
specialize DITA.  Such a model would also accommodate reaggregation 
better and I think will resolve some of the difficulties related to 
original metadata vs cascading/propagating/inheriting metadata.

Eliot Kimber wrote:
> Reading this section more closely, it seems like there's actually two
> different things going on:
>
> - Cascading, in the sense meant by say cascading style sheets, of
> "inheritable" attributes down the *map* hierarchy, where local values
> override values from ancestors.
>
> - Metadata imposition or replacement from maps to topics, where the values
> on the topics are overridden or replaced by values in the map.
>
> I've commented in the wiki that this whole section ( Inheritance of
> attributes and metadata in maps) needs to be refactored to be more effective
> structurally and I'm willing to help take a stab at that rewrite.
>
> Cheers,
>
> E.
>
> On 7/6/09 5:46 AM, "Eliot Kimber" <ekimber@reallysi.com> wrote:
>
>   
>> WRT the discussion in comments on the Inheritance of attributes and metadata
>> in maps section, I wonder if "propagation" isn't the best term. That was the
>> term we used in HyTime for a similar feature.
>>
>> That is, metadata and attribute values "are propagated" from ancestor to
>> descendant elements and from topicrefs to topics, emphasizing that this is a
>> processing action,
>>
>> Although I agree that inheritance is definitely the wrong term, so "cascade"
>> is better. In particular, inheritance in the OO sense implies that local
>> values override inherited values, but that is not necessarily the case here,
>> where maps can, in some cases, impose values onto referenced things.
>>
>> Cheers,
>>
>> E.
>>
>>
>> ----
>> Eliot Kimber | Senior Solutions Architect | Really Strategies, Inc.
>> email:  ekimber@reallysi.com <mailto:ekimber@reallysi.com>
>> office: 610.631.6770 | cell: 512.554.9368
>> 2570 Boulevard of the Generals | Suite 213 | Audubon, PA 19403
>> www.reallysi.com <http://www.reallysi.com>  | http://blog.reallysi.com
>> <http://blog.reallysi.com> | www.rsuitecms.com <http://www.rsuitecms.com>
>>
>>
>> ---------------------------------------------------------------------
>> 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
>>
>>     
>
> ----
> Eliot Kimber | Senior Solutions Architect | Really Strategies, Inc.
> email:  ekimber@reallysi.com <mailto:ekimber@reallysi.com>
> office: 610.631.6770 | cell: 512.554.9368
> 2570 Boulevard of the Generals | Suite 213 | Audubon, PA 19403
> www.reallysi.com <http://www.reallysi.com>  | http://blog.reallysi.com
> <http://blog.reallysi.com> | www.rsuitecms.com <http://www.rsuitecms.com> 
>
>
> ---------------------------------------------------------------------
> 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 
>
>
>   

-- 
Allyn J Radford
Managing Director
Learnilities Pty Ltd
www.learnilities.com.au

Solution Architecture Consulting
Standards-based eLearning Systems and Content
Digital Content Exchange Planning and Development

Phone: +61 (0)3 9751 0730
Mob:   +61 (0)419 009 320

--



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