RE: [dita] Conref push for static output formats

["Su-Laine Yeo" <su-laine.yeo@justsystems.com>]

Sorry, for the examples here:
http://www.oasis-open.org/committees/download.php/15120/IssueNumber17e.h
tml , I meant default.dita and push.dita, not default.dita and
source.dita. 

I think the spec should explicitly say whether or not processors are
required to resolve "pushed" conrefs across independent content sets for
all output types. For example, say you have two folders side-by-side:

- Folder1 containing a file called defaultmap.ditamap and a file called
default.dita. The map contains a topicref to default.dita. 
- Folder2 containing a file called pushmap.ditamap and a file called
push.dita, where the push.dita topic has a <step> to be pushed into a
set of steps in default.dita. The map contains a topicref to push.dita.

(As I understand, this is a typical scenario for conref push: Folder1
could be owned by one author and Folder2 could be owned by another
author who does not have the ability to edit the contents of Folder1.)

If you ask the Open Toolkit to process defaultmap.ditamap, it will not
know that pushmap.ditamap or push.dita exist. As far as I know, it would
require quite a radical change to the way processors work if we want
processors to accept more than one root ditamap at a time as input, i.e.
if we expect them to allow users to say, "Here are default.ditamap and
pushmap.ditamap, and go resolve them into one PDF file please." However
if we do not expect processors to accept more than one root ditamap at a
time as input, users wanting to use conref-push will have to make sure
that their root ditamap has links to all the content they need. 

I think it would be acceptable for processors to NOT resolve "pushed"
conrefs across independent content sets if there is a clean way for
users to create a link from defaultmap.ditamap to pushmap.ditamap
without producing unwanted side-effects such as duplicate content in
output. However, I do not know of a clean way for users to do this. The
closest thing we have is the "toc" attribute, however although this
would in theory suppress the contents of pushmap.ditamap from appearing
in a table of contents, it would not suppress the contents of
pushmap.ditamap from the body of the document.

What I'm looking for is to be able to set up defaultmap.ditamap so it
looks something like this:

<map>
	<topicref href = "default.dita"/>
	<topicref href = "../Folder2/pushmap.ditamap" format ="ditamap"
appear="no"/>
</map>

Then other authors can push whatever they want into the default content
set by naming a map "pushmap.ditamap" and placing it in the appropriate
location.

Su-Laine

Su-Laine Yeo
Interaction Design Specialist 

JustSystems Canada, Inc.
Office: 778-327-6356 
syeo@justsystems.com
http://na.justsystems.com 






-----Original Message-----
From: Su-Laine Yeo [mailto:su-laine.yeo@justsystems.com] 
Sent: Wednesday, December 10, 2008 7:02 PM
To: dita@lists.oasis-open.org
Subject: [dita] Conref push for static output formats

Hi everyone,

I think we could use some clarification on the processing exectations
for the "conref push" feature.

Using the examples from here:
http://www.oasis-open.org/committees/download.php/15120/IssueNumber17e.h
tml , it is basically clear how things should work if both the
default.dita and the source.dita topics are available to the processor
to be combined. I understand that this is the case in Eclipse, where the
combining of topics is done at runtime. It would also be the case for,
say, PDF output, if both topics are in the same map.

However, what if the author of source.dita does not have the ability to
edit the map file that default.dita is in? If source.dita and
default.dita are in totally separate maps, which of the two maps do I
give to the Open Toolkit when I want to create a PDF file?

I asked Robert Anderson this question earlier, and his response wasy,
"I'm not sure I can answer that. All of the scenarios I've
worked through in my own mind have the content available (both source
and target). This might be a question that's best left to the TC list."
So - over to the rest of you :)

Best,
Su-Laine

Su-Laine Yeo
Interaction Design Specialist 

JustSystems Canada, Inc.
Office: 778-327-6356 
syeo@justsystems.com
http://na.justsystems.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