[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]