W3C home > Mailing lists > Public > public-multilingualweb-lt@w3.org > August 2012

Re: forbiddenCharacters data category - related to [ACTIOn-189]

From: Jirka Kosek <jirka@kosek.cz>
Date: Mon, 27 Aug 2012 17:19:50 +0200
Message-ID: <503B9016.6010502@kosek.cz>
To: Yves Savourel <ysavourel@enlaso.com>
CC: public-multilingualweb-lt@w3.org
On 27.8.2012 16:36, Yves Savourel wrote:

Hi Yves,

> While Jirka’s solution would help in reducing the number of cases where C0-etc. need to be specified, I think it still doesn’t provide a full solution: we would not be able to allow such characters.

But such characters can't be inside generic XML document unless you are
using some custom application specific escaping mechanism. So until
there is not generic mechanism for entering such characters inside XML
it doesn't make sense to support such characters in ITS.

> Another aspect to take into account is that—at least from my experience—it’s often much easier to define the list of forbidden characters than the list of allowed characters.

However such approach was source of many security flaws in past. And
with my proposal you can still do what you want by using [^...] notation.

> If we look again at the issue: it seems to boils down to two problems: a) the inability of the XML regex to handle invalid XML characters, and b) \uHHHH not supported by all engines.
> For a) it's an XML problem that keeps coming back in localization. More and more formats are working around that problem because they need to store those characters in XML. For example Unicode-LDML, TS and XLIFF2 define elements to 'escape' them. 

But ITS will never understood to custom escape syntaxes, it operates on
raw XML content. I see that you want to use ITS to transfer additional
information to processing system which can work on superset of XML
datamodel, for example by supporting C0 characters. But it feels strange
to standardize something which doesn't work on our datamodel.

> A use case like forbidden characters in Windows' path is a good illustration that we do need to support those characters in the regex.

Why you can't use something like


instead of


It's not that big difference and we would stay inside XML Schema regex


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

Received on Monday, 27 August 2012 15:20:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:31:51 UTC