| Re: [jakartaee-platform-dev] Fair rules for "optional"TCKcompliancetests |
What Asciidoc (the previous definitions as there seems to be no published EFSP Version yet) and SparkPlug have in common, is that they have far more "optional" than required parts, therefore it is hard to imagine too many vendors would create an implementation that does not support the Asciidoc Header although that’s an optional part of the spec. I don’t see anything in David’s proposed rephrase that would make it more difficult for them, but since a Glassfish-neutral TCK is not realistic before Jakarta EE 10, I guess it is not that urgent. Werner From: Werner Keil If the topic is "What can be generalized in the EFSP" vs. "What should be more specialized in an individual process" then I would say this discussion is very much on topic. SparkPlug has a few distant similarities to at least Jakarta Messaging, therefore not really surprising that it works well. For Asciidoc on the other hand, it starts with the term "implementation" which can’t even be seen there strictly speaking. Other examples would be UCUM (not standardized by an industry body but it is accepted by HL7 and others) or the OASIS ODF. Asciidoc does not get implemented, it’s interpreted, converted or transformed into something else, therefore "implementing" may not be totally wrong but it is very imprecise for these types of standards. Werner From: Mike Milinkovich On 2020-07-06 1:47 p.m., Werner Keil wrote:
We are getting off topic here, but I can say "so far, so good" with respect to Sparkplug's adoption of the EFSP. Too early to tell with AsciiDoc at this point. -- Mike Milinkovich Executive Director | Eclipse Foundation, Inc. mike.milinkovich@xxxxxxxxxxxxxxxxxxxxxx @mmilinkov +1.613.220.3223 (m) |