Re: [docbook] Adding new element to docbook DTD

["Chris Chiasson" <chris@chiasson.name>]

1 - I am not an expert.
2 - This sounds like a case for modifying the xslt rather than the
dtd/schema/grammar.
3 - Think of the semicolon in profile.condition as an infix operator
representing a logical "or"
4 - Invent another operator, let's call it &&, as an infix operator
representing a logical "and"
5 - Where's the patch? :-]

in the markup, authors could use
<para profile.condition="PimpProduct1&&PimpProduct2">Here is how you
can use product 2 to enhance the operation of product 2.</para>

anyway - something along those lines

IMHO, this would be a good feature to have.

On 3/30/06, John Dyer <jdyer@opushealthcare.com> wrote:
> 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: docbook-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: docbook-help@lists.oasis-open.org
>
>


--
http://chris.chiasson.name/