IDS
IDS copied to clipboard
buildingSMART
IDS file validation issues with schema v0.9
Trying to validate an IDS file (using schema 0.9) via Java, we get the error
no-xsi: The {target namespace} of an attribute declaration must not match 'http://www.w3.org/2001/XMLSchema-instance'.
Eliminating this import:
<xs:import namespace="http://www.w3.org/2001/XMLSchema-instance" schemaLocation="XMLSchema-instance"/>
solves the problem.
See also https://github.com/buildingSMART/IDS/issues/24 and https://github.com/buildingSMART/IDS/issues/55
The problem has been found both on Java and .NET implementation. There's a concern that the initial hope that tooling would be helped by using the standard xml types does not yield benefits.
The combination of namespaces is valid XSD; not all tools support it. We will create documentation on how to deal with it.
Any timeframe in which we can expect this documentation? It would be great to know which approach to take.
- change the namespace of xs: to ids:
- generate your classes
- change the namespace back from ids to xs for the xsd components
The combination of namespaces is valid XSD; not all tools support it.
It is perfectly fine to have multple namespace indeed. But this is something else. The curent IDS implementation uses typycal constructs that are normally used to validate a XSD. That is really confusing and IMO not intended to be used in XML.
There are a couple of signals to take into consideration:
- Multiple languages and frameworks have difficulty to deal with it
- As a human it is very hard to get your head around the fact that XMLSchema-instance is used to verify XML instead of an XSD
Both 1 and 2 make it more complex than needed and could have a negative impact on the adoption of IDS by the industry.
change the namespace of xs: to ids: generate your classes change the namespace back from ids to xs for the xsd components
If this imposed on developers who must interact with IDS, then I think the wrong decision is made. I have worked with XML and XSD quite extensively in the past. I do even agree that it should be possible. But knowing that multiple languages and frameworks do not support this out-of-the-box and that it causes additional cognitive load on the people working with this.... This to me really is a signal to rethink the current implementation.
There's a concern that the initial hope that tooling would be helped by using the standard xml types does not yield benefits.
I share that concern. I even think it will work against IDS to re-pupose standard XSD types in your XML.
Also I would be happy to help!
As a human it is very hard to get your head around the fact that XMLSchema-instance is used to verify XML instead of an XSD
+1 - the use of XSD 'design-time' minoccurs / maxoccurs attributes the host the desired behaviour in the 'runtime' specification has always struck me as both conceptually wrong, and introducing unnecessary complexity in tooling, authoring, parsing and execution of the IDS, when all that's needed is a enumeration of Required/Prohibited/Optional etc.
Even if the thinking was this could also be extended for 'aggregate' restrictions in future (e.g. "There must be exactly 10 elements" => minoccurs=10 maxoccurs=10) ... it still feels semantically wrong, and won't support more sophisticated aggregates.
I would like to come to an agreement around this. Worth discussing in the calls.
I think most implementers agree that the use of the xs namespace in our implementation was not ideal, but most implementers have a working solution for 1.0 that would be a waste of efforts to change.
The proposed solution is to keep this solution for 1.0 and discuss changes and improvement to future versions. This would mean to keep this issue open but retarget it for the next version. The audit tool helps to enforce the agreed cardinality constraints for optional, required and prohibited.