You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Add support for validation against external schemas #5
Not sure if this belongs here or in java-stix-validator, so sorry if I posted in the wrong place.
If I define a custom ControlledVocabularyType extension as described here and then attempt to validate an instance document which leverages that controlled vocabulary, I get the following error in java-stix-validator:
SAXParseException:
Public ID: null
System ID: null
Line : 3
Column : 70
Message : cvc-elt.4.2: Cannot resolve 'customVocabs:CustomVocab-1.0' to a type definition for element 'stix:Package_Intent'.
It would be nice to provide a function which makes it easy to pass in a directory of schemas to validate a STIX document against and support the validation of third-party extensions.
java-stix-validator uses the validation found in java-stix's STIXSchema object. java-stix-validator is a web app.
The STIXSchema object is appropriately named for the purpose it provides. It's the validator for STIX schema and not other's schemas. The object is a singleton that pulls in the all the schemas -- The reason why they are packaged with the jar. I've gotten emails wondering why the jar is 18 megabytes huge. -- creates a javax.xml.validation.Schema object off them, and from there creates a validator object used to validate documents. I hear you though. If we want java-stix to also be validating other people's schemas the STIXSchema object would need to be modified to take in these additional schemas in addition to STIX's. If I was to do the work, it would probably take couple of hours. A bit more to copy it to both 1.2.0 and 1.1.0 branches, test, and release. Now if you want java-stix-validator, that would be a bit more work as it spins up singletons for java-stix 1.2.0 and 1.1.0 branches on startup. It takes a bit time to load in 165-some schema files. :)
Another thing, the schema location is stripped off documents because you want to use the schema you have and not dynamically pull...
If i were to instantiate STIXPackage.fromXMLString() an AIS STIX package it fails with similar errors. Is there some way this could be supported ? Is the issue related ?
It's related, but not exactly the intention of this issue (it's something that we could fix, though). The issue being discussed is more about custom vocabularies, not custom marking types; it's possible the same solution could work for both.
Activity
nemonik commentedon Jul 30, 2015
java-stix-validator uses the validation found in java-stix's STIXSchema object. java-stix-validator is a web app.
The STIXSchema object is appropriately named for the purpose it provides. It's the validator for STIX schema and not other's schemas. The object is a singleton that pulls in the all the schemas -- The reason why they are packaged with the jar. I've gotten emails wondering why the jar is 18 megabytes huge. -- creates a javax.xml.validation.Schema object off them, and from there creates a validator object used to validate documents. I hear you though. If we want java-stix to also be validating other people's schemas the STIXSchema object would need to be modified to take in these additional schemas in addition to STIX's. If I was to do the work, it would probably take couple of hours. A bit more to copy it to both 1.2.0 and 1.1.0 branches, test, and release. Now if you want java-stix-validator, that would be a bit more work as it spins up singletons for java-stix 1.2.0 and 1.1.0 branches on startup. It takes a bit time to load in 165-some schema files. :)
Another thing, the schema location is stripped off documents because you want to use the schema you have and not dynamically pull...
ragogitpub commentedon Nov 6, 2017
Hello
If i were to instantiate STIXPackage.fromXMLString() an AIS STIX package it fails with similar errors. Is there some way this could be supported ? Is the issue related ?
gtback commentedon Nov 7, 2017
It's related, but not exactly the intention of this issue (it's something that we could fix, though). The issue being discussed is more about custom vocabularies, not custom marking types; it's possible the same solution could work for both.
@nemonik, any ideas how hard this would be?