Documentation complete. Review welcome, in particular the examples are a bit ropy.

All done, including a full stack test

Documentation pending.

Thanks.

> Complex parsing is usually a technical debt later

Motivation in itself !

I think it's cleaner to just expose it. Complex parsing is usually a technical debt later and I don't think this is really about implementation, it's about deployment. The two-phase resolution has to be a documented behavior because that's how it's supportable as a means of making decisions in conditions.

Implementation done, but now that it comes to changing the configuration I have an architectural/philosophical question for  (or anyone else who is still listening)

• The code as currently checked in expects an external setting of the pre resolve Attribute IDs (by the service strategy).  I think that this makes sense because it is all to do with how (our implementation of) attribute resolution works.

• Nonetheless we both think that the best way to indicate a pre-resolved attribute definition is via an attribute on the <AttributeDefinition>

My plan had been to capture the setting of this in the parser and to pass the list thus generated into the AttributeResolver. This actually keeps everything away from the API - the only externally visible change is to the schema. This again is in keeping with my view that the pre-resolution is about the IMPLEMENTATION of attribute resolution.

But another way to look at this is to make the property "candidate for presolution" to be a thing to do with the Attribute Definition (and thus a setter/getter on the aposite API). This makes the parsing much easier and removes the need for any externally visible changes to the attribute resolver implementation (it can just look at all the attribute definitions and suck out the preresolve ones)

But despite being an easier for some reason this doesn't somehow feel "right". This may just be because of the way I came into thinking about this.

So I'm looking for input.