Problem with DocBook 4.x stylesheet customizations

Hi,

I have noticed that for some time oXygen is now shipping with namespaced
DocBook stylesheets. This is just fine, but problem is that
frameworks/docbook/catalog.xml contains the following rule:

 <rewriteURI
    uriStartString="http://docbook.sourceforge.net/release/xsl/current/"
    rewritePrefix="xsl/"/>

This rule will cause import of namespaced stylesheets into
customizations layers written against original non-namespaced
stylesheets. As such customization layers do not reference DocBook
elements in namespace result is mangled output.

Would it be possible to either drop this entry completely from XML
catalog or to ship oXygen with both namespaced and non-namespaced
stylesheets?

Thanks,

				Jirka

--

-- 
------------------------------------------------------------------
  Jirka Kosek      e-mail: jirka@...      http://xmlguru.cz
------------------------------------------------------------------
       Professional XML consulting and training services
  DocBook customization, custom XSLT/XSL-FO document processing
------------------------------------------------------------------

Re: no luck with xproc scenario

Hi Christian,

There is no support for using variables for the input bindings, sorry 
about the documentation/feature missmatch. We already fixed this in the 
current development adding support for editor variables when you specify 
the input bindings.
Actually the XProc scenarios support will be improved in oXygen 11.1 as 
we already added support for specifying parameters and options.

The ${cfn} stands for current file name and it is computed depending on 
whatever the current file is. If the selected editor is an XProc file 
then that will contain that file name. Please note that one of the 
interesting improvements in version 11 was that any type of scenario can 
be set for any file so you can set an XProc scenario for an XML file and 
then if you execute the transformation with that file as the current 
file then the ${cfn} variable will be expanded to that file filename.

Best Regards,
George
--

-- 
George Cristian Bina
<oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger
http://www.oxygenxml.com

Christian Wittern wrote:
> Hi there,
> 
> Today I got my first XProc file working and now I am struggling to drive it
> from oxygen.  What I would like to achieve is that the input and output
> files are taken from the environment in a similar way as the XSLT scenario

Re: Problem with DocBook 4.x stylesheet customizations

Hello,

That catalog entry should map the namespaced version of the stylesheets 
instead of the non namespaced version. Please replace the entry with:

    <rewriteURI 
uriStartString="http://docbook.sourceforge.net/release/xsl-ns/current/"
     rewritePrefix="xsl/"/>

We will correct the built-in XML catalog in the next version.

Regards,
Sorin

Jirka Kosek wrote:
> Hi,
> 
> I have noticed that for some time oXygen is now shipping with namespaced
> DocBook stylesheets. This is just fine, but problem is that
> frameworks/docbook/catalog.xml contains the following rule:
> 
>  <rewriteURI
>     uriStartString="http://docbook.sourceforge.net/release/xsl/current/"
>     rewritePrefix="xsl/"/>
> 
> This rule will cause import of namespaced stylesheets into
> customizations layers written against original non-namespaced
> stylesheets. As such customization layers do not reference DocBook
> elements in namespace result is mangled output.
> 

Re: no luck with xproc scenario

Dear George,

George Cristian Bina wrote:
> Hi Christian,
>
> There is no support for using variables for the input bindings, sorry 
> about the documentation/feature missmatch. We already fixed this in 
> the current development adding support for editor variables when you 
> specify the input bindings.
> Actually the XProc scenarios support will be improved in oXygen 11.1 
> as we already added support for specifying parameters and options.
I am looking forward to this, since the current way makes XProc more or 
less unusable.  Even if I call a XProc scenario from an XML file, there 
is no way that this scenario could pick up the current XML file as the 
input file.

>
> The ${cfn} stands for current file name and it is computed depending 
> on whatever the current file is. If the selected editor is an XProc 
> file then that will contain that file name. Please note that one of 
> the interesting improvements in version 11 was that any type of 
> scenario can be set for any file so you can set an XProc scenario for 
> an XML file and then if you execute the transformation with that file 
> as the current file then the ${cfn} variable will be expanded to that 
> file filename.
Right, this is what I would expect from the way the other scenarios 
behave.  But I experience the following:

I have a XProc scenario called md-db2xml.xpl.  In the input port, of 
that file, I am setting tthe XML file to JY006.xml.  Now I have that 

ISO Schematron not supported in NVDL

Hi,

it seems that although oXygen supports standalone and embedded ISO
Schematron it is not able to process ISO Schematron schemas referenced
from NVDL.

I'm getting the following error:

Engine name: Jing
Severity: error
Description: org.xml.sax.SAXParseException-no implementation available
for schema language with namespace URI
"http://purl.oclc.org/dsdl/schematron"

in oXygen 11.

				Jirka

--

-- 
------------------------------------------------------------------
  Jirka Kosek      e-mail: jirka@...      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
------------------------------------------------------------------

Re: ISO Schematron not supported in NVDL

Seconded. I get the same error, including using oXygen's jing from
the commandline. Reporting this is on my (long) things-to-do list --
thanks, Jirka!

> it seems that although oXygen supports standalone and embedded ISO
> Schematron it is not able to process ISO Schematron schemas
> referenced from NVDL.
> I'm getting the following error:
> Engine name: Jing
> Severity: error
> Description: org.xml.sax.SAXParseException-no implementation available
> for schema language with namespace URI
> "http://purl.oclc.org/dsdl/schematron"
> in oXygen 11.

Re: ISO Schematron not supported in NVDL

Syd Bauman wrote:
> Seconded. I get the same error, including using oXygen's jing from
> the commandline. Reporting this is on my (long) things-to-do list --
> thanks, Jirka!

The cause is probably in fact that for standalone Schematron validation
oXygen uses his own transformation through XSLT 2.0. But Jing uses
different code base for this and there is probably still old code from
James Clark supporting only Schematron 1.x.

But if you want to use ISO Schematron from NVDL right now, you can use
JNVDL:

http://jnvdl.sourceforge.net/

			Jirka

--

-- 
------------------------------------------------------------------
  Jirka Kosek      e-mail: jirka@...      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
------------------------------------------------------------------

_______________________________________________

Setting output file name

I'm generating PDFs using the default/demo PDF generator in Oxygen
10.x on Vista and using a bookmap and a dita map.

I'm looking for a way to set the output file name explicitly --
currently the ditamap/bookmap I'm using becomes the output file name.

I've looked through help and through the demo transforms, but I'm not
finding this. I see that I can do this for PS, HTML, or TXT output.

Is there a way to explicitly set the file name in Oxygen 10.x / DITA?

Re: ISO Schematron not supported in NVDL

Hi Jirka, Syd,

Indeed, for NVDL oXygen uses Jing now as I moved the NVDL support from 
oNVDL to Jing. James started to work at some moment on ISO Schematron 
support but there is no progress in the last months. I also started some 
time ago in oNVDL to add support for ISO Schematron but that was not 
finalized. Probably the best thing will be to get as many votes as 
possible on the ISO Schematron issue from the jing-trang project, just 
sign in and star the issue:

http://code.google.com/p/jing-trang/issues/detail?id=23

Best Regards,
George
--

-- 
George Cristian Bina
<oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger
http://www.oxygenxml.com

Jirka Kosek wrote:
> Syd Bauman wrote:
>> Seconded. I get the same error, including using oXygen's jing from
>> the commandline. Reporting this is on my (long) things-to-do list --
>> thanks, Jirka!
> 
> The cause is probably in fact that for standalone Schematron validation
> oXygen uses his own transformation through XSLT 2.0. But Jing uses
> different code base for this and there is probably still old code from
> James Clark supporting only Schematron 1.x.
> 

Re: no luck with xproc scenario

Dear Christian,

Thanks! We fixed this issue today and it will be available in 11.1. 
Version 11.1 is planned for December but we probably will make a beta 
available a few weeks before the release.

Best Regards,
George
-- 
George Cristian Bina
<oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger
http://www.oxygenxml.com

Christian Wittern wrote:
> Dear George,
> 
> George Cristian Bina wrote:
>> Hi Christian,
>>
>> There is no support for using variables for the input bindings, sorry 
>> about the documentation/feature missmatch. We already fixed this in 
>> the current development adding support for editor variables when you 
>> specify the input bindings.
>> Actually the XProc scenarios support will be improved in oXygen 11.1 
>> as we already added support for specifying parameters and options.
> I am looking forward to this, since the current way makes XProc more or 
> less unusable.  Even if I call a XProc scenario from an XML file, there 
> is no way that this scenario could pick up the current XML file as the 
> input file.
>