Re: [jakartabatch-dev] job xml XSD 'version' update (to 2.0) proposed

["Scott Kurz" <skurz@xxxxxxxxxx>]

Michael,

Thanks for giving it a look. Turns out I was wrong: we never did ship the XSDs in the API jar, though we could.

I wanted to at least get a proposal out there to keep discussion moving and was stumbling on the questions of whether we should ship the common https://jakarta.ee/xml/ns/jakartaee/jakartaee_9.xsd file as well.

Another way, (I'm thinking now), to sidestep that question would be to forget including the common XSD and define our own "job-versionType" similar to the common "dewey-versionType" (it's just a simple xsd:token restriction).

Assuming that as a solution, I'm fine putting the XSDs in. In jbatch we put them in /xsd off of the JAR root..... I suppose that's as good as any path.

------------------------------------------------------
Scott Kurz
WebSphere Batch and Developer Experience
skurz@xxxxxxxxxx
--------------------------------------------------------

Michael Minella ---06/22/2020 03:41:21 PM---Hi Scott, The version stuff all makes senes to me. I do have one question though, what is the motiva

From: Michael Minella <mminella@xxxxxxxxxx>
To: jakartabatch developer discussions <jakartabatch-dev@xxxxxxxxxxx>
Date: 06/22/2020 03:41 PM
Subject: [EXTERNAL] Re: [jakartabatch-dev] job xml XSD 'version' update (to 2.0) proposed
Sent by: jakartabatch-dev-bounces@xxxxxxxxxxx

---

Hi Scott,

The version stuff all makes senes to me. I do have one question though, what is the motivation for removing the XSDs from the API JAR? Given the requirement to validate the XML on startup, any implementation would be required to ship those XSDs so it feels like an unnecessary duplication across all the implementations. It also introduces the risk that the XSD could evolve from what the spec requires. I'd vote to leave it in.

Thanks,
Michael

---

From: jakartabatch-dev-bounces@xxxxxxxxxxx <jakartabatch-dev-bounces@xxxxxxxxxxx> on behalf of Scott Kurz <skurz@xxxxxxxxxx>
Sent: Monday, June 22, 2020 1:34 PM
To: jakartabatch developer discussions <jakartabatch-dev@xxxxxxxxxxx>
Subject: [jakartabatch-dev] job xml XSD 'version' update (to 2.0) proposed 
 
Let me run this by the list here.

Though I'd mentioned the change of our job XML's schema targetNamespace (back in https://www.eclipse.org/lists/jakartabatch-dev/msg00080.html), it hadn't crossed my mind to update the "version" attribute on the <job> root element. 

As it turns out, the other Jakarta EE 9 specs are incrementing these version numbers to match the spec version: https://jakarta.ee/xml/ns/jakartaee/#9

So to follow this pattern, we should also make a change like: https://github.com/jakartaee/jakarta.ee/pull/812/files to bump up our version to "2.0".

So the net change for a typical job XML would be something like:

-<job id="job_batchlet_1step" xmlns="http://xmlns.jcp.org/xml/ns/javaee" version="1.0">
+<job id="job_batchlet_1step" xmlns="https://jakarta.ee/xml/ns/jakartaee" version="2.0">

I'd be surprised if anyone thinks we should go in a different direction than the platform, but please speak now if there are any concerns.
-----

A couple other notes:

1. Note I included the common jakartaee_9.xsd file to use the common platform 'dewey-versionType'

2. I'm also planning to remove the XSDs from the API JAR (to avoid duplication in terms of which jakarta spec project "owns" the source of the .xsd... though they are effectively still duplicated in the spec). I'd suggest that impls that want them packaged can package them in the impl, rather than relying on them packaged in the API.

3. If you're familiar with the Eclipse Transformer project, you'll know its intention is to help migrate from Jakarta EE 8 -> Jakarta EE 9, e.g. helping with the javax.* => jakarta.* package conversion.
I opened up an issue here https://github.com/eclipse/transformer/issues/73 to address the batch job XML (and batch.xml) migration use cases.

Now we just need someone to implement that ;) 
----

Finally.. just a quick note... the spec does say job XML has to be schema-valid (in case anyone was wondering) ...(not sure if the TCK enforces though).

The batch runtime must perform schema validation during JobOperator start processing before the start method returns to the caller.

Thanks,
------------------------------------------------------
Scott Kurz
WebSphere Batch and Developer Experience
skurz@xxxxxxxxxx
--------------------------------------------------------_______________________________________________
jakartabatch-dev mailing list
jakartabatch-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartabatch-dev