I can't think of a reason you would need the id value for the topic to be the same in a different map/Help system. The CMS does its own bookkeeping with its own object id under the hood to maintain single sourcing. File-based management doesn't use the id. Beyond that, why would anyone care? What am I missing?
> -----Original Message-----
> From: Tony Self [mailto:]
> Sent: Monday, January 10, 2011 6:28 PM
> To: 'Kristen Eberlein';
> Cc: 'Ymte Westra'
> Subject: RE: [dita-help] Current best practices for context hooks
>
> Hi Kris
>
> For me, having the context hooks in the map means that the
> task of allocating the ids can be managed more easily. I
> don't have to open up every stinking topic individually... I
> can just work my way down the ditamap tree.
>
> That doesn't mean that storing hooks in the map is right for
> all situations.
> If I am single-sourcing a topic in a different map, and am
> using the same id, I would have to repeat my effort by adding
> the hook in the second map.
> However, if the id was different for different publications,
> I could use different ids in the different maps.
>
> Tony Self
>
> -----Original Message-----
> From: Kristen Eberlein [mailto:]
> Sent: Friday, 7 January 2011 11:08 PM
> To: ;
> Cc: Ymte Westra
> Subject: RE: [dita-help] Current best practices for context hooks
>
> Hi, Tony.
>
> What do you see as the pros and cons for using the
> <resourceid> element in the DITA map? In the DITA topics?
>
> Many thanks!
>
> Best regards,
> Kris
>
> Kristen James Eberlein l DITA Architect and Technical
> Specialist l SDL Structured Content Technologies Division l
> (t) + 1 (919) 682-2290 l
>
> Please consider the environment before printing this e-mail
>
>
>
>
> -----Original Message-----
> From: Tony Self [mailto:]
> Sent: Friday, January 07, 2011 5:51 AM
> To: Kristen Eberlein;
> Cc: Ymte Westra
> Subject: RE: [dita-help] Current best practices for context hooks
>
> Hi Kris
>
> Like Chris, I use the resourceid element, but in the ditamap,
> and for Microsoft HTML Help output. I use the htmlhelp2 or
> htmlhelp+ plug-ins to the OT (developed by Deb Pickett).
> Those plug-ins convert the resourceid contents to HTML Help
> alias and map files.
>
> Tony Self
>
>
> -----Original Message-----
> From: Goolsby, Chris [mailto:]
> Sent: Friday, 7 January 2011 2:13 AM
> To: Kristen Eberlein;
> Cc: Ymte Westra
> Subject: RE: [dita-help] Current best practices for context hooks
>
> Yes, we assign a help ID to the <resourceid>, such as
> "help17074". When we publish the DITA to HTML, the stylesheet
> takes the value in <resourceid> and passes it to a <meta> tag
> inside of the published HTML chunk for the topic.
> The application calls the right topic based on the help ID
> value in the <meta> tag.
>
> Chris
>
> -----Original Message-----
> From: Kristen Eberlein [mailto:]
> Sent: Thursday, January 06, 2011 9:57 AM
> To: Goolsby, Chris;
> Cc: Ymte Westra
> Subject: RE: [dita-help] Current best practices for context hooks
>
> Hi, Chris.
>
> So you are adding the <resourceid> element to the <prolog>
> element within the DITA topic?
>
> Best regards,
>
> Kris
> Kristen James Eberlein l DITA Architect and Technical
> Specialist l SDL Structured Content Technologies Division l
> (t) + 1 (919) 682-2290 l
>
> Please consider the environment before printing this e-mail
>
>
>
>
> -----Original Message-----
> From: Goolsby, Chris [mailto:]
> Sent: Thursday, January 06, 2011 9:36 AM
> To: Kristen Eberlein;
> Cc: Ymte Westra
> Subject: RE: [dita-help] Current best practices for context hooks
>
> At PTC Arbortext, we use the resourceid in topics to hold our
> context hooks.
> The stylesheet passes the value in the resourceid to the
> published HTML, and the product grabs the right topic based
> on that value.
>
> Regards.
>
> Chris Goolsby
> PTC
>
> -----Original Message-----
> From: Kristen Eberlein [mailto:]
> Sent: Thursday, January 06, 2011 9:29 AM
> To:
> Cc: Ymte Westra
> Subject: [dita-help] Current best practices for context hooks
>
> What are people currently doing for context hooks? SDL has
> some clients who cannot wait for DITA 1.3; any current best
> practices that we should practice?
>
> Best regards,
> Kris
>
> Kristen James Eberlein l DITA Architect and Technical
> Specialist l SDL Structured Content Technologies Division l
> (t) + 1 (919) 682-2290 l
>
> Please consider the environment before printing this e-mail
>
>
> -----Original Message-----
> From: Tony Self [mailto:]
> Sent: Monday, December 06, 2010 1:33 AM
> To:
> Subject: [dita-help] Help Features in DITA 1.3
>
> Greetings colleagues
>
> Now that 1.2 has been released, we have to start thinking
> about 1.3. You will probably recall that the Help
> Subcommittee was established to make recommendations for 1.3;
> it wasn't anticipated that 1.3 would be so far away.
>
> So far, we have proposals for spec changes to better handle
> context hooks, and window definitions.
>
> We have discussed in the past the possibility of a
> specialisation for integrated or embedded user assistance content.
>
> There has been some negative feedback from the community
> about the perceived complexity of 1.2, with new information
> types, constrained versions of some types, and a (perceived)
> mushrooming in the number of elements.
>
> My feeling is that the context hook and window definitions
> should be built into the base content model. My feeling is
> that we should not have a specialised information type for
> UA, mainly because I don't think the community is demanding
> such a thing.
>
> What do you all think?
>
> Tony Self
>
>
>
> ---------------------------------------------------------------------
> 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_workgr
> oups.php
>
>
> ---------------------------------------------------------------------
> 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_workgr
> oups.php
>
>
> ---------------------------------------------------------------------
> 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_workgr
> oups.php
>
>
> ---------------------------------------------------------------------
> 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_workgr
> oups.php
>
>
> ---------------------------------------------------------------------
> 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_workgr
> oups.php
>
>
