Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-platform-dev] Fair rules for "optional"TCKcompliance tests

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.




From: Mike Milinkovich
Sent: Monday, July 6, 2020 20:23
To: jakartaee-platform-dev@xxxxxxxxxxx
Subject: Re: [jakartaee-platform-dev] Fair rules for "optional"TCKcompliance tests


On 2020-07-06 1:47 p.m., Werner Keil wrote:

I thought so, but it will be interesting to see how the two other mentioned users of the EFSP use that because both SparkPlug and Asciidoc are more protocol definitions and not API centric. Especially Asciidoc describes itself as a text document format, so it’s like JSON or XML and has no similarity with e.g. the JAXB, JSONB or JSONP specs under Jakarta EE.

Some of these definitions were pretty much carbon-copied from the Java EE stack and JCP and now we see other standards use them that have more in common with those defined at OASIS or W3C than the JCP or Jakarta specs.

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.



+1.613.220.3223 (m)


Back to the top