OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

docbook message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [docbook] Adding new element to docbook DTD


Jirka Kosek wrote:

> You can use multiple profiling attributes on a single 
> element. In this case conditions are "ANDed". E.g.
> 
> <para condition="C1" role="C2">
> 	this is a test
> </para>
> 
> And then use profile.condition=C1 and profile.role=C2 
> parameters for processing. Note that you might find more 
> appropriate attribute then role for the second condition. The 
> following attributes are supported directly for profiling:
> 
> <xsl:param name="profile.arch" select="''"/> <xsl:param 
> name="profile.condition" select="''"/> <xsl:param 
> name="profile.conformance" select="''"/> <xsl:param 
> name="profile.lang" select="''"/> <xsl:param 
> name="profile.os" select="''"/> <xsl:param 
> name="profile.revision" select="''"/> <xsl:param 
> name="profile.revisionflag" select="''"/> <xsl:param 
> name="profile.role" select="''"/> <xsl:param 
> name="profile.security" select="''"/> <xsl:param 
> name="profile.userlevel" select="''"/> <xsl:param 
> name="profile.vendor" select="''"/>

While this would work, my writers have expressed that they want their
conditions to be listed under a single attribute.  Technically, I think
this is one of two correct ways to approach this (see below).  Also, at
this point we have six products that will be profiled, and that number
is expected to grow.  

Another approach that I thought would work would be to define custom
profiling attributes that can be set to "true" or "false".  I think this
would actually be a better solution than my original idea of adding the
<if> element.  But it seems that this will not work either.  It appears
that docbook only allows creation of a single custom attribute through
the profile.attribute parameter.  Is there any way to use more than one
custom attribute?



Bob Stayton wrote:

> Another approach is to do two profiling passes.  On the first 
> pass, process your document with profiling/profile.xsl and 
> set profile.condition="C1".  Any elements with condition="C2" 
> will be removed.  On the second pass, process the result of 
> the first pass with the same stylesheet but set 
> profile.condition="C2". 
> That will remove any elements with condition="C1", leaving 
> only those with condition="C1;C2".  Then process the result 
> of that with the regular stylesheet.

My purpose here is to develop a process to be used for my company's
technical writing staff.  I am a developer and will not be involved with
the transforming of documentation once a process is in place.  While
this approach would work fine if I were transforming docs myself, I
think it is a bit more complex than what we are looking for.



Dick Hamilton wrote:

> John,
> 
> What I'd be inclined to do in this case is to define a new 
> condition, C3, which is true when C1 and C2 are true, then 
> use that condition on a single para.  I presume you're 
> calling your xsl processor with profile.condition set to 
> "C1;C2", so you'd just use "C1;C2;C3" instead and put condition="C3"
> on your para.  Unless you've got a boatload of conditions and 
> combinations, this should be reasonably clean and doesn't 
> require any customization.
> 
> Another choice would be to make your inner nested para a phrase.
> Since phrase shouldn't generate any line breaks, etc., you 
> won't get the spurious output.  But, if C1 is set and C2 
> isn't, you'll get an empty para, which you probably don't 
> want.  Also, you can't nest any block elements inside the 
> phrase, which may or may not be a problem.
> 
> Dick Hamilton
> 
> P.S.  I just noticed Jirka's response, which is yet another
>       way of approaching this problem.  Overall, I think you'll
>       find there are several ways of looking at this that don't
>       require customization.

I think I mentioned in my reply to Jirka's email that we currently have
six possible profiling conditions.  This number is going to get bigger
in the future.  These conditions can be combined in any number of ways.
If we had only a few conditions, this would be a perfect solution, but I
think it would be quite a hassle with the number of conditions we have.

I really appreciate all the responses.  I would be very interested in
any feedback on the possible approach of adding more custom attributes
(mentioned in my reply to Jirka) or any other ideas you might have.  I
really think that is the best possible solution.  

I get the feeling from the responses I am getting that customizing the
DTD is not something that is reccommended.  Is this the case?  Why?

Thanks,
John


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]