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: Branch filtering: ditavalref as child of a map


Belatedly following up on an action item from the January 6 meeting. Here is a sample of the problems involved with having more than one <ditavalref> as direct children of a map. Take the following map:
<title>Here is a map for <ph audience="me">ME</ph><ph audience="you">YOU</ph></title>
<topicmeta> ... </topicmeta>
<ditavalref href=""> <ditavalref href=""> <topicref href=""> <topicref href=""> <topicref href=""> <reltable> ... relationship table ... </reltable>

Why this is difficult to handle:

The <ditavalref> element is intended to filter the containing element and its children. This is easy to understand in the context of a topicref:
<topicref href="" ... ditavalref, then topic children </topicref>

When there are multiple <ditavalref> elements in that case, it's easy to express using simpler markup -- just duplicate the branch:
<topicref href="" ... first ditavalref, then topic children </topicref>
<topicref href="" ... second ditavalref, then topic children </topicref>

With the map container, we can't duplicate the root element. Likewise - <reltable> can only appear as a child of <map>, so we cannot introduce grouping elements to make this simpler. (Note: this already results in odd wording related to mapref, where integrating a sub-map requires special treatment for reltable.)

From the discussion on January 6, I think it's clear that we expect the relationship tables to be processed with the filter, so that links continue to work within each copy of the content. Disallowing this would mean that at most, only one version of your content could be cross-linked.

It's less clear whether the title or metadata should be processed with the filter. I believe Eliot's assumption was no, while my assumption was yes. My preference is for consistency - if ditavalref always filters the container and its kids (including metadata) within topicref, it should do the same within map.

Part of the difficulty comes from the fact that this could be a root map, and it could be a submap.

In a root map, the sample above essentially creates two full publications, one filtered for "me" and one for "you". If we duplicate the title (or metadata), which is used by the publication as a whole? In a submap, the title already has little meaning. I'd still prefer to say it gets filtered - because then the submap works exactly the same way it would if you placed <ditavalref> inside of a reference to this map.

I think further discussion goes to the TC. My preference, if we can, is to say that <ditavalref> as a child of map works the same way as <ditavalref> inside a reference to the map. This might require special treatment for <ditavalref> as child of a root map, where you're effectively building one publication with multiple copies of the entire content. If the sample map above is a root map, then I think we could say it's equivalent to that same map (minus the <ditavalref>) referenced like this:
<mapref href=""> <ditavalref href=""> <ditavalref href=""> </mapref>

Robert D Anderson
IBM Authoring Tools Development
Chief Architect, DITA Open Toolkit (http://www.dita-ot.org/)

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