From ihe.onwuka at gmail.com  Mon Dec  1 00:06:34 2014
From: ihe.onwuka at gmail.com (Ihe Onwuka)
Date: Mon, 1 Dec 2014 08:06:34 +0000
Subject: [xquery-talk] [saxon] getting around the built in type
 restriction of a Basic XSLT processor
In-Reply-To: <DA948873-4219-448C-B38F-0A85FBBDCEA4@saxonica.com>
References: <CALfs7+wKQutLMSDjAuZH2=MZDB0VM0XqTEqMmO7f7j5+r+oS+A@mail.gmail.com>
	<DA948873-4219-448C-B38F-0A85FBBDCEA4@saxonica.com>
Message-ID: <CALfs7+wfB8kb7XR4wFKBbOHXjtzD7nHGy0uRXPBeQ1VdMH5C+g@mail.gmail.com>

On Sun, Nov 30, 2014 at 10:32 PM, Michael Kay <mike at saxonica.com> wrote:

> The XSLT 2.0 spec restricts the set of types available in a
> non-schema-aware processor. Schema awareness comes only with Saxon-EE.
>
> The extension attribute saxon:allow-all-built-in-types removes the
> restriction (making the processor non-conformant), but like all extensions
> in the Saxon namespace, it is available only with Saxon-PE or higher.
>
> If it's only the castable test you are after, you could use matches(.,
> '\i\c*')
>
>
This returns true for matches('1880s','\i\c*') in Saxon XSLT and Zorba.


> On 30 Nov 2014, at 20:28, Ihe Onwuka <ihe.onwuka at gmail.com> wrote:
>
> I have a sequence of keywords which I would like to create as empty
> elements if their content constitutes a valid element name but I cannot
> execute the following because of the above restriction that prevents the
> comparison to xs:NCName
>
> Code is below.
>
>         <xsl:for-each select="tokenize(substring-after(.,'&#9;'),'\t')">
>           <xsl:choose>
>             <xsl:when test=". castable as xs:NCName">
>               <xsl:element name="{.}"/>
>             </xsl:when>
>             <xsl:otherwise>
>               <keyword name="{.}"/>
>             </xsl:otherwise>
>          </xsl:for-each>
>
> I have tried the allow-all-built-in-types saxon attribute and that hasn't
> worked.
>
> Any other suggestions.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://x-query.com/pipermail/talk/attachments/20141201/e5ae2e5a/attachment.html>

From ihe.onwuka at gmail.com  Mon Dec  1 00:13:47 2014
From: ihe.onwuka at gmail.com (Ihe Onwuka)
Date: Mon, 1 Dec 2014 08:13:47 +0000
Subject: [xquery-talk] [saxon] getting around the built in type
 restriction of a Basic XSLT processor
In-Reply-To: <CALfs7+wfB8kb7XR4wFKBbOHXjtzD7nHGy0uRXPBeQ1VdMH5C+g@mail.gmail.com>
References: <CALfs7+wKQutLMSDjAuZH2=MZDB0VM0XqTEqMmO7f7j5+r+oS+A@mail.gmail.com>
	<DA948873-4219-448C-B38F-0A85FBBDCEA4@saxonica.com>
	<CALfs7+wfB8kb7XR4wFKBbOHXjtzD7nHGy0uRXPBeQ1VdMH5C+g@mail.gmail.com>
Message-ID: <CALfs7+xxRucG4M2C-TETLznvVBr1yT3VPxvLxG-ZKOHxM4GGiw@mail.gmail.com>

ah hah... the regex needs to start with a ^ and is '^\i\c*'

On Mon, Dec 1, 2014 at 8:06 AM, Ihe Onwuka <ihe.onwuka at gmail.com> wrote:

>
> On Sun, Nov 30, 2014 at 10:32 PM, Michael Kay <mike at saxonica.com> wrote:
>
>> The XSLT 2.0 spec restricts the set of types available in a
>> non-schema-aware processor. Schema awareness comes only with Saxon-EE.
>>
>> The extension attribute saxon:allow-all-built-in-types removes the
>> restriction (making the processor non-conformant), but like all extensions
>> in the Saxon namespace, it is available only with Saxon-PE or higher.
>>
>> If it's only the castable test you are after, you could use matches(.,
>> '\i\c*')
>>
>>
> This returns true for matches('1880s','\i\c*') in Saxon XSLT and Zorba.
>
>
>> On 30 Nov 2014, at 20:28, Ihe Onwuka <ihe.onwuka at gmail.com> wrote:
>>
>> I have a sequence of keywords which I would like to create as empty
>> elements if their content constitutes a valid element name but I cannot
>> execute the following because of the above restriction that prevents the
>> comparison to xs:NCName
>>
>> Code is below.
>>
>>         <xsl:for-each select="tokenize(substring-after(.,'&#9;'),'\t')">
>>           <xsl:choose>
>>             <xsl:when test=". castable as xs:NCName">
>>               <xsl:element name="{.}"/>
>>             </xsl:when>
>>             <xsl:otherwise>
>>               <keyword name="{.}"/>
>>             </xsl:otherwise>
>>          </xsl:for-each>
>>
>> I have tried the allow-all-built-in-types saxon attribute and that hasn't
>> worked.
>>
>> Any other suggestions.
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://x-query.com/pipermail/talk/attachments/20141201/ec2f0ad1/attachment.html>

From ihe.onwuka at gmail.com  Mon Dec  1 00:20:26 2014
From: ihe.onwuka at gmail.com (Ihe Onwuka)
Date: Mon, 1 Dec 2014 08:20:26 +0000
Subject: [xquery-talk] [saxon] getting around the built in type
 restriction of a Basic XSLT processor
In-Reply-To: <CEBDE503-BA5B-455C-A808-86A387AAEA8A@saxonica.com>
References: <CALfs7+wKQutLMSDjAuZH2=MZDB0VM0XqTEqMmO7f7j5+r+oS+A@mail.gmail.com>
	<DA948873-4219-448C-B38F-0A85FBBDCEA4@saxonica.com>
	<CALfs7+wfB8kb7XR4wFKBbOHXjtzD7nHGy0uRXPBeQ1VdMH5C+g@mail.gmail.com>
	<CEBDE503-BA5B-455C-A808-86A387AAEA8A@saxonica.com>
Message-ID: <CALfs7+x8DZfFnD9sk1zQsh_YRYWVcUSc=cPO8yj78nFxJkzcjg@mail.gmail.com>

yes otherwise it would return true for things like man's-hat .

On Mon, Dec 1, 2014 at 8:15 AM, John Lumley <john at saxonica.com> wrote:

> On 1 Dec 2014, at 08:06, Ihe Onwuka <ihe.onwuka at gmail.com> wrote:
>
> If it's only the castable test you are after, you could use matches(.,
>> '\i\c*')
>>
>>
> This returns true for matches('1880s','\i\c*') in Saxon XSLT and Zorba.
>
>
> Perhaps the match should be anchored: matches(.,'^\i\c*$')
>
> John Lumley
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://x-query.com/pipermail/talk/attachments/20141201/b8f16e59/attachment.html>

From france.baril at architextus.com  Wed Dec 10 15:09:40 2014
From: france.baril at architextus.com (France Baril)
Date: Wed, 10 Dec 2014 17:09:40 -0600
Subject: [xquery-talk] Serialize xml to html5 with php.
In-Reply-To: <678C9BC8-2368-4847-BEA3-E2025378D199@basex.org>
References: <CAHNQ2BbY0E5XTBMErXs-Oae+j8SFvHjaMZrFWALxKWv_jwivLQ@mail.gmail.com>
	<678C9BC8-2368-4847-BEA3-E2025378D199@basex.org>
Message-ID: <CAHNQ2BYX=+MvVfNQyJjG8BH8pQ39yydgBB9C-d5maAKKJibbVA@mail.gmail.com>

Hi, solution #2 was the best option.

#1 was not an option in our context and #3 did not work in every browser.

On Thu, Nov 27, 2014 at 10:00 AM, Michael Seiferle <ms at basex.org> wrote:

> Hi France,
>
>
> I started toying around, here are three more or less pragmatic approaches
> :-)
>
> Are you required to use html(5) serialization? From what I understand
> processing instructions in HTML are serialized differently, '?>' serializes
> to '>':
> http://www.w3.org/TR/1999/REC-html401-19991224/appendix/notes.html#h-B.3.6
> (there may be a better source for this behavior, but this is what I found).
>
> In case you are not, you could work around this using xhtml serialization:
>
>> declare option output:method "xhtml";
>>
>> <x>
>> <?php print "Hi"  ?>
>> <input/>
>> </x>
>>
>
> or alternatively add an extra '?':
>
>> declare option output:method "html";
>> declare option output:html-version "5.0";
>>
>> <x>
>> <?php haha  ??>
>> <input/>
>> </x>
>>
>
> or you could make use of PHPs script syntax: http://php.net/manual/en/
> language.basic-syntax.phpmode.php
>
>  <script language="php">
>>     echo 'some editors (like FrontPage) don\'t
>>          like processing instructions';
>> </script>
>>
>
> Best
>
> Michael
>
>
> On 27 Nov 2014, at 16:33, France Baril wrote:
>
>  Hi,
>>
>> I was trying to use BaseX to export files that contain some php code, and
>> after xml to html5 serialization  <?php ... ?> becomes <?php ...>.
>>
>> They suggested I contact this list to enquire about any option to export
>> the php with the closing '?'?
>>
>>
>> --
>> France Baril
>> Architecte documentaire / Documentation architect
>> france.baril at architextus.com
>> _______________________________________________
>> talk at x-query.com
>> http://x-query.com/mailman/listinfo/talk
>>
>


-- 
France Baril
Architecte documentaire / Documentation architect
france.baril at architextus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://x-query.com/pipermail/talk/attachments/20141210/20172a78/attachment.html>

From liam at w3.org  Mon Dec 22 20:48:53 2014
From: liam at w3.org (Liam R E Quin)
Date: Mon, 22 Dec 2014 23:48:53 -0500
Subject: [xquery-talk] XQuery 3.1, XPath 3.1,
 XQueryX 3.1 now W3C Candidate Recommendations - Call for
 Implementations
Message-ID: <20141222234853.71016d1d.liam@w3.org>

The XQuery and XSLT Working Groups here at the World Wide Web Consortium have published
* XQuery 3.1
* Xpath 3.1
* XQueryX 3.1
* Functions and Operators 3.1
* Data Model 3.1
as W3C Candidate Recommendations; the documents are expected to be stable unless implementation feedback means we have to change them, so please let us know!

See the Status section in each document for how to file comments using Bugzilla;
each document also has a Changes section.

You can find the documents on http://www.w3.org/TR/tr-date-all/

Liam


-- 
Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/

From liam at w3.org  Mon Dec 22 22:12:37 2014
From: liam at w3.org (Liam R E Quin)
Date: Tue, 23 Dec 2014 01:12:37 -0500
Subject: [xquery-talk] XQuery 3.1, XPath 3.1,
 XQueryX 3.1 now W3C Candidate Recommendations - Call for
 Implementations
Message-ID: <20141223011237.12f149a0.liam@w3.org>

[correcting a typo in the URL! oops]

The XQuery and XSLT Working Groups here at the World Wide Web Consortium have published
* XQuery 3.1
* Xpath 3.1
* XQueryX 3.1
* Functions and Operators 3.1
* Data Model 3.1
as W3C Candidate Recommendations; the documents are expected to be stable unless implementation feedback means we have to change them, so please let us know!

See the Status section in each document for how to file comments using Bugzilla;
each document also has a Changes section.

You can find the documents on http://www.w3.org/TR/tr-date-all

Liam


-- 
Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/