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 CrawfordPasadena CA USA
On Friday, January 23, 2015 1:57 PM, Barton Wright <[email protected]>
wrote:
Hi Mary,
The keyword you’re looking for is profiling. See
http://www.sagehill.net/docbookxsl/Profiling.html
Best 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: [email protected]
For additional commands, e-mail: [email protected]
