Hi Graham, I think the problem only happens with the namespace handlers but their schemas may be using some syntactically restrained datatypes that come from the blueprint.xsd as well.
This property thing looks like some kind of egg and chicken case. If the property resolution could be made to occur during the xml processing (using the entity resolver), it would have been clean from the xml validation perspective. But if the property resolution occurs above that layer, we have only less optimal solutions. But I think keeping the structure validation and dropping the datatype validation may be a reasonable approach that can keep the existing intuitive XML schemas instead of requiring them to be changed into one with no-datatypes (ie. using all strings) or redundantly typed one (ie. with string and non-string). Regards, Aki 2012/12/10 Graham Charters <[email protected]>: > Hi Aki, > > It seems a shame to have to disable all datatype validation in order to use > property placeholders, but given we already have a mechanism to disable all > validation, this does not seem unreasonable. Is the problem only happening > with the namespace handlers? Personally, I think it would be better to > address the validation problem, rather than lose validation altogether. > > FWIW, property placeholder support never made it into the final spec, and I > think any spec work is likely to go the route of a separate attribute which > would avoid this problem. > > Regards, Graham. > > > On 7 December 2012 11:04, Aki Yoshida <[email protected]> wrote: >> >> Hi, >> I posted this question a month ago, but haven't heard any comments. >> >> Could some comment on this? >> >> Thanks. >> Regards, aki >> >> 2012/11/8 Aki Yoshida <[email protected]>: >> > Currently, you can only disable the entire schema validation by >> > setting directive blueprint.aries.xml-validation to false. >> > >> > I would like to have an option for only disabling the datatype >> > validation while keeping the structures validation. This may sound >> > strange, so I would like to explain the reason. >> > >> > Many namespace handler XML schemas are using some datatypes that >> > constrain their syntactic representation (e.g., int, boolean, enum, >> > etc). For those values, the valid syntactic representation must be >> > available during validation. That means, you can't use the ${...} >> > placeholders for those values. And I find it inconvenient. >> > >> > The options could be: >> > 1. do not allow placeholders for those values >> > 2. change the schemas to use only non-syntactic datatypes like >> > xsd:string >> > 3. change the datatypes to a union of the placeholder looking string >> > and the original type >> > 4. use the current xml-validation directive to disable the whole >> > validation >> > 5. provide an option to only disable datatype validation (that means >> > ignoring datatype validation errors during validation) >> > >> > I prefer option 5 and the others are in the order of 4 > 2 > 1 > 3. >> > >> > Let me know how you think. >> > >> > If we go for option 5, we can modify a minor change in >> > BlueprintContainerImpl to read another directive >> > (blueprint.aries.xml-validation-datatypes) and pass this flag to the >> > Parser's validate method so that it can either ignore datatype >> > validation errors or not. >> > >> > Thanks. >> > >> > aki > >
