Hide Forgot
NMTOKEN type in XSD prevents using of properties in switchyard.xml, because NMTOKEN does not allow using of $, {, } that are needed for properties, see http://www.schemacentral.com/sc/xsd/t-xsd_NMTOKEN.html. I have found this in JCA binding, but core module also contains some XSDs, DTDs containing NMTOKEN. See ResourceAdapter and Endpoint in http://goo.gl/EmTdKn. NMTOKEN should be replaced with something else or properties should be evaluated before XSD validation.
To clarify here, you are saying that property substitution does not work for attributes with a type of NMTOKEN, correct? NMTOKEN in the schema doesn't prevent a user from using a property in other attributes or elements. The exposure here is very small, so giving dev nack for FSW 6. We should evaluate the use of NMTOKEN in the future though to determine if fields which use it should support property substitution.
If I define the property in resourceAdapter element: <jca:resourceAdapter name="${resourceAdapter:hornetq-ra.rar}"/> then during compilation this error occurs: [ERROR] Failed to execute goal org.switchyard:switchyard-plugin:1.1.0.M3-redhat-2:configure (default) on project jca-bean-service-test: SWITCHYARD011602: Model [org.switchyard.config.model.switchyard.v1.V1SwitchYardModel] is invalid: cvc-datatype-valid.1.2.1: '${resourceAdapter:hornetq-ra.rar}' is not a valid value for 'NMTOKEN'. -> [Help 1] I think that the exposure is not very small since changing of JCA resource adapter (hornetq, activemq, etc.) is quite real use case.
grep shows following schemas are using NMTOKEN in SY core/components: core/sca-binding-jms-1.1-csd05.xsd core/sca-binding-jca-1.1-cd04-rev2.xsd components/jca/jca_1_0.xsd, jca_1_1.xsd, jca_2_0.xsd I believe sca-binding-{jms,jca} is not used for actual SwitchYard configuration, and JCA is using NMTOKEN without strong reason (just because it is copied from sca-binding-jca). Following 3 attributes are NMTOKEN in JCA schema: binding.jca/inboundConnection/resourceAdapter/@name - RAR archive name binding.jca/inboundInteraction/endpoint/@type - endpoint class name binding.jca/outboundInteraction/processor/@type - processor class name I don't think there's any problem to relax those 3 from NMTOKEN to String.