[wildfly-dev] Management Parser Versioning

[Darran Lofthouse]

Thinking about future XML changes, once the parser is forked I think we 
can also relax how we add new optional attributes and elements to the 
schema.

As I see it our main commitment is: -

* XML that is valid according to the schema should parse without error. *

I say 'should' as I believe in some cases documentation is relied upon 
to describe valid combinations.

* The XML we write must be valid according to the schema. *

Don't see any justification for not following that one.

* Parsers can be tolerant to XML that is technically invalid. *

e.g. we are not big on enforcing sequence ordering.

So lets say we have a release that contains a 4.0 version of the schema 
I think if in version 4.1 of the schema we add an optional attribute or 
element we can just add support for that attribute or element to the 
existing parse method.

Of course if the new attribute or element is required then we will need 
to switch to something version specific to avoid rejecting previously 
valid configuration.

I know this is a long way off but I only raise this now as I realise 
this has already happened where a new optional element has been added to 
the schema.  Technically if we were strict about it the code is wrong 
but the scenarios where it is going to break for someone are quite 
contrived and I think this fits with tolerant parsing and we will 
automatically fix on the next write.

Regards,
Darran Lofthouse.


On 22/04/15 13:30, Brian Stansberry wrote:
> That's fine with me.
>
> On 4/22/15 6:20 AM, Darran Lofthouse wrote:
>> Working with the parsers for the core config has become increasingly
>> cryptic, we are now at the point where we have three different major
>> versions which diverge and converge as we work on them.  Most recent
>> changes have resulted in large sections of the config converging for 1.x
>> and 3.x leaving 2.x independent.
>>
>> So that I can add references to Elytron I am starting to add support for
>> version 4.
>>
>> One think that I have learned is that each major version tends to belong
>> to one branch of the codebase, all changes to that version happen on
>> that branch first: -
>>
>>     1.x - Maintained only for EAP
>>     2.x - WildFly 8.x branch
>>     3.x - WildFly Core master branch
>>
>> I would expect if further changes are made to core for WildFly 9
>> releases we will end up with 1.x branch of core and and 4.x version of
>> the schema will be owned by the master branch.
>>
>> To make things less cryptic I am proposing that until we find a better
>> solution for all subsequent major schema versions we just fork the
>> parser and all related classes.
>>
>> This will simplify the code being modified for the upstream development.
>>
>> Forward porting parsing changes will also become a simple copy and paste.
>>
>> For the current cryptic approach I think almost every engineer (and I am
>> finding it really hard to think of exceptions) that has worked in-depth
>> in this area has introduced at least one bug and I don't think the test
>> coverage is high enough to protect against this.
>>
>> Regards,
>> Darran Lofthouse.
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>