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

------------------------------------------------------------
---------
To unsubscribe, e-mail: docbook-unsubscribelists.oasis-open.org
For additional commands, e-mail: docbook-helplists.oasis-open.org

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 <jdyeropushealthcare.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-unsubscribelists.oasis-open.org
> For additional commands, e-mail: docbook-helplists.oasis-open.org
>
>


--
http://chris.chiasson.nam
e/

------------------------------------------------------------
---------
To unsubscribe, e-mail: docbook-unsubscribelists.oasis-open.org
For additional commands, e-mail: docbook-helplists.oasis-open.org

John Dyer wrote:

> 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.  

I don't think that it is good idea to place unrelated
conditions into a 
single attribute. But if you want to do it, you can, but you
must create 
your customized version of the following template:

<!-- Returns non-empty string if list in $b contains one
ore more values 
from list $a -->
<xsl:template name="cross.compare">
   <xsl:param name="a"/>
   <xsl:param name="b"/>
   <xsl:param name="sep"
select="$profile.separator"/>
   <xsl:variable name="head"
select="substring-before(concat($a, $sep), 
$sep)"/>
   <xsl:variable name="tail"
select="substring-after($a, $sep)"/>
   <xsl:if test="contains(concat($sep, $b, $sep),
concat($sep, $head, 
$sep))">1</xsl:if>
   <xsl:if test="$tail">
     <xsl:call-template
name="cross.compare">
       <xsl:with-param name="a"
select="$tail"/>
       <xsl:with-param name="b"
select="$b"/>
     </xsl:call-template>
   </xsl:if>
</xsl:template>


Your version of template should return non-empty string only
if $b 
contains all conditions mentioned in $a.

> 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?

Are you sure, that your conditions can not be stored in
attributes like 
os, wordsize, arch, ... which are supported directly? Even
if not, you 
can customize template <xsl:template
match="*" mode="profile">
  from profiling/profile-mode.xsl to handle your custom
attributes.

> 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?

I think that opposite is true. With customized DTD
efficiency of 
authoring and your whole documentation system will be much
better than 
with stock DocBook. (Of course, I'm biased here, because it
is my job to 
create custom DocBook based documentation systems for my
customers. 

				Jirka

-- 
------------------------------------------------------------
------
   Jirka Kosek     e-mail: jirkakosek.cz     http://www.kosek.cz
------------------------------------------------------------
------
   Profesionální školení a poradenství v oblasti technologií
XML.
      Podívejte se na náš nově spuštěný web http://DocBook.cz
        Podrobný přehled školení http://xmlguru.cz/skoleni/

------------------------------------------------------------
------
                    Nejbližší termíny školení:
      ** XSLT 13.-16.3.2006 ** XML schémata 24.-26.4.2006 **
        ** DocBook 15.-17.5.2006 ** XSL-FO 12.-13.6.2006 **
------------------------------------------------------------
------
   http://xmlguru.cz    Blog
mostly about XML for English readers
------------------------------------------------------------
------