Re: issue-67 (Re: Comment on ITS 2.0 specification WD)

Hi Yves, Felix, and all,

Now I have browsed through the discussions related to action-189, and 
indeed the new issue 67 will entirely repeat this previous discussion 
and it doesn't add any new evidence to the apparently still unresolved 
concerns.

Given the description of, and in particular the examples, in the 
"Allowed Characters" section of the specification, I would claim that 
most regex engines could be used with the given syntax and the intended 
use cases if we take so-called text-directed engines (aka DFAs).

Therefore, what about simply adding a short paragraph on "processing 
expectations"? Otherwise, I fear that we will also discuss the 
extensions or flavors available in XQuery and XPath on top of the XSD 
regexes... ;-)

Thanks and cheers -- Jörg

On Jan 04, 2013, at 14:14 (UTC+1), Yves Savourel wrote:
> Hi Felix, all,
>
>> I *think* in the discussion around action-189, all the arguments you
>> give below were discussed; Jirka and partially I gave counterarguments,
>> e.g. a counterargument to your SRX example at
>> http://lists.w3.org/Archives/Public/public-multilingualweb-lt/2012Aug/0302.html
>> saying that each XML Schema 1.0 or 1.1 implementation correctly implements
>> the regular expressions we refer to - so no danger for an "SRX situation" here.
>> What is the "new evidence" in your argumentation below? I'm just trying to
>> avoid repetition for whose who followed the previous discussion.
>
> I have no new evidence. In my opinion the old ones are still valid: The RE engines for Java and many other programming languages do not support the same syntax as XSD RE. There are therefore two options for the implementers:
>
> a) Use a RE engine that supports XSD RE: There is at least one in Java, but as an implementer I don't want to have a dependency on yet another component just to support rarely used features when the same functionality could be obtain with the runtime RE engine if a simple sub-set was the prescribed syntax.
>
> b) Create a schema on-the-fly with RE restrictions for the content parts that need to be verified and use an XSD validator to verify those snippets of data. Such solution would complicated to implement and far from efficient.
>
>
>> so no danger for an "SRX situation" here.
>
> Actually we already have the situation: We've implemented Allowed Characters (the use of the RE not just its parsing) in Okapi and we do not use an XSD RE engine. It's a not-completely-conformant implementation and it will stay that way except if there are overwhelming reasons for that component to have a dependency on an XSD RE engine at some point (very unlikely), or if Java suddenly starts to support that syntax.
>
> The main argument is that, while the ITS markup lives in the HTML5/XML world, the consumers of the data categories may have no relations with the XML technology stack. For every other data categories the information we pass to the consumers are simple: number, labels, identifiers: all highly interoperable. Except for Allowed Characters where the information a regular expression. I simply would like to have a RE syntax that is common to most RE engines, not specific to one.
>
> My question is why do you want to make the implementers life more difficult when you can have the same functionality with a more interoperable solution?
>
> Cheers,
> -yves
>

Received on Friday, 4 January 2013 13:45:22 UTC