Merchant, Daniel | 1 Sep 2010 03:22
Favicon

RE: Server Side Includes for ASP

It has taken me a week of running experiments to get the proper handle on this.

When I am producing unchunked HTML output, it does indeed work as you have described.    

Unless I am misconstructing a chunked HTML output customization, chunking does not work.

<?xml version="1.0"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">

  <xsl:import href="html/docbook.xsl"/>
  <xsl:import href="html/chunk-common.xsl"/>
  <xsl:include href="html/chunk-code.xsl"/>

  <xsl:template name="user.preroot">
  	<xsl:text disable-output-escaping="yes">
&lt;% <at>   Page language="VB" AutoEventWireup="false" MasterPageFile="~/FANUCRoboticsMasterPageMeta.master"%>
     </xsl:text>
  </xsl:template>

  <xsl:param name="root.filename" select="'default'"/>  
  <xsl:param name="html.ext" select="'.aspx'"/>

</xsl:stylesheet>

If I pull the lines for chunk-common.xsl and chunk-code.xsl, the first line of the HTML output is:

<% <at>   Page language="VB" AutoEventWireup="false" MasterPageFile="~/FANUCRoboticsMasterPageMeta.master"%>

IF I put the lines for chunk-common.xsl and chunk-code.xsl back in, the first line of the HTML output is:

(Continue reading)

Dave Pawson | 1 Sep 2010 08:40
Picon

Re: Re: Including <b> and <i> in XHTML stylesheets

On Tue, 31 Aug 2010 14:28:44 -0700
"Bob Stayton" <bobs <at> sagehill.net> wrote:

> I wonder if anyone is using b and i in selectors in CSS?  Such
> selectors would have to be enhanced to include the new element names.
> 
> Bob Stayton

I'd struggle to find a use for CSS when both b and i are styles anyway?

-- 

regards 

--

-- 
Dave Pawson
XSLT XSL-FO FAQ.
http://www.dpawson.co.uk
Jirka Kosek | 1 Sep 2010 09:35
Picon
Favicon
Gravatar

Re: Re: Including <b> and <i> in XHTML stylesheets

Keith Fahlgren wrote:
> As you've argued in the past, we don't have HTML5 stylsheets at this
> time.  As for <b> & <i>, "their use is discouraged in favor of style
> sheets." We already use strong and em for emphasis, so the remaining
> font elements are purely presentational and make it more difficult to
> style DocBook (X)HTML output using CSS.

Personally I don't care whether stylesheets will emit <b>/<i> or
<strong>/<em>. But from CSS point of view these elements could be styled
equally well.

IMHO if you generate HTML from semantically rich markup as DocBook you
are using HTML as purely presentational markup.

				Jirka

--

-- 
------------------------------------------------------------------
  Jirka Kosek      e-mail: jirka <at> kosek.cz      http://xmlguru.cz
------------------------------------------------------------------
       Professional XML consulting and training services
  DocBook customization, custom XSLT/XSL-FO document processing
------------------------------------------------------------------
 OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 member
------------------------------------------------------------------

Daniel Leidert | 1 Sep 2010 10:40
Picon

Re: Re: Including <b> and <i> in XHTML stylesheets

Jirka Kosek wrote:
> Keith Fahlgren wrote:
> > As you've argued in the past, we don't have HTML5 stylsheets at this
> > time.  As for <b> & <i>, "their use is discouraged in favor of style
> > sheets." We already use strong and em for emphasis, so the remaining
> > font elements are purely presentational and make it more difficult to
> > style DocBook (X)HTML output using CSS.
> 
> Personally I don't care whether stylesheets will emit <b>/<i> or
> <strong>/<em>. But from CSS point of view these elements could be styled
> equally well.

Why? <b> and <i> are presentation markup. Of course you *can* style
<i> as bold and <b> as italic. But this is definitly not intentional.
Whereas <em> and <strong> are content markup and you can style them
in every way you want (JFTR: ditto for <s>/<strike> and <del>).

I would definitely prefer to have docbook-xsl output clean content
markup and leave any details of presentation up to the user. In my
experience, you can really concentrate on content markup (by using
container elements) without limiting styling/presentation possibilities.

> IMHO if you generate HTML from semantically rich markup as DocBook you
> are using HTML as purely presentational markup.

I disagree. Transforming from one to another format shouldn't remove
nor reduce the semantics. (X)HTML is a semantically rich markup too.
Keep the semantics in a clean markup and let the user care about the
presentation (of course provide ready-to-use templates, CSS files, ..).

(Continue reading)

Rowland, Larry | 1 Sep 2010 15:58
Picon
Favicon

RE: Re: Including <b> and <i> in XHTML stylesheets

There are accessibility guidelines that recommend using semantically
appropriate markup such as <em> and <strong> instead of representational
markup such as <b> and <i>.

Regards,
Larry


=======================================================================
[ Larry Rowland             | If you want to build a ship, don't drum ]  
[ ESS/ATG                   | up the men to gather the wood, divide   ]
[ Hewlett-Packard           | the work, and give orders. Instead,     ]
[ 3404 East Harmony Road    | teach them to yearn for the vast and    ]
[ Fort Collins, CO  80528   | endless sea. - Antoine de Saint Exupery ]
[ Phone: 970/898-2280       +-----------------------------------------]
[ E-Mail:larry.rowland <at> .hp.com                                        ]
=======================================================================  


-----Original Message-----
From: Jirka Kosek [mailto:jirka <at> kosek.cz] 
Sent: Wednesday, September 01, 2010 1:36 AM
To: Keith Fahlgren
Cc: DocBook Apps ML
Subject: Re: [docbook-apps] Re: Including <b> and <i> in XHTML stylesheets

Keith Fahlgren wrote:
> As you've argued in the past, we don't have HTML5 stylsheets at this
> time.  As for <b> & <i>, "their use is discouraged in favor of style
> sheets." We already use strong and em for emphasis, so the remaining
(Continue reading)

Jeff Hooker | 1 Sep 2010 19:22

result-document() replacing chunking?

Hi all,

 

Are there any efforts underway to replace the chunking mechanism using in the Norm Walsh docbook xsl with updated scripts using result-document()?

 

I suppose the real question is “is anybody porting the publishing scripts to XSLT 2.0?”

 

My CMS can handle result-document(), but the chunking mechanism baffles it. Looking at a rather large rewrite.

 

Thanks,

Jeff.

honyk | 1 Sep 2010 20:10
Picon

RE: [PDF] Bookmarks - add index groups

Hello Guys,

thanks for your useful hints, it is working now!

Some details for future followers...

I've modified templates which match 'indexterm' in modes 'index-div-basic' and 'index-symbol-div'
placing the id attribute on the block element (to create an anchor):

<fo:block id="id{$key}">

Into the bookmark processing code (mode="xep.outline") I've added another branching:
<xsl:when test="self::index">
  <rx:bookmark internal-destination="{$id}">
    <rx:bookmark-label>
       <xsl:value-of select="normalize-space($bookmark-label)"/>
    </rx:bookmark-label>
    <xsl:apply-templates select="." mode="xep.outline.index"/>
  </rx:bookmark>
</xsl:when>

which calls the following template

   <xsl:template match="index" mode="xep.outline.index">

      <xsl:param name="scope" select="(ancestor::book|/)[last()]"/>

      <xsl:variable name="role">
         <xsl:if test="$index.on.role != 0">
            <xsl:value-of select=" <at> role"/>
         </xsl:if>
      </xsl:variable>

      <xsl:variable name="type">
         <xsl:if test="$index.on.type != 0">
            <xsl:value-of select=" <at> type"/>
         </xsl:if>
      </xsl:variable>

      <xsl:variable name="terms"
         select="//indexterm
                        [count(.|key('letter',
                          translate(substring(&primary;, 1, 1),
                             &lowercase;,
                             &uppercase;))
                          [&scope;][1]) = 1
                          and not( <at> class = 'endofrange')]"/>

      <xsl:variable name="alphabetical"
         select="$terms[contains(concat(&lowercase;, &uppercase;),
                substring(&primary;, 1, 1))]"/>

      <xsl:for-each select="$alphabetical">
         <xsl:sort select="substring(&primary;, 1, 1)"/>
         <xsl:variable name="label">
            <xsl:call-template name="string.upper">
               <xsl:with-param name="string"
                  select="substring(&primary;, 1, 1)"/>
            </xsl:call-template>
         </xsl:variable>
         <rx:bookmark internal-destination="id{$label}">
            <rx:bookmark-label>
               <xsl:value-of select="$label"/>
            </rx:bookmark-label>
         </rx:bookmark>
      </xsl:for-each>

   </xsl:template>

The latter code requires placing special entities (/common/entities.ent) into the XSLT file:
<!DOCTYPE xsl:stylesheet [
<!ENTITY % common.entities SYSTEM "path to common entities ">
%common.entities;
]>

That's it.

Thanks once again.

Jan

> Bob Stayton wrote:
> 
> > The tricky part is determining which letters actually have entries in
> > the current index, so you don't create bookmark links to non-existant
> > index sections.  I don't have a quick solution for that one.
> 
> I think that code from autoidx.xsl can be reused, namely from
> generate-basic-template. For example following code will populate
> variable $alphabetical with exactly one indexterm for each letter.
> 
>   <xsl:variable name="terms"
>                 select="//indexterm
>                         [count(.|key('letter',
>                           translate(substring(&primary;, 1, 1),
>                              &lowercase;,
>                              &uppercase;))
>                           [&scope;][1]) = 1
>                           and not( <at> class = 'endofrange')]"/>
> 
>   <xsl:variable name="alphabetical"
>                 select="$terms[contains(concat(&lowercase;,
> &uppercase;),
>                                         substring(&primary;, 1, 1))]"/>
> 
> So in order to get just letters something like the following code could
> be used:
> 
> <xsl:for-each select="$alphabetical">
>   <rx:bookmark-label>
>     <xsl:value-of select="substring(&primary;, 1, 1)"/
>   </rx:bookmark-label>
> </xsl:for-each>
> 
> 				Jirka
Cramer, David W (David | 1 Sep 2010 20:36

RE: [PDF] Bookmarks - add index groups

Thanks for posting the details Jan. I've added a feature request linking back to this post. I think it would
be a nice addition to the base xsls:
https://sourceforge.net/tracker/index.php?func=detail&aid=3057673&group_id=21935&atid=373750


David

-----Original Message-----
From: honyk [mailto:j.tosovsky <at> email.cz] 
Sent: Wednesday, September 01, 2010 1:10 PM
To: 'Jirka Kosek'; 'Bob Stayton'
Cc: docbook-apps <at> lists.oasis-open.org
Subject: RE: [docbook-apps] [PDF] Bookmarks - add index groups

Hello Guys,

thanks for your useful hints, it is working now!

Some details for future followers...

I've modified templates which match 'indexterm' in modes 'index-div-basic' and 'index-symbol-div'
placing the id attribute on the block element (to create an anchor):

<fo:block id="id{$key}">

Into the bookmark processing code (mode="xep.outline") I've added another branching:
<xsl:when test="self::index">
  <rx:bookmark internal-destination="{$id}">
    <rx:bookmark-label>
       <xsl:value-of select="normalize-space($bookmark-label)"/>
    </rx:bookmark-label>
    <xsl:apply-templates select="." mode="xep.outline.index"/>
  </rx:bookmark>
</xsl:when>

which calls the following template

   <xsl:template match="index" mode="xep.outline.index">

      <xsl:param name="scope" select="(ancestor::book|/)[last()]"/>

      <xsl:variable name="role">
         <xsl:if test="$index.on.role != 0">
            <xsl:value-of select=" <at> role"/>
         </xsl:if>
      </xsl:variable>

      <xsl:variable name="type">
         <xsl:if test="$index.on.type != 0">
            <xsl:value-of select=" <at> type"/>
         </xsl:if>
      </xsl:variable>

      <xsl:variable name="terms"
         select="//indexterm
                        [count(.|key('letter',
                          translate(substring(&primary;, 1, 1),
                             &lowercase;,
                             &uppercase;))
                          [&scope;][1]) = 1
                          and not( <at> class = 'endofrange')]"/>

      <xsl:variable name="alphabetical"
         select="$terms[contains(concat(&lowercase;, &uppercase;),
                substring(&primary;, 1, 1))]"/>

      <xsl:for-each select="$alphabetical">
         <xsl:sort select="substring(&primary;, 1, 1)"/>
         <xsl:variable name="label">
            <xsl:call-template name="string.upper">
               <xsl:with-param name="string"
                  select="substring(&primary;, 1, 1)"/>
            </xsl:call-template>
         </xsl:variable>
         <rx:bookmark internal-destination="id{$label}">
            <rx:bookmark-label>
               <xsl:value-of select="$label"/>
            </rx:bookmark-label>
         </rx:bookmark>
      </xsl:for-each>

   </xsl:template>

The latter code requires placing special entities (/common/entities.ent) into the XSLT file:
<!DOCTYPE xsl:stylesheet [
<!ENTITY % common.entities SYSTEM "path to common entities ">
%common.entities;
]>

That's it.

Thanks once again.

Jan

> Bob Stayton wrote:
> 
> > The tricky part is determining which letters actually have entries in
> > the current index, so you don't create bookmark links to non-existant
> > index sections.  I don't have a quick solution for that one.
> 
> I think that code from autoidx.xsl can be reused, namely from
> generate-basic-template. For example following code will populate
> variable $alphabetical with exactly one indexterm for each letter.
> 
>   <xsl:variable name="terms"
>                 select="//indexterm
>                         [count(.|key('letter',
>                           translate(substring(&primary;, 1, 1),
>                              &lowercase;,
>                              &uppercase;))
>                           [&scope;][1]) = 1
>                           and not( <at> class = 'endofrange')]"/>
> 
>   <xsl:variable name="alphabetical"
>                 select="$terms[contains(concat(&lowercase;,
> &uppercase;),
>                                         substring(&primary;, 1, 1))]"/>
> 
> So in order to get just letters something like the following code could
> be used:
> 
> <xsl:for-each select="$alphabetical">
>   <rx:bookmark-label>
>     <xsl:value-of select="substring(&primary;, 1, 1)"/
>   </rx:bookmark-label>
> </xsl:for-each>
> 
> 				Jirka


---------------------------------------------------------------------
To unsubscribe, e-mail: docbook-apps-unsubscribe <at> lists.oasis-open.org
For additional commands, e-mail: docbook-apps-help <at> lists.oasis-open.org

Jirka Kosek | 2 Sep 2010 00:01
Picon
Favicon
Gravatar

Re: result-document() replacing chunking?

Jeff Hooker wrote:

> I suppose the real question is "is anybody porting the publishing
> scripts to XSLT 2.0?"

Yes. See

http://github.com/docbook/xslt20-stylesheets

HTML support is quite complete thanks to Norm. I have improved FO output
during summer but it is not yet complete. Any feedback welcomed.

				Jirka

--

-- 
------------------------------------------------------------------
  Jirka Kosek      e-mail: jirka <at> kosek.cz      http://xmlguru.cz
------------------------------------------------------------------
       Professional XML consulting and training services
  DocBook customization, custom XSLT/XSL-FO document processing
------------------------------------------------------------------
 OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 member
------------------------------------------------------------------

Peter Desjardins | 2 Sep 2010 01:04
Picon

Can XOM's XIncludeDriver use an XML catalog?

Hi.

I'm trying to use XInclude from the XOM package
(http://www.ibiblio.org/xml/XOM/) to resolve xi:includes. Sometimes it
works perfectly. I'm seeing frequent intermittent failures to resolve
my documents because XInclude can't access DTD components on the
Internet.

I am invoking XInclude as shown in Bob Stayton's book
(http://www.sagehill.net/docbookxsl/Xinclude.html#JavaXIncludes). Is
there a way to configure the class to use an XML catalog? I've got one
set up for use with Saxon and the DocBook XSL stylesheets.

Here's the command I am giving to XInclude:

    java \
        nu.xom.samples.XIncludeDriver \
        source/${FILE_NAME}/${FILE_NAME}.xml  >
source/${FILE_NAME}/${FILE_NAME}.resolved.xml

I've pasted the error I'm seeing at the bottom of this message. I have
a script that resolves five documents. Different documents encounter
this problem each time I run it. The errors complain about different
files also.

Thanks for your help.

Peter

java.io.IOException: Server returned HTTP response code: 403 for URL:
http://www.oasis-open.org/docb
ook/xml/4.5/ent/isoamsr.ent
java.io.IOException: Server returned HTTP response code: 403 for URL:
http://www.oasis-open.org/docb
ook/xml/4.5/ent/isoamsr.ent
        at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown
Source)
        at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.setupCurrentEntity(Unknown
Sourc
e)
        at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.startEntity(Unknown
Source)
        at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.startEntity(Unknown
Source)
        at com.sun.org.apache.xerces.internal.impl.XMLDTDScannerImpl.startPE(Unknown
Source)
        at com.sun.org.apache.xerces.internal.impl.XMLDTDScannerImpl.skipSeparator(Unknown
Source)
        at com.sun.org.apache.xerces.internal.impl.XMLDTDScannerImpl.scanDecls(Unknown
Source)
        at com.sun.org.apache.xerces.internal.impl.XMLDTDScannerImpl.scanDTDExternalSubset(Unknown
S
ource)
        at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$DTDDriver.dispatch(Unknown
 Source)
        at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$DTDDriver.next(Unknown
Sou
rce)
        at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$PrologDriver.next(Unknown
Source)
        at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(Unknown
Source)
        at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unkno
wn Source)
        at com.sun.org.apache.xerces.internal.parsers.DTDConfiguration.parse(Unknown
Source)
        at com.sun.org.apache.xerces.internal.parsers.DTDConfiguration.parse(Unknown
Source)
        at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(Unknown
Source)
        at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(Unknown
Source)
        at nu.xom.Builder.build(Unknown Source)
        at nu.xom.Builder.build(Unknown Source)
        at nu.xom.xinclude.XIncluder.downloadXMLDocument(Unknown Source)
        at nu.xom.xinclude.XIncluder.resolve(Unknown Source)
        at nu.xom.xinclude.XIncluder.resolve(Unknown Source)
        at nu.xom.xinclude.XIncluder.resolve(Unknown Source)
        at nu.xom.xinclude.XIncluder.resolve(Unknown Source)
        at nu.xom.xinclude.XIncluder.resolve(Unknown Source)
        at nu.xom.xinclude.XIncluder.resolve(Unknown Source)
        at nu.xom.xinclude.XIncluder.resolveInPlace(Unknown Source)
        at nu.xom.xinclude.XIncluder.resolveInPlace(Unknown Source)
        at nu.xom.xinclude.XIncluder.resolveInPlace(Unknown Source)
        at nu.xom.samples.XIncludeDriver.main(Unknown Source)

Gmane