Re: Action A-659-05 Completed

Hi,

> A feature that prevents people from implementing a spec is a serious
> problem.
>
> What can we do to change this?

Less Unicode everywhere would have been helpful.

You could have said the strings are a sequence of bytes, like char* in 
C, and be done with it.

For the collations I know no library, but the rest was also complicated: 
normalize-unicode (required a special 3rd party library just for that 
function, 30% of the final program size was taken by its tables, and 
then the library did not even work on all inputs), matches/replace 
(another 3rd party library. 50% of still failing QT3 tests are due to a 
different interpretation of the Unicode \p-classes in it, and it takes 
like 30% of the runtime), format-* (if anyone needs  other digits than 
0..9, they could just fn:translate them), the #x85/#x2028 whitespace 
normalization (#xA and #xD can be normalized without knowing if is utf-8 
or latin1), ..



By the way, FO 1.7.1 says:

[Definition] A *character* is an instance of the Char 
<http://www.w3.org/TR/REC-xml/#NT-Char>^XML production of [Extensible 
Markup Language (XML) 1.0 (Fifth Edition)] 
<https://www.w3.org/XML/Group/qtspecs/specifications/xpath-functions-31/html/Overview-diff.html#xml>.

Perhaps that should be updated to XML 1.1 ?


> I note things like pyuca and pyICU and
> even zope.ucol all for Python, so it seems there's some library
> support. But I'm sure you found these too.


But I work in FreePascal not Python.

There you usually use codepaged byte-strings or UCS-2. Only last year 
the rtl even got utf-8 support.



Cheers,
Benito


On 11.11.2016 04:37, Liam R. E. Quin wrote:
> On Wed, 2016-11-09 at 23:18 +0100, Benito van der Zander wrote:
> [...]
>>> * Support for UCA Collations. We chose to make support for UCA
>>> collations mandatory in the interests of interoperability and I18N
>>> support, but implementation is technically challenging, and
>>> typically
>>> depends on third party libraries. We could make the feature
>>> optional,
>>> but we don't think this would be in the interests of the user
>>> community; rather we would prefer to accept that implementation of
>>> these features may lag a little behind.
>>>
>>>   
>> And this point is actually what has stopped me from implementing
>> XQuery 3.1 so far.
> A feature that prevents people from implementing a spec is a serious
> problem.
>
> What can we do to change this? I note things like pyuca and pyICU and
> even zope.ucol all for Python, so it seems there's some library
> support. But I'm sure you found these too.
>
>>> * Support for fn:transform() (dynamic invocation of XSLT from
>>> XQuery).
>>> There is strong evidence that users require this feature, but it
>>> is
>>> difficult to ensure 100% interoperability of implementations
>>> because
>>> in many cases it will depend on integrating a third-party product.
>>> Tests where the transformation requires XSLT 3.0 are particularly
>>> challenging because the standard is so new. We think we have done
>>> the
>>> right thing by including this feature although it will probably
>>> remain
>>> true that different vendors will offer different subsets of the
>>> capability.
>>>
>> or this.
> Right - you could use libxml2 (and have XSLT 1 support only), but
> support for fn:transform necessarily has to be optional in practice.
>
> Liam
>