Re: [ACTION-160] (related to [ACTION-135] too) Summarize specialRequirements

2012/7/11 Arle Lommel <arle.lommel@dfki.de>

> I think we need to find out where Jan’s group is before we decide on
> this. If they don't have a proposal/implementation ready (yet), then maybe
> this is the perfect opportunity to coordinate with Microsoft and XLIFF on a
> common solution. If Microsoft is far along the path and willing to share,
> then maybe it shortens our development cycle to start where they are.
>
> I'm just afraid that it we end up with a simple enumeration solution
>

If that solves the problem of Cocomore and their customers, I'm not afraid
about that :)



> without at least range selectors and inverse, we will end up with a
> solution that will be seen as too cumbersome for many implementers and
> users. While it meets Michael’s needs and we need to be mindful of what
> implementers commit to, we also have to keep usability for the broader
> community in mind, and this is a case where I think that the broader
> community would expect more from ITS 2.0.
>

>From my experience it is OK to enhance a solution which is small and does
the right thing. If you do something in a hurry and do too much, you are
stuck with the mechanism. And don't forget our time line: we want to decide
about this by the end of July. I don't expect clear information about the
regex topic by then (but I may be wrong).

Felix


>
>
> -Arle
>
>
>
>
> On Jul 11, 2012, at 11:19 , Felix Sasaki wrote:
>
> We had also input from Microsoft (Ian) that they are working on a solution
> involving regex. So if the "enumeration only" works for Michael's /
> Cocomores scenario, I would disagree with going even a simple regex
> approach, to avoid too many solutions in the same problem space.
>
> Felix
>
> 2012/7/11 Michael Kruppa <Michael.Kruppa@cocomore.com>
>
>> Hi Yves, Arle, all,
>>
>> I totally agree that Arle's proposal is very reasonable. If we can
>> clarify the points Yves made, this would be a good solution from our point
>> of view.
>>
>> I would just like to clarify that I meant to say, that the enumeration
>> approach would be sufficient for us in order to avoid data storage and html
>> integration problems.
>> It is of course in no way sufficient for the examples Arle has given.
>>
>> Cheers
>>
>> Micha
>>
>> ________________________________________
>> Dr. Michael Kruppa, Senior IT-Consultant
>> Tel.: +49 69 972 69 189 Fax: +49 69 972 69 204; E-Mail:
>> michael.kruppa@cocomore.com
>> Cocomore AG, Gutleutstraße 30, D-60329 Frankfurt
>> Internet: http://www.cocomore.de Facebook:
>> http://www.facebook.com/cocomore Google+: http://plus.cocomore.de
>> Cocomore ist aktives Mitglied im World Wide Web Consortium (W3C) und im
>> Bundesverband Digitale Wirtschaft (BVDW)
>> Cocomore is active member of the World Wide Web Consortium (W3C)
>> Vorstand: Dr. Hans-Ulrich von Freyberg (Vors.), Dr. Jens Fricke, Marc
>> Kutschera, Vors. des Aufsichtsrates: Martin Velasco, Sitz: Frankfurt/Main,
>> Amtsgericht Frankfurt am Main, HRB 51114
>>
>>
>>
>> -----Ursprüngliche Nachricht-----
>> Von: Yves Savourel [mailto:ysavourel@enlaso.com]
>> Gesendet: Mittwoch, 11. Juli 2012 11:07
>> An: 'Arle Lommel'; 'Multilingual Web LT Public List'
>> Cc: 'Fredrik Estreen'
>> Betreff: RE: [ACTION-160] (related to [ACTION-135] too) Summarize
>> specialRequirements
>>
>> Hi Arle,
>>
>> I like this modest proposal.
>>
>> Providing [abc], [^abc] and [a-z] in addition to the enumeration would
>> help.
>> And those are standard notations:
>>
>> Here is a list of many regex features and how they are compatible.
>> http://www.regular-expressions.info/refflavors.html
>>
>> The only issues I would see are:
>>
>> - the ASCII vs Unicode for things like \w \s, etc.
>> We would have probably to decide one way or the other.
>>
>> - the \x{NNN} and \p{...}
>> Which are not always supported all all engines.
>> But maybe we can limit the number of engines to the main ones: Perl5,
>> Java, .NET, Phyton, XML.
>> Then things can be simple.
>>
>> -ys
>>
>
>


-- 
Felix Sasaki
DFKI / W3C Fellow