I haven’t addressed the fo templates yet. I probably won’t be able to get to it once August hits, so will try to address them this week. Yes, the stylesheets do try to put the Dublin Core elements and attributes in the HTML <meta> tags: <!-- Dublin Core metadata --> <xsl:template name = head.content.abstract > <xsl:param name = node select = . /> <xsl:variable name = info select = (d:articleinfo d:bookinfo d:prefaceinfo d:chapterinfo d:appendixinfo d:sectioninfo d:sect1info d:sect2info d:sect3info d:sect4info d:sect5info d:referenceinfo d:refentryinfo d:partinfo d:info d:docinfo)[1] /> <xsl:if test = $info and $info/d:abstract > <meta name = description > <xsl:attribute name = content > <xsl:for-each select = $info/d:abstract[1]/* > <xsl:value-of select = normalize-space(.) /> <xsl:if test = position() < last() > <xsl:text> </xsl:text> </xsl:if> </xsl:for-each> </xsl:attribute> </meta> </xsl:if> <link rel = schema.DC href =
http://purl.org/dc/terms/ /> <xsl:if test = $info and $info/dc:* > <xsl:for-each select = $info/dc:* > <meta> <xsl:attribute name = name > DC. <xsl:value-of select = local-name(.) /> </xsl:attribute> <xsl:attribute name = content > <xsl:value-of select = normalize-space(.) /> </xsl:attribute> </meta> </xsl:for-each> </xsl:if> </xsl:template> Also, I have started to add this in the FO as well: … <xsl:call-template name = user.pagemasters /> </fo:layout-master-set> <xsl:if test = //d:info/dc:* > <fo:declarations> <x:xmpmeta xmlns:x = adobe:ns:meta/ > <rdf:RDF xmlns:rdf =
http://www.w3.org/1999/02/22-rdf-syntax-ns# > <rdf:Description rdf:about = xmlns:dc =
http://purl.org/dc/elements/1.1/ > <!-- Dublin Core properties go here --> <xsl:copy-of select = //d:info/dc:* /> </rdf:Description> <rdf:Description rdf:about = xmlns:xmp =
http://ns.adobe.com/xap/1.0/ > <!-- XMP properties go here --> <xmp:CreatorTool> <xsl:value-of select = substring-before(., '{DISTRONAME-VERSION}') /> <xsl:value-of select = concat($DistroName, '-', $VERSION) /> <xsl:value-of select = substring-after(., '{DISTRONAME-VERSION}') /> <xsl:text> </xsl:text> </xmp:CreatorTool> </rdf:Description> </rdf:RDF> </x:xmpmeta> </fo:declarations> </xsl:if> </xsl:template> Thanks and best regards, --Scott Scott Hudson PELCO by Schneider Electric United States Standards & Information Architect Phone: +1 970 282 1952 Mobile: +1 720 369 2433 Email:
scott.hudson@schneider-electric.com Sites: pdn.pelco.com , partnerfirst.pelco.com On Jul 23, 2014, at 12:45 PM, Bob Stayton <
bobs@sagehill.net > wrote: Good. That means we would only need to add the templates to the html directory and the fo directory. All the other output types are generated from them. Some of the others might need some tweaks, but we should try the snapshots with html and fo first, and then we can test the other outputs. Do you have fo templates for the Publishers elements yet? Also, are the default Publishers stylesheets doing anything with the Dublin Core elements and attributes? Bob Stayton Sagehill Enterprises
bobs@sagehill.net On 7/23/2014 9:43 AM, Hudson, Scott wrote: Hi Bob, I favor the second option as well. The templates would only trigger if the publishers elements were present. I think this makes it easier to distribute and render. AFAIK, there are no modifications to any content models (other than excluding technical elements). The exclusions would be handled at the schema level when validating the document, so should not affect stylesheet processing. Thanks and best regards, --Scott *Scott Hudson* /PELCO/***by Schneider Electric* *United States * *Standards & Information Architect** Phone:*+1 970 282 1952 *Mobile:*+1 720 369 2433 *Email:*_
scott.hudson@schneider-electric.com _ *Sites:* pdn.pelco.com <
http://pdn.pelco.com > , partnerfirst.pelco.com <
http://partnerfirst.pelco.com > On Jul 23, 2014, at 10:38 AM, Bob Stayton <
bobs@sagehill.net < mailto:
bobs@sagehill.net >> wrote: Hi Scott, I thought a bit about how to integrate Publishers into the DocBook XSL distro. I think there are two approaches: 1. Create a Publishers customization layer for each output. 2. Integrate the Publishers elements into the base stylesheets. The first choice would continue what we started with epub3, but extend it to all the DocBook XSL output types, of which there are many. These would likely be packaged separately from the stock stylesheets, because they would parallel the existing directory structure. A user would install both if they needed to process Publishers documents. The second choice adds templates for the new Publishers elements to the base stylesheets. There would be no customizations or separate files for Publishers. Rather, the collection of templates in DocBook XSL would be extended to include Publishers. Because XSL is driven by the elements being processed, such templates would only be used by Publishers documents. A single distro handles all. I favor the second choice because it eliminates extra packages and simplifies ongoing maintenance. It would also make personal customizations easier for our users. The question is, will this work? I've looked at the Publishers schema and stylesheet, and I think supersetting DocBook XSL would work, because Publishers mostly adds elements and attributes (add new templates) or removes elements (ignore existing templates). Does Publishers *alter* any content models in a way that such a scheme could not work? Or if it does, is there sufficient context to allow @match attributes to handle the differences? Bob Stayton Sagehill Enterprises
bobs@sagehill.net < mailto:
bobs@sagehill.net > On 7/17/2014 3:01 PM, Hudson, Scott wrote: You are the best, Bob! Thanks so much for taking the time on this. How do you want to handle adding these to the DocBook XSL tree? Would you prefer to contribute them? I don’t really want to break anything, since I don’t usually work in the DocBook XSL repo. I guess we still need to address xsl:fo, too… Thanks and best regards, --Scott *Scott Hudson* /PELCO/***by Schneider Electric* *United States * *Standards & Information Architect** Phone:*+1 970 282 1952 *Mobile:*+1 720 369 2433 *Email:*_
scott.hudson@schneider-electric.com _ *Sites:* pdn.pelco.com <
http://pdn.pelco.com > , partnerfirst.pelco.com <
http://partnerfirst.pelco.com > On Jul 17, 2014, at 3:54 PM, Bob Stayton <
bobs@sagehill.net < mailto:
bobs@sagehill.net >> wrote: Hi Scott, I took your publishers.xhtml.xsl stylesheet and made it into a customization for epub3 output. The main issue is managing import precedence, because the chunking process uses xsl:apply-imports to switch from chunking behavior to formating behavior. The attached zip file has the custom stylesheets, sample output, a sample Makefile, and a README that explains it. I copy the README below. Bob Stayton Sagehill Enterprises
bobs@sagehill.net < mailto:
bobs@sagehill.net > README DocBook Publishers EPUB3 customization --------------------------------------- 17 July 2014 Bob Stayton Sagehill Enterprises
bobs@sagehill.net This archive contains a customization of the DocBook Epub3 stylesheet for use with the DocBook Publishers schema. coriolan.xml - DocBook 5 input file with publisher elements publishers-chunk-epub3.xsl - Stylesheet to generate epub3 output. publishers-elements-epub3.xsl - Imported by publishers-chunk-epub3.xsl Makefile.publishers - Makefile showing processing steps. coriolan - Sample output directory. coriolan.epub - Sample output epub file. Notes ------------ Customizing any of the DocBook chunking stylesheets requires care to maintain proper import precedence. To generate chunked epub3 output, process the sample input file with the publishers-chunk-epub3.xsl stylesheet. You will have to modify the xsl:import statements so it can import the stock DocBook files. The publishers-chunk-epub3.xsl stylesheet does not contain any custom templates, except those that would customize the chunking behavior, which is rare. None are needed here. The publishers-chunk-epub3.xsl stylesheet imports the templates that format the content within each chunk. In this case, it imports the file publishers-elements-epub3.xsl. I moved your custom templates into publishers-elements-epub3.xsl. That file also imports the stock xhtml5/docbook.xsl, which elevates xhtml to xhtml5, and imports the stcok epub3/epub3-element-mods.xsl which elevates xhtml5 to epub3. Again, you'll need to change the xsl:import paths. These imports are followed by the templates that customize elements for the Publishers schema. I changed three of your templates to replace <div remap= > with <div class= > because remap is not a valid XHTML attribute, and epubcheck complained. I wasn't sure if you intended to output remap there. The Makefile I include here is mostly to demonstrate the commands I used to generate the coriolan.epub file. It should work for you too if you adjust the CLASSPATH and other command paths. Basically it does three things: 1. Process the input document with publishers-chunk-epub3.xsl. 2. Run a zip process to generate the .epub file. 3. Run epubcheck on the result. The coriolan.epub file that I generated opens and displays properly in Calibre. But it still does not pass epubcheck-3.0. That will require some more investigation. ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. ______________________________________________________________________<publishers-epub3-2014-07-17.zip> --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. ______________________________________________________________________ ______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. ______________________________________________________________________