Re: [dita] Issue 13041: Reminder of prior discussion

[Michael Priestley <mpriestl@ca.ibm.com>]

Thanks, Eliot.

There's a lot to go through here, but
I think the key point for me is accomodating the case where the same content
is included in both a single publication and separate publications. This
is the current DITA spec case - arch and langref published both together
and separately, with crosslinks resolved internally for the first case
and externally for the second.

My example used a single keyspace for
both, without fragment identifiers. I still think this is perfectly acceptable
and should be supported. 

Your example uses a separaet keyspace
for one but not the other, and I'm not sure how that's managed. Is it that
the author creates a map-scoped keyref either way, but the map-scoped href
is simply a scoped href in the together case, but becomes a cross-keyspace
reference in the second case?

If that's what you're suggesting, I
think I'm comfortable with that. The only thing missing (and it's a big
thing still) is the acceptance of map-based scoping in keyref, and the
detailing of all the processing implications (I'm not sure how many processors
maintain a record of the original map structure once an aggregated map
has been created, by mapref and conref etc.). That would be under the scope
of Chris's scoped keyref proposal I think.

If my understanding is correct, effectively
we end up with the two scenarios roughly like this:

- in my separate-build scenario, keys
are coordinated, so the build just includes a list of all addressable keys
from the other deliverable at build time, and authors use keyrefs normally
- in your separate-build scenario, keys
are not coordinated, but the build can still include either a full list
of all addressable keys, or a short list of just the ones needed - and
authors use keyrefs with map fragment identifiers to disambiguate

Both scenarios would be acceptable,
and both would accomodate arbitrary build combinations.

Eliot, does that sound right?

Michael Priestley, Senior Technical
Staff Member (STSM)
Lead IBM DITA Architect 
mpriestl@ca.ibm.com
http://dita.xml.org/blog/25

From:	Eliot Kimber <ekimber@reallysi.com>
To:	dita <dita@lists.oasis-open.org>
Date:	11/22/2011 11:56 AM
Subject:	[dita] Issue 13041: Reminder of prior discussion
Sent by:	<dita@lists.oasis-open.org>

---

My last treatise on this issue is here:
http://lists.oasis-open.org/archives/dita/201109/msg00032.html

To summarize: I think Michael's general approach of using keys to
capture/define rendition-specific addresses is sound and a useful
abstraction.

However, I still feel that providing a way to address key spaces explicitly
is essential. My post tries to explain my reasoning in detail and to define
an abstract processing model that allows us to avoid specific implementation
details while we're discussing the requirements and potential solutions.

Cheers,

E. 

-- 
Eliot Kimber
Senior Solutions Architect
"Bringing Strategy, Content, and Technology Together"
Main: 512.554.9368
www.reallysi.com
www.rsuitecms.com


---------------------------------------------------------------------
To unsubscribe, e-mail: dita-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: dita-help@lists.oasis-open.org