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

Re: mlw-lt-track-ISSUE-53 (Empty string for allowedCharacters): Empty string for allowedCharacters [MLW-LT Standard Draft]

From: Pedro Luis Díez Orzas [Linguaserve I.S. SA] <pedro.diez@linguaserve.com>
Date: Fri, 5 Oct 2012 12:23:11 +0000
Message-ID: <918129218-1349439794-cardhu_decombobulator_blackberry.rim.net-81510208-@b11.c3.bise7.blackberry>
To: "MultilingualWeb-LT Working Group" <public-multilingualweb-lt@w3.org>
Hi Yves, I think this is the logical default behaviour. Agreed.



Pedro Luis Díez Orzas
Presidente Ejecutivo - CEO
Linguaserve I.S. S.A.
Enviado desde mi BlackBerry®

-----Original Message-----
From: MultilingualWeb-LT Working Group Issue Tracker <sysbot+tracker@w3.org>
Date: Fri, 05 Oct 2012 12:11:44 
To: <public-multilingualweb-lt@w3.org>
Reply-To: MultilingualWeb-LT Working Group <public-multilingualweb-lt@w3.org>
Subject: mlw-lt-track-ISSUE-53 (Empty string for allowedCharacters): Empty string for allowedCharacters [MLW-LT Standard Draft]

mlw-lt-track-ISSUE-53 (Empty string for allowedCharacters): Empty string for allowedCharacters [MLW-LT Standard Draft]

http://www.w3.org/International/multilingualweb/lt/track/issues/53


Raised by: Yves Savourel
On product: MLW-LT Standard Draft

What should be the behavior associated with allowedCharacter when its value is an empty string?

My question comes from trying to map ITS and XLIFF. In XLIFF there is an attribute that might be used for allowedCharacters, but it has this provision:  "A blank value indicates there is no limitation."

Since we don't define anything for a blank allowedCharacters, I assume it means the blank pattern is evaluated and can't possibly match any character, so it means none is allowed. (which is a strange case).

Is it the proper interpretation?

BTW: I'm not trying to force a mapping to XLIFF charclass, just trying to precise a bit more the ITS expected behavior to see if it matches or not.





Received on Friday, 5 October 2012 12:23:46 UTC

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