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 of attributes through mapref


I've edited some questions and comments into the text below.

 

   -Jeff

 

> -----Original Message-----

> From: Robert D Anderson [mailto:robander@us.ibm.com]

> Sent: Monday, March 23, 2009 9:08 AM

> To: dita

> Subject: [dita] Inheritance of attributes through mapref

>

> This is a summary of the item discussed last week and the week before,

> initially raised here:

> http://wiki.oasis-open.org/dita/MaprefResolution

>

> The consensus at the TC as I understand it is that attributes specified on

> a map reference are equivalent to the same attributes specified on the

> target element. Exceptions are format (which must be 'ditamap') and href

> (which references the target).

 

So some properties such as @format cascade within a map, but not from map to map. Other properties such as @linking cascade within a map and from map to map. And still other attributes such as @href don’t cascade within a map or from map to map. Am I following this correctly? If this is correct, it seems OK to me, we just need to explain clearly which category each attribute or property is in.

 

Is there yet another case where a property can cascade from a map to a topic or from a map to a map to a topic and in both cases on to elements within the topic? Are the rules for map to map cascades and the rules for map to topic cascades the same?

 

Is @scope in the same category as @format?  I’ve always thought of @format and @scope as qualifying the @href value on the current element.  Is @format=”ditamap” a special case where @scope is ignored on the current element and just passed on?  If so, is that a good idea?  And if it isn’t a special case, don’t you need to specify @scope=”local” @format=”ditamap” for things to make sense?  I’m not sure what @scope=”external” @format=”ditamap” or @scope=”peer” @format=”ditamap” would do, but it would seem that the DITA map wouldn’t be available for local processing unless @scope is “local” either explicitly or by default.

 

> For example, if I have this map reference:

> <topicref href=""someMap.ditamap"

>           format="ditamap"

>           toc="no"

>           scope="peer"

>           print="no"

>           linking="normal"/>

>

> In the map someMap.ditamap, the toc / scope / print / linking attributes

> from that topicref will override whatever is set or defaulted on the <map>

> element. From there, those attributes will cascade as they normally would

> within someMap.ditamap.

 

So when a single valued attribute like @linking cascades within a map, it provides a default value for elements that support @linking and which do not have an explicit value for @linking set, but does not override explicitly set values. And when a single valued attribute like @linking cascades from a map to a map, it does override any explicitly specified @linking value specified on the <map> element, and then we go back to regular non-overriding cascading within the referenced map.  Is that correct? That might work, but it isn’t possible to override explicitly set @linking values on topicrefs in the referenced map with this approach.  That is OK by me, but I just wanted to make sure that I understand the proposal.

 

Multi-valued attributes such as @audience are a bit different since they never override and instead their values are merged with values from lower level elements when they cascade both within a map and from map to map.  Still right so far?

 

And thinking about @scope again: It is a single valued attribute, but I’m not sure how much sense it makes to have one map change the effective scope value on a topicref in another map without also being able to change the @href and @format values (something you can do using key references, but not with map to map cascading).  Take this example:

 

<map  title=”map1”>

<topicref  href="”sometopic.dita”"  format=”dita”  />

</map>

 

So @scope on the topicref defaults to “local”.

 

But what happens if I reference this map from another map:

 

<map  title=”map2”>

<topicref  href="”map1.ditamap” " format=”ditamap”  scope=”external” />

</map>

 

Does this make the effective value of @scope “external” on the topicref for “sometopic.dita”? And if it does, what does that do?

 

> Similarly, if I have this construct in the original map:

> <topicref toc="no">

>   <topicref href=""someMap.ditamap"" format="ditamap"/>

> </topicref>

>

> The toc="no" attribute will cascade to the map reference, which is then

> treated the same as in the previous example, and will override the toc

> attribute on the map element within someMap.ditamap.

 

And does this work the same way for both @toc=”yes” and @toc=”no”? And in both cases the @toc value would apply to all topicrefs that don’t have an explicitly specified @toc value, but it would not override a @toc value that was explicitly set other than possibly a @toc value on the <map> element, nor would @toc cascade to topicrefs within reltables because @toc on <reltable> has a default of “no” specified in the DTD or XML Schema?  If I’m understanding this correctly, I think it is OK, although I’m not sure how useful this will be.

 

> An attribute that is defaulted in the DTD or Schema is treated in the same

> way as an attribute specified in the document.

>

> A value generally treated as a processing default does *not* cascade in the

> same manner. For example, within a map where no element specifies the scope

> attribute and no element has a default scope attribute, there will be a

> processing default of scope="local". That processing default will not

> override whatever is specified at the root of someMap.ditamap.

 

I have my usual reservations about @scope, but lets pick a different attribute as an example.

 

Say that @linking is not specified at all in the higher level map and so defaults to “normal” as the processor supplied default within that map, but the @linking value would not cascade from the higher level map to a lower level map.

 

What happens if I have nested topicrefs in a higher level map as follows:

 

<topicref  linking=”none”>

      <topicref  href="”someothermap.ditamap” " format=”ditamap”  />

</topicref>

 

So here linking=”none” cascades from the first topicref to the nested topicref, but is it a processor supplied default and so it does not cascade on to the referenced map. Or is a cascading value different from a processor supplied default and so @linking=”none” would cascade on to the referenced map?

 

Some of this was discussed by an ad hoc group back last September and summarized in a note to the TC:

 

http://lists.oasis-open.org/archives/dita/200810/msg00009.html

 

Most of this current proposal is in line with the earlier discussion, but the earlier discussion did not make a distinction between explicit values and processor supplied defaults in terms of map to map cascading, they all cascade from map to map no matter where/how they originated.  The current proposal only has explicit values cascading and processor supplied defaults do not cascade.  Is the change deliberate?  It seems simpler and more consistent to me to be able to determine what an attributes value is using explicit values, DTD defaults, cascading within the document, and processor supplied defaults into account, and then after you know what the attribute value is to have that value cascade on to the referenced document if appropriate.

 

Do we need to bring controlled value defaults into this discussion?  The September 2008 discussion had controlled values being applied within a document before other processor supplied defaults and then the final result would cascade from one document to another.

 

> Any questions/comments, please respond to the list...

>

> Thanks -

>

> Robert D Anderson

> IBM Authoring Tools Development

> Chief Architect, DITA Open Toolkit

>

>

> ---------------------------------------------------------------------

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