Thread: [Xsltforms-support] CDATA in subforms
Brought to you by:
alain-couthures
Menu
▾
▴
xsltforms-support
|
From: Tim T. <tim...@gm...> - 2015-07-05 02:10:54
|
Alain, I am trying to load a subform that contains a <script type="text/turtle"> tag with RDF data serialized as Turtle. This data is enclosed in a CDATA section (per http://www.w3.org/TR/turtle/#h3_xhtml). However, when I load the subform (as XHTML), the CDATA is ignored and all <> characters are escaped, which causes the Turtle parser I am using to break. Shouldn't CDATA contents be ignored when a subform is loaded? As a related question, does XSLTForms support the @cdata-section-elements attribute on <xf:submission>? I see some reference to it in the code, but wasn't sure whether it had been fully implemented. This could be very useful for dealing with non-XML formats in hybrid applications. Many thanks, Tim -- Tim A. Thompson Metadata Librarian (Spanish/Portuguese Specialty) Princeton University Library |
|
From: Alain C. <ala...@ag...> - 2015-07-06 17:08:55
|
Tim, XSLT does not preserve CDATA nodes but treats them into text nodes. It is still possible to treat script elements according to their type attributes. I can modified the XSLT stylesheet accordingly: for "text/javascript", the script value can be encapsulated with "/* <![CDATA[ */" and "/* ]]> */", and, for "text/turtle", with "# <![CDATA[" and "# ]]>". What do you think? For submission, adding support for @cdata-section-elements is not difficult for non-IE browsers because serialization is performed with Javascript instructions. For IE, because serialization is still based on an XSLT transformation, the stylesheet source would have to be adapted according to @cdata-section-elements value. Do you already need this? --Alain Le 05/07/2015 04:10, Tim Thompson a écrit : > Alain, > > I am trying to load a subform that contains a <script > type="text/turtle"> tag with RDF data serialized as Turtle. > > This data is enclosed in a CDATA section (per > http://www.w3.org/TR/turtle/#h3_xhtml). However, when I load the > subform (as XHTML), the CDATA is ignored and all <> characters are > escaped, which causes the Turtle parser I am using to break. Shouldn't > CDATA contents be ignored when a subform is loaded? > > As a related question, does XSLTForms support the > @cdata-section-elements attribute on <xf:submission>? I see some > reference to it in the code, but wasn't sure whether it had been fully > implemented. This could be very useful for dealing with non-XML > formats in hybrid applications. > > Many thanks, > Tim > > -- > Tim A. Thompson > Metadata Librarian (Spanish/Portuguese Specialty) > Princeton University Library > > > ------------------------------------------------------------------------------ > Don't Limit Your Business. Reach for the Cloud. > GigeNET's Cloud Solutions provide you with the tools and support that > you need to offload your IT needs and focus on growing your business. > Configured For All Businesses. Start Your Cloud Today. > https://www.gigenetcloud.com/ > > > _______________________________________________ > Xsltforms-support mailing list > Xsl...@li... > https://lists.sourceforge.net/lists/listinfo/xsltforms-support |
|
From: Tim T. <tim...@gm...> - 2015-07-06 18:01:00
|
Alain, I think adding the proposed CDATA encapsulations to script elements would be a great solution. Regarding @cdata-section-elements, I do need this functionality, in some form, for the application I'm working on. But my first preference would be to output the CDATA sections on the server using XQuery. Unfortunately, eXist does not currently support cdata-section-elements as a serialization parameter either, so I was considering the @cdata-section-elements submission attribute as a temporary workaround. I do think this would be a good feature to have, but for now, just adding the CDATA encapsulations would make a big difference. Thanks again! Tim -- Tim A. Thompson Metadata Librarian (Spanish/Portuguese Specialty) Princeton University Library On Mon, Jul 6, 2015 at 1:08 PM, Alain Couthures < ala...@ag...> wrote: > Tim, > > XSLT does not preserve CDATA nodes but treats them into text nodes. It is > still possible to treat script elements according to their type attributes. > I can modified the XSLT stylesheet accordingly: for "text/javascript", the > script value can be encapsulated with "/* <![CDATA[ */" and "/* ]]> */", > and, for "text/turtle", with "# <![CDATA[" and "# ]]>". What do you think? > > For submission, adding support for @cdata-section-elements is not > difficult for non-IE browsers because serialization is performed with > Javascript instructions. For IE, because serialization is still based on an > XSLT transformation, the stylesheet source would have to be adapted > according to @cdata-section-elements value. Do you already need this? > > --Alain > > > Le 05/07/2015 04:10, Tim Thompson a écrit : > > Alain, > > I am trying to load a subform that contains a <script type="text/turtle"> > tag with RDF data serialized as Turtle. > > This data is enclosed in a CDATA section (per > <http://www.w3.org/TR/turtle/#h3_xhtml> > http://www.w3.org/TR/turtle/#h3_xhtml). However, when I load the subform > (as XHTML), the CDATA is ignored and all <> characters are escaped, which > causes the Turtle parser I am using to break. Shouldn't CDATA contents be > ignored when a subform is loaded? > > As a related question, does XSLTForms support the @cdata-section-elements > attribute on <xf:submission>? I see some reference to it in the code, but > wasn't sure whether it had been fully implemented. This could be very > useful for dealing with non-XML formats in hybrid applications. > > Many thanks, > Tim > > -- > Tim A. Thompson > Metadata Librarian (Spanish/Portuguese Specialty) > Princeton University Library > > > ------------------------------------------------------------------------------ > Don't Limit Your Business. Reach for the Cloud. > GigeNET's Cloud Solutions provide you with the tools and support that > you need to offload your IT needs and focus on growing your business. > Configured For All Businesses. Start Your Cloud Today.https://www.gigenetcloud.com/ > > > > _______________________________________________ > Xsltforms-support mailing lis...@li...://lists.sourceforge.net/lists/listinfo/xsltforms-support > > > |
|
From: Alain C. <ala...@ag...> - 2015-07-07 19:24:11
|
Tim,
I have now committed CDATA support:
* script content is "escaped" with CDATA for "text/javascript" and
"text/turtle"
* @cdata-section-elements in submission is supported for all major
browsers
Thank you for your feedback!
--Alain
Le 06/07/2015 20:00, Tim Thompson a écrit :
> Alain,
>
> I think adding the proposed CDATA encapsulations to script elements
> would be a great solution.
>
> Regarding @cdata-section-elements, I do need this functionality, in
> some form, for the application I'm working on. But my first preference
> would be to output the CDATA sections on the server using XQuery.
> Unfortunately, eXist does not currently support cdata-section-elements
> as a serialization parameter either, so I was considering the
> @cdata-section-elements submission attribute as a temporary
> workaround. I do think this would be a good feature to have, but for
> now, just adding the CDATA encapsulations would make a big difference.
>
> Thanks again!
> Tim
>
>
> --
> Tim A. Thompson
> Metadata Librarian (Spanish/Portuguese Specialty)
> Princeton University Library
>
>
> On Mon, Jul 6, 2015 at 1:08 PM, Alain Couthures
> <ala...@ag... <mailto:ala...@ag...>>
> wrote:
>
> Tim,
>
> XSLT does not preserve CDATA nodes but treats them into text
> nodes. It is still possible to treat script elements according to
> their type attributes. I can modified the XSLT stylesheet
> accordingly: for "text/javascript", the script value can be
> encapsulated with "/* <![CDATA[ */" and "/* ]]> */", and, for
> "text/turtle", with "# <![CDATA[" and "# ]]>". What do you think?
>
> For submission, adding support for @cdata-section-elements is not
> difficult for non-IE browsers because serialization is performed
> with Javascript instructions. For IE, because serialization is
> still based on an XSLT transformation, the stylesheet source would
> have to be adapted according to @cdata-section-elements value. Do
> you already need this?
>
> --Alain
>
>
> Le 05/07/2015 04:10, Tim Thompson a écrit :
>> Alain,
>>
>> I am trying to load a subform that contains a <script
>> type="text/turtle"> tag with RDF data serialized as Turtle.
>>
>> This data is enclosed in a CDATA section (per
>> http://www.w3.org/TR/turtle/#h3_xhtml). However, when I load the
>> subform (as XHTML), the CDATA is ignored and all <> characters
>> are escaped, which causes the Turtle parser I am using to break.
>> Shouldn't CDATA contents be ignored when a subform is loaded?
>>
>> As a related question, does XSLTForms support the
>> @cdata-section-elements attribute on <xf:submission>? I see some
>> reference to it in the code, but wasn't sure whether it had been
>> fully implemented. This could be very useful for dealing with
>> non-XML formats in hybrid applications.
>>
>> Many thanks,
>> Tim
>>
>> --
>> Tim A. Thompson
>> Metadata Librarian (Spanish/Portuguese Specialty)
>> Princeton University Library
>>
>>
>> ------------------------------------------------------------------------------
>> Don't Limit Your Business. Reach for the Cloud.
>> GigeNET's Cloud Solutions provide you with the tools and support that
>> you need to offload your IT needs and focus on growing your business.
>> Configured For All Businesses. Start Your Cloud Today.
>> https://www.gigenetcloud.com/
>>
>>
>> _______________________________________________
>> Xsltforms-support mailing list
>> Xsl...@li...
>> <mailto:Xsl...@li...>
>> https://lists.sourceforge.net/lists/listinfo/xsltforms-support
>
>
|
|
From: Tim T. <tim...@gm...> - 2015-07-08 00:46:54
|
Alain,
Thank you very much for these updates!
However, I am running into a couple of errors.
1. In addition to the CDATA comments,
<?javax.xml.transform.enable-output-escaping?> processing instructions are
also being output inside the <script> tags, which is causing a syntax error
(in Firefox, Chrome, and IE). Firefox throws the following error:
SyntaxError: expected expression, got '<'
2. When I clear my browser cache and reload the page, the transformation
breaks with a server error:
Error while serializing XML: Ambiguous rule match for
/html/head[1]/script[1] Matches both "xhtml:script[not(@type) or @type =
'text/javascript'] | script[not(@type) or @type = 'text/javascript']"
Sorry for the trouble!
Tim
--
Tim A. Thompson
Metadata Librarian (Spanish/Portuguese Specialty)
Princeton University Library
On Tue, Jul 7, 2015 at 3:23 PM, Alain Couthures <
ala...@ag...> wrote:
> Tim,
>
> I have now committed CDATA support:
>
> - script content is "escaped" with CDATA for "text/javascript" and
> "text/turtle"
> - @cdata-section-elements in submission is supported for all major
> browsers
>
> Thank you for your feedback!
>
> --Alain
>
>
> Le 06/07/2015 20:00, Tim Thompson a écrit :
>
> Alain,
>
> I think adding the proposed CDATA encapsulations to script elements would
> be a great solution.
>
> Regarding @cdata-section-elements, I do need this functionality, in some
> form, for the application I'm working on. But my first preference would be
> to output the CDATA sections on the server using XQuery. Unfortunately,
> eXist does not currently support cdata-section-elements as a serialization
> parameter either, so I was considering the @cdata-section-elements
> submission attribute as a temporary workaround. I do think this would be a
> good feature to have, but for now, just adding the CDATA encapsulations
> would make a big difference.
>
> Thanks again!
> Tim
>
>
> --
> Tim A. Thompson
> Metadata Librarian (Spanish/Portuguese Specialty)
> Princeton University Library
>
>
> On Mon, Jul 6, 2015 at 1:08 PM, Alain Couthures <
> ala...@ag...> wrote:
>
>> Tim,
>>
>> XSLT does not preserve CDATA nodes but treats them into text nodes. It is
>> still possible to treat script elements according to their type attributes.
>> I can modified the XSLT stylesheet accordingly: for "text/javascript", the
>> script value can be encapsulated with "/* <![CDATA[ */" and "/* ]]> */",
>> and, for "text/turtle", with "# <![CDATA[" and "# ]]>". What do you think?
>>
>> For submission, adding support for @cdata-section-elements is not
>> difficult for non-IE browsers because serialization is performed with
>> Javascript instructions. For IE, because serialization is still based on an
>> XSLT transformation, the stylesheet source would have to be adapted
>> according to @cdata-section-elements value. Do you already need this?
>>
>> --Alain
>>
>>
>> Le 05/07/2015 04:10, Tim Thompson a écrit :
>>
>> Alain,
>>
>> I am trying to load a subform that contains a <script
>> type="text/turtle"> tag with RDF data serialized as Turtle.
>>
>> This data is enclosed in a CDATA section (per
>> http://www.w3.org/TR/turtle/#h3_xhtml). However, when I load the subform
>> (as XHTML), the CDATA is ignored and all <> characters are escaped, which
>> causes the Turtle parser I am using to break. Shouldn't CDATA contents be
>> ignored when a subform is loaded?
>>
>> As a related question, does XSLTForms support the
>> @cdata-section-elements attribute on <xf:submission>? I see some reference
>> to it in the code, but wasn't sure whether it had been fully implemented.
>> This could be very useful for dealing with non-XML formats in hybrid
>> applications.
>>
>> Many thanks,
>> Tim
>>
>> --
>> Tim A. Thompson
>> Metadata Librarian (Spanish/Portuguese Specialty)
>> Princeton University Library
>>
>>
>> ------------------------------------------------------------------------------
>> Don't Limit Your Business. Reach for the Cloud.
>> GigeNET's Cloud Solutions provide you with the tools and support that
>> you need to offload your IT needs and focus on growing your business.
>> Configured For All Businesses. Start Your Cloud Today.https://www.gigenetcloud.com/
>>
>>
>>
>> _______________________________________________
>> Xsltforms-support mailing lis...@li...://lists.sourceforge.net/lists/listinfo/xsltforms-support
>>
>>
>>
>
>
|
|
From: Tim T. <tim...@gm...> - 2015-07-08 03:43:47
|
Just to update: the previous errors were produced in eXist 2.2. I have also done some testing in BaseX 8.2.2, and I did not get these errors. In BaseX, the CDATA sections seem to be properly generated (no processing instructions appear in the output) and the application runs in Chrome and Internet Explorer 11. It still does not run in Firefox, however, which fails to load properly and throws a vague "not well-formed" error. --Tim -- Tim A. Thompson Metadata Librarian (Spanish/Portuguese Specialty) Princeton University Library On Tue, Jul 7, 2015 at 8:46 PM, Tim Thompson <tim...@gm...> wrote: > Alain, > > Thank you very much for these updates! > > However, I am running into a couple of errors. > > 1. In addition to the CDATA comments, > <?javax.xml.transform.enable-output-escaping?> processing instructions are > also being output inside the <script> tags, which is causing a syntax error > (in Firefox, Chrome, and IE). Firefox throws the following error: > > SyntaxError: expected expression, got '<' > > 2. When I clear my browser cache and reload the page, the transformation > breaks with a server error: > > Error while serializing XML: Ambiguous rule match for > /html/head[1]/script[1] Matches both "xhtml:script[not(@type) or @type = > 'text/javascript'] | script[not(@type) or @type = 'text/javascript']" > > Sorry for the trouble! > > Tim > > -- > Tim A. Thompson > Metadata Librarian (Spanish/Portuguese Specialty) > Princeton University Library > > > On Tue, Jul 7, 2015 at 3:23 PM, Alain Couthures < > ala...@ag...> wrote: > >> Tim, >> >> I have now committed CDATA support: >> >> - script content is "escaped" with CDATA for "text/javascript" and >> "text/turtle" >> - @cdata-section-elements in submission is supported for all major >> browsers >> >> Thank you for your feedback! >> >> --Alain >> >> >> Le 06/07/2015 20:00, Tim Thompson a écrit : >> >> Alain, >> >> I think adding the proposed CDATA encapsulations to script elements >> would be a great solution. >> >> Regarding @cdata-section-elements, I do need this functionality, in some >> form, for the application I'm working on. But my first preference would be >> to output the CDATA sections on the server using XQuery. Unfortunately, >> eXist does not currently support cdata-section-elements as a serialization >> parameter either, so I was considering the @cdata-section-elements >> submission attribute as a temporary workaround. I do think this would be a >> good feature to have, but for now, just adding the CDATA encapsulations >> would make a big difference. >> >> Thanks again! >> Tim >> >> >> -- >> Tim A. Thompson >> Metadata Librarian (Spanish/Portuguese Specialty) >> Princeton University Library >> >> >> On Mon, Jul 6, 2015 at 1:08 PM, Alain Couthures < >> ala...@ag...> wrote: >> >>> Tim, >>> >>> XSLT does not preserve CDATA nodes but treats them into text nodes. It >>> is still possible to treat script elements according to their type >>> attributes. I can modified the XSLT stylesheet accordingly: for >>> "text/javascript", the script value can be encapsulated with "/* <![CDATA[ >>> */" and "/* ]]> */", and, for "text/turtle", with "# <![CDATA[" and "# >>> ]]>". What do you think? >>> >>> For submission, adding support for @cdata-section-elements is not >>> difficult for non-IE browsers because serialization is performed with >>> Javascript instructions. For IE, because serialization is still based on an >>> XSLT transformation, the stylesheet source would have to be adapted >>> according to @cdata-section-elements value. Do you already need this? >>> >>> --Alain >>> >>> >>> Le 05/07/2015 04:10, Tim Thompson a écrit : >>> >>> Alain, >>> >>> I am trying to load a subform that contains a <script >>> type="text/turtle"> tag with RDF data serialized as Turtle. >>> >>> This data is enclosed in a CDATA section (per >>> http://www.w3.org/TR/turtle/#h3_xhtml). However, when I load the >>> subform (as XHTML), the CDATA is ignored and all <> characters are escaped, >>> which causes the Turtle parser I am using to break. Shouldn't CDATA >>> contents be ignored when a subform is loaded? >>> >>> As a related question, does XSLTForms support the >>> @cdata-section-elements attribute on <xf:submission>? I see some reference >>> to it in the code, but wasn't sure whether it had been fully implemented. >>> This could be very useful for dealing with non-XML formats in hybrid >>> applications. >>> >>> Many thanks, >>> Tim >>> >>> -- >>> Tim A. Thompson >>> Metadata Librarian (Spanish/Portuguese Specialty) >>> Princeton University Library >>> >>> >>> ------------------------------------------------------------------------------ >>> Don't Limit Your Business. Reach for the Cloud. >>> GigeNET's Cloud Solutions provide you with the tools and support that >>> you need to offload your IT needs and focus on growing your business. >>> Configured For All Businesses. Start Your Cloud Today.https://www.gigenetcloud.com/ >>> >>> >>> >>> _______________________________________________ >>> Xsltforms-support mailing lis...@li...://lists.sourceforge.net/lists/listinfo/xsltforms-support >>> >>> >>> >> >> > |
|
From: Alain C. <ala...@ag...> - 2015-07-08 19:37:56
|
Tim, A "not well-formed" error might be due to an incorrect content-type for Firefox. Have you already checked this? --Alain Le 08/07/2015 05:43, Tim Thompson a écrit : > Just to update: the previous errors were produced in eXist 2.2. I have > also done some testing in BaseX 8.2.2, and I did not get these errors. > In BaseX, the CDATA sections seem to be properly generated (no > processing instructions appear in the output) and the application runs > in Chrome and Internet Explorer 11. It still does not run in Firefox, > however, which fails to load properly and throws a vague "not > well-formed" error. > > --Tim > > -- > Tim A. Thompson > Metadata Librarian (Spanish/Portuguese Specialty) > Princeton University Library > > > On Tue, Jul 7, 2015 at 8:46 PM, Tim Thompson <tim...@gm... > <mailto:tim...@gm...>> wrote: > > Alain, > > Thank you very much for these updates! > > However, I am running into a couple of errors. > > 1. In addition to the CDATA comments, > <?javax.xml.transform.enable-output-escaping?> processing > instructions are also being output inside the <script> tags, which > is causing a syntax error (in Firefox, Chrome, and IE). Firefox > throws the following error: > > SyntaxError: expected expression, got '<' > > 2. When I clear my browser cache and reload the page, the > transformation breaks with a server error: > > Error while serializing XML: Ambiguous rule match for > /html/head[1]/script[1] Matches both "xhtml:script[not(@type) or > @type = 'text/javascript'] | script[not(@type) or @type = > 'text/javascript']" > > Sorry for the trouble! > > Tim > > -- > Tim A. Thompson > Metadata Librarian (Spanish/Portuguese Specialty) > Princeton University Library > > > On Tue, Jul 7, 2015 at 3:23 PM, Alain Couthures > <ala...@ag... > <mailto:ala...@ag...>> wrote: > > Tim, > > I have now committed CDATA support: > > * script content is "escaped" with CDATA for > "text/javascript" and "text/turtle" > * @cdata-section-elements in submission is supported for all > major browsers > > Thank you for your feedback! > > --Alain > > > Le 06/07/2015 20:00, Tim Thompson a écrit : >> Alain, >> >> I think adding the proposed CDATA encapsulations to script >> elements would be a great solution. >> >> Regarding @cdata-section-elements, I do need this >> functionality, in some form, for the application I'm working >> on. But my first preference would be to output the CDATA >> sections on the server using XQuery. Unfortunately, eXist >> does not currently support cdata-section-elements as a >> serialization parameter either, so I was considering the >> @cdata-section-elements submission attribute as a temporary >> workaround. I do think this would be a good feature to have, >> but for now, just adding the CDATA encapsulations would make >> a big difference. >> >> Thanks again! >> Tim >> >> >> -- >> Tim A. Thompson >> Metadata Librarian (Spanish/Portuguese Specialty) >> Princeton University Library >> >> >> On Mon, Jul 6, 2015 at 1:08 PM, Alain Couthures >> <ala...@ag... >> <mailto:ala...@ag...>> wrote: >> >> Tim, >> >> XSLT does not preserve CDATA nodes but treats them into >> text nodes. It is still possible to treat script elements >> according to their type attributes. I can modified the >> XSLT stylesheet accordingly: for "text/javascript", the >> script value can be encapsulated with "/* <![CDATA[ */" >> and "/* ]]> */", and, for "text/turtle", with "# >> <![CDATA[" and "# ]]>". What do you think? >> >> For submission, adding support for >> @cdata-section-elements is not difficult for non-IE >> browsers because serialization is performed with >> Javascript instructions. For IE, because serialization is >> still based on an XSLT transformation, the stylesheet >> source would have to be adapted according to >> @cdata-section-elements value. Do you already need this? >> >> --Alain >> >> >> Le 05/07/2015 04:10, Tim Thompson a écrit : >>> Alain, >>> >>> I am trying to load a subform that contains a <script >>> type="text/turtle"> tag with RDF data serialized as Turtle. >>> >>> This data is enclosed in a CDATA section (per >>> http://www.w3.org/TR/turtle/#h3_xhtml). However, when I >>> load the subform (as XHTML), the CDATA is ignored and >>> all <> characters are escaped, which causes the Turtle >>> parser I am using to break. Shouldn't CDATA contents be >>> ignored when a subform is loaded? >>> >>> As a related question, does XSLTForms support the >>> @cdata-section-elements attribute on <xf:submission>? I >>> see some reference to it in the code, but wasn't sure >>> whether it had been fully implemented. This could be >>> very useful for dealing with non-XML formats in hybrid >>> applications. >>> >>> Many thanks, >>> Tim >>> >>> -- >>> Tim A. Thompson >>> Metadata Librarian (Spanish/Portuguese Specialty) >>> Princeton University Library >>> >>> >>> ------------------------------------------------------------------------------ >>> Don't Limit Your Business. Reach for the Cloud. >>> GigeNET's Cloud Solutions provide you with the tools and support that >>> you need to offload your IT needs and focus on growing your business. >>> Configured For All Businesses. Start Your Cloud Today. >>> https://www.gigenetcloud.com/ >>> >>> >>> _______________________________________________ >>> Xsltforms-support mailing list >>> Xsl...@li... >>> <mailto:Xsl...@li...> >>> https://lists.sourceforge.net/lists/listinfo/xsltforms-support >> >> > > > |
|
From: Alain C. <ala...@ag...> - 2015-07-08 20:23:39
|
Tim, About "Ambiguous rule match", it sounds as if the error message is incomplete because it should end with at least 2 different @match values. Can you please check this? Thanks! --Alain Le 08/07/2015 02:46, Tim Thompson a écrit : > Alain, > > Thank you very much for these updates! > > However, I am running into a couple of errors. > > 1. In addition to the CDATA comments, > <?javax.xml.transform.enable-output-escaping?> processing instructions > are also being output inside the <script> tags, which is causing a > syntax error (in Firefox, Chrome, and IE). Firefox throws the > following error: > > SyntaxError: expected expression, got '<' > > 2. When I clear my browser cache and reload the page, the > transformation breaks with a server error: > > Error while serializing XML: Ambiguous rule match for > /html/head[1]/script[1] Matches both "xhtml:script[not(@type) or @type > = 'text/javascript'] | script[not(@type) or @type = 'text/javascript']" > > Sorry for the trouble! > > Tim > > -- > Tim A. Thompson > Metadata Librarian (Spanish/Portuguese Specialty) > Princeton University Library > > > On Tue, Jul 7, 2015 at 3:23 PM, Alain Couthures > <ala...@ag... <mailto:ala...@ag...>> > wrote: > > Tim, > > I have now committed CDATA support: > > * script content is "escaped" with CDATA for "text/javascript" > and "text/turtle" > * @cdata-section-elements in submission is supported for all > major browsers > > Thank you for your feedback! > > --Alain > > > Le 06/07/2015 20:00, Tim Thompson a écrit : >> Alain, >> >> I think adding the proposed CDATA encapsulations to script >> elements would be a great solution. >> >> Regarding @cdata-section-elements, I do need this functionality, >> in some form, for the application I'm working on. But my first >> preference would be to output the CDATA sections on the server >> using XQuery. Unfortunately, eXist does not currently support >> cdata-section-elements as a serialization parameter either, so I >> was considering the @cdata-section-elements submission attribute >> as a temporary workaround. I do think this would be a good >> feature to have, but for now, just adding the CDATA >> encapsulations would make a big difference. >> >> Thanks again! >> Tim >> >> >> -- >> Tim A. Thompson >> Metadata Librarian (Spanish/Portuguese Specialty) >> Princeton University Library >> >> >> On Mon, Jul 6, 2015 at 1:08 PM, Alain Couthures >> <ala...@ag... >> <mailto:ala...@ag...>> wrote: >> >> Tim, >> >> XSLT does not preserve CDATA nodes but treats them into text >> nodes. It is still possible to treat script elements >> according to their type attributes. I can modified the XSLT >> stylesheet accordingly: for "text/javascript", the script >> value can be encapsulated with "/* <![CDATA[ */" and "/* ]]> >> */", and, for "text/turtle", with "# <![CDATA[" and "# ]]>". >> What do you think? >> >> For submission, adding support for @cdata-section-elements is >> not difficult for non-IE browsers because serialization is >> performed with Javascript instructions. For IE, because >> serialization is still based on an XSLT transformation, the >> stylesheet source would have to be adapted according to >> @cdata-section-elements value. Do you already need this? >> >> --Alain >> >> >> Le 05/07/2015 04:10, Tim Thompson a écrit : >>> Alain, >>> >>> I am trying to load a subform that contains a <script >>> type="text/turtle"> tag with RDF data serialized as Turtle. >>> >>> This data is enclosed in a CDATA section (per >>> http://www.w3.org/TR/turtle/#h3_xhtml). However, when I load >>> the subform (as XHTML), the CDATA is ignored and all <> >>> characters are escaped, which causes the Turtle parser I am >>> using to break. Shouldn't CDATA contents be ignored when a >>> subform is loaded? >>> >>> As a related question, does XSLTForms support the >>> @cdata-section-elements attribute on <xf:submission>? I see >>> some reference to it in the code, but wasn't sure whether it >>> had been fully implemented. This could be very useful for >>> dealing with non-XML formats in hybrid applications. >>> >>> Many thanks, >>> Tim >>> >>> -- >>> Tim A. Thompson >>> Metadata Librarian (Spanish/Portuguese Specialty) >>> Princeton University Library >>> >>> >>> ------------------------------------------------------------------------------ >>> Don't Limit Your Business. Reach for the Cloud. >>> GigeNET's Cloud Solutions provide you with the tools and support that >>> you need to offload your IT needs and focus on growing your business. >>> Configured For All Businesses. Start Your Cloud Today. >>> https://www.gigenetcloud.com/ >>> >>> >>> _______________________________________________ >>> Xsltforms-support mailing list >>> Xsl...@li... >>> <mailto:Xsl...@li...> >>> https://lists.sourceforge.net/lists/listinfo/xsltforms-support >> >> > > |
|
From: Tim T. <tim...@gm...> - 2015-07-08 20:53:22
|
Alain, I reinstalled eXist 2.2 and am not currently getting the "ambiguous rule match" error anymore. But, yes, there were originally 2 different @match values. Best, Tim -- Tim A. Thompson Metadata Librarian (Spanish/Portuguese Specialty) Princeton University Library On Wed, Jul 8, 2015 at 4:23 PM, Alain Couthures < ala...@ag...> wrote: > Tim, > > About "Ambiguous rule match", it sounds as if the error message is > incomplete because it should end with at least 2 different @match values. > Can you please check this? > > Thanks! > > --Alain > > > Le 08/07/2015 02:46, Tim Thompson a écrit : > > Alain, > > Thank you very much for these updates! > > However, I am running into a couple of errors. > > 1. In addition to the CDATA comments, > <?javax.xml.transform.enable-output-escaping?> processing instructions are > also being output inside the <script> tags, which is causing a syntax error > (in Firefox, Chrome, and IE). Firefox throws the following error: > > SyntaxError: expected expression, got '<' > > 2. When I clear my browser cache and reload the page, the transformation > breaks with a server error: > > Error while serializing XML: Ambiguous rule match for > /html/head[1]/script[1] Matches both "xhtml:script[not(@type) or @type = > 'text/javascript'] | script[not(@type) or @type = 'text/javascript']" > > Sorry for the trouble! > > Tim > > -- > Tim A. Thompson > Metadata Librarian (Spanish/Portuguese Specialty) > Princeton University Library > > > On Tue, Jul 7, 2015 at 3:23 PM, Alain Couthures < > <ala...@ag...>ala...@ag...> wrote: > >> Tim, >> >> I have now committed CDATA support: >> >> - script content is "escaped" with CDATA for "text/javascript" and >> "text/turtle" >> - @cdata-section-elements in submission is supported for all major >> browsers >> >> Thank you for your feedback! >> >> --Alain >> >> >> Le 06/07/2015 20:00, Tim Thompson a écrit : >> >> Alain, >> >> I think adding the proposed CDATA encapsulations to script elements >> would be a great solution. >> >> Regarding @cdata-section-elements, I do need this functionality, in some >> form, for the application I'm working on. But my first preference would be >> to output the CDATA sections on the server using XQuery. Unfortunately, >> eXist does not currently support cdata-section-elements as a serialization >> parameter either, so I was considering the @cdata-section-elements >> submission attribute as a temporary workaround. I do think this would be a >> good feature to have, but for now, just adding the CDATA encapsulations >> would make a big difference. >> >> Thanks again! >> Tim >> >> >> -- >> Tim A. Thompson >> Metadata Librarian (Spanish/Portuguese Specialty) >> Princeton University Library >> >> >> On Mon, Jul 6, 2015 at 1:08 PM, Alain Couthures < >> <ala...@ag...>ala...@ag...> wrote: >> >>> Tim, >>> >>> XSLT does not preserve CDATA nodes but treats them into text nodes. It >>> is still possible to treat script elements according to their type >>> attributes. I can modified the XSLT stylesheet accordingly: for >>> "text/javascript", the script value can be encapsulated with "/* <![CDATA[ >>> */" and "/* ]]> */", and, for "text/turtle", with "# <![CDATA[" and "# >>> ]]>". What do you think? >>> >>> For submission, adding support for @cdata-section-elements is not >>> difficult for non-IE browsers because serialization is performed with >>> Javascript instructions. For IE, because serialization is still based on an >>> XSLT transformation, the stylesheet source would have to be adapted >>> according to @cdata-section-elements value. Do you already need this? >>> >>> --Alain >>> >>> >>> Le 05/07/2015 04:10, Tim Thompson a écrit : >>> >>> Alain, >>> >>> I am trying to load a subform that contains a <script >>> type="text/turtle"> tag with RDF data serialized as Turtle. >>> >>> This data is enclosed in a CDATA section (per >>> <http://www.w3.org/TR/turtle/#h3_xhtml> >>> http://www.w3.org/TR/turtle/#h3_xhtml). However, when I load the >>> subform (as XHTML), the CDATA is ignored and all <> characters are escaped, >>> which causes the Turtle parser I am using to break. Shouldn't CDATA >>> contents be ignored when a subform is loaded? >>> >>> As a related question, does XSLTForms support the >>> @cdata-section-elements attribute on <xf:submission>? I see some reference >>> to it in the code, but wasn't sure whether it had been fully implemented. >>> This could be very useful for dealing with non-XML formats in hybrid >>> applications. >>> >>> Many thanks, >>> Tim >>> >>> -- >>> Tim A. Thompson >>> Metadata Librarian (Spanish/Portuguese Specialty) >>> Princeton University Library >>> >>> >>> ------------------------------------------------------------------------------ >>> Don't Limit Your Business. Reach for the Cloud. >>> GigeNET's Cloud Solutions provide you with the tools and support that >>> you need to offload your IT needs and focus on growing your business. >>> Configured For All Businesses. Start Your Cloud Today.https://www.gigenetcloud.com/ >>> >>> >>> >>> _______________________________________________ >>> Xsltforms-support mailing lis...@li...://lists.sourceforge.net/lists/listinfo/xsltforms-support >>> >>> >>> >> >> > > |
Thanks for helping keep SourceForge clean.
X