Hi, Mary.
The profiling chapter provides great information, but I was initially missing a simple use case for implementing a ProductName variable, which appears in our XML source as: &ProductName;
The part I was missing was putting the ProductName entity in the header of our XML files (after <?xml version.. and the DocBook schema declarations) as follows:
<!DOCTYPE section [
<!ENTITY ProductName '<phrase condition="Mobile">Mobile-specific Product</phrase><phrase condition="Buyer">Buyer-specific Product</phrase><phrase condition="Seller">Seller-specific Product</phrase>'>
]>
We then indicate the desired product name condition in our oXygen transform scenario by setting the profile.condition parameter to a one of our condition values, such as Mobile. Once the transform then replaces &ProductName; with the desired product name for the target help system.
We also show or hide any product-specific content using audience attributes, such as <para audience="seller"> and then set the profile.audience parameter in our oXygen transform scenario to the desired value.
Perhaps others on this list can let us know a better approach.
Thanks,
--Jared Crawford
Pasadena CA USA
On Friday, January 23, 2015 1:57 PM, Barton Wright <> wrote:
Hi Mary,The keyword you’re looking for is profiling. Seehttp://www.sagehill.net/docbookxsl/Profiling.htmlBest of luck with DocBook. Ask anything anytime.
> I'm brand new to docbooks, having inherited it through this job I started. Now that I have my build scripts working, I'm in good shape, except that I've not yet figured out how best to achieve this simple goal: create a variable (such as ProductName) that can resolve to one of several values based on whether it's a corporate or an OEM build target.> > I must not be searching on the correct words to find out how this is typically done!> Gratefully,> Mary
---------------------------------------------------------------------To unsubscribe, e-mail: additional commands, e-mail:
