RE: Feature Request: assign serialization options dynamically

Hi James,

Cheers for letting me know: I was already aware of this option, which I think will fit with my current issue.  I was more concerned that there wasn't a way to pass serialized xml (with dynamically assigned options) out of an xproc pipeline, e.g. to a content management system or xml database.

In my case, I've defined a pipeline which takes a URL and uses text based processing to pull DTD declaration information out and output it as a c:param-set.  I can pass it out to  p:store (or any other pipeline) then as required.

Thanks,
Tom 

> -----Original Message-----
> From: James Sulak [mailto:jsulak@gmail.com] 
> Sent: 14 April 2010 14:33
> To: HILLMAN, Tomos
> Cc: xproc-dev@w3.org
> Subject: Re: Feature Request: assign serialization options dynamically
> 
> Hi Tomos,
> 
> This may not solve your specific problem, but one way to 
> accomplish that right now is to use <p:store> with 
> <p:with-option />s to dynamically set the public and system 
> identifiers. (Of course, like Vojtech mentioned, this won't 
> work if you don't actually want to store the document to disk).
> 
> I've run into the same problem you have, and to get around 
> it, I use an XML table mapping DITA-like @class attributes to 
> DTDs, which allows me to handle different document types in 
> the same pipeline:
> 
> The table (doctype_derivation.xml):
> 
> <derivations>
>     <derivation>
>         <class>codebook/codeblock</class>
>         <system-id>codebook.dtd</system-id>
>         <public-id>-//DTD CodeBook v0.1//EN</public-id>
>     </derivation>
>     <derivation>
>         <class>commbook/commblock</class>
>         <system-id>commbook.dtd</system-id>
>         <public-id>-//DTD CommBook V0.1//EN</public-id>
>     </derivation>
> </derivations>
> 
> The pipeline:
> 
>     <!-- Get the class attribute from the root element -->
>     <p:variable name="class" select="/*/@class"/>
> 
>     <!-- Get the derivation table -->
>     <p:identity name="get_derivation">
>         <p:input port="source">
>             <p:document href="doctype_derivation.xml"/>
>         </p:input>
>     </p:identity>
> 
> ...... (pipeline logic) .....
> 
>   <!-- Store the document with the appropriate DTD -->
>   <p:store omit-xml-declaration="false" method="xml" encoding="utf-8">
>         <p:with-option name="href" select="$href" />
>         <p:with-option name="doctype-public"
> select="//derivation[contains($class, class)]/public-id">
>             <p:pipe port="result" step="get_derivation"/>
>         </p:with-option>
>         <p:with-option name="doctype-system"
> select="//derivation[contains($class, class)]/system-id">
>             <p:pipe port="result" step="get_derivation"/>
>         </p:with-option>
>     </p:store>
> 
> This approach might work for you if there's some reliable way 
> to dynamically identify your documents' doctypes from the XML 
> content itself.
> 
> Hope this helps,
> 
> -James
> 
> 
> On Wed, Apr 14, 2010 at 7:28 AM, HILLMAN, Tomos 
> <tomos.hillman@oup.com> wrote:
> > Hi List,
> >
> > I hope this is the right place to suggest new features, and 
> that feature requests are accepted at this stage in the 
> process; this is in partial response to the thread earlier 
> this week 'Specifying output in p:xslt'.
> >
> > My particular example of needing this feature was applying 
> a single pipeline to a set of documents belonging to several 
> different but related data models.  One requirement of the 
> process is to output serialized XML with appropriate public 
> and system DTD identifiers.
> >
> > Perhaps a parameter port on the p:serialization pipeline 
> would allow for decent system for this?
> >
> > T
> > Oxford University Press (UK) Disclaimer
> >
> > This message is confidential. You should not copy it or 
> disclose its contents to anyone. You may use and apply the 
> information for the intended purpose only. OUP does not 
> accept legal responsibility for the contents of this message. 
> Any views or opinions presented are those of the author only 
> and not of OUP. If this email has come to you in error, 
> please delete it, along with any attachments. Please note 
> that OUP may intercept incoming and outgoing email communications.
> >
> >
> 
Oxford University Press (UK) Disclaimer

This message is confidential. You should not copy it or disclose its contents to anyone. You may use and apply the information for the intended purpose only. OUP does not accept legal responsibility for the contents of this message. Any views or opinions presented are those of the author only and not of OUP. If this email has come to you in error, please delete it, along with any attachments. Please note that OUP may intercept incoming and outgoing email communications.

Received on Wednesday, 14 April 2010 14:11:01 UTC