It is allow using collada specification to write files that are syntactically 100% collada 1.4.x compliance, but that are a subset of the grammar?
I am not sure what you mean, but in order to test if a COLLADA file is compliant you have a two major tools available:
- XML validator. You can use any XML validator (like XMLSpy, or embedded in libraries such as libXML2) to validate a COLLADA document. This will check for all that we could express in the Schema language.
- Coherency test: this is a set of conditioners that will check for consistency/coherency of the document. This covers for the part of the specification that cannot be embedded in the schema. (for example, is the count parameter matches with the number of elements). We are adding conditioners to this test each time we find an implementation problem.
If you find out that some tools are violating any of the above tests, please immediately report bugs to the tool developer.
Say for example changing the extension from xml, or dae to something else.
.dae is the extension chosen for COLLADA documents. You can also use .xml, since COLLADA documents are XML documents, but it is always more convenient to use the dae extension to know upfront what the file may contain.
The reason I say this is because I had found that plugging makers for popular modeling packages violates Collada specifications.
As incredible as it may be, some do not read the specification at all ! I found out that some do reverse engineering on files exported by their favorite tool, not even checking that the document validates, propagating errors.
So it is really important to chase down all those implementations, and help them to fix the issues. This is why the coherency test is very important in my opinion, since this provides with an easy way for everybody to test, without any doubts.
Of course, the main way to get all those implementation and quality issues solved is to find and report bugs, and to follow up with vendors very regularly to make sure those are fixed. This is what SCE focus in on, and we will keep doing this until the level of quality is good.
It appears that Fcollada is more strict and compliance than Collada DOM, for what I can see collada Dom is a wrapper over XML with not type validations of any kind.
You can compile the DOM so that it will use libXML2 to validate the data against the schema every time it is loaded. I do not know the details but I was told it is easy.
Your point though, is that FCOLLADA and COLLADA-DOM are different. FCOLLADA has a higher level of abstractation, and make it easier for programming import/exports, but the COLLADA-DOM gives you more control, and is a lot closer to the schema, since its front-end is generated automatically from the XML Schema.
It may sound a triviality, but for example if I export a cube from XSI, I can load it in Max but it comes with a whole set of other things, like camera, light, procedural model, etc.
If I experts a cube from Max then XSI collada do not understand the format.
I am not sure I understand what the problem is ? You export a cube from Max in COLLADA and XSI cannot load it back ?
There are issues that we are getting fixed, but they concern advanced features, for most users, the interchange between MAX, Maya, and XSI works perfectly .
And I give up on blender, blender exported files are not collada compliance at all.
That is correct, but since Blender is an open-source project, the work in the export/import is done by donating time to this project. They are currently working on animation, but have basic issues with textures. The Physics part works great though, which is more advanced than what 3dsMAx provides at the moment. I guess my point is that it is up to the community to help with the development of the Blender plug-in
So for me saying that my library supports Collada will be a cause for debates, each time some one try to load a file with a package that does not support the data. Since I am an underdog I do not want to go into debates and explanation. But if the file have a different extension I do not have to explain anything, It will be collada as long as the package plug-in is 100% collade compliance. And it will be upto the user to rename it to DAE.
That is why we have made the coherency test available, which BTW now includes the XML validation. You now have a good way to test the data, and close debates.
It is possible that I just do not understand Collada but I had some sample file that I had created and I can post a link, perhaps some body would like to test then with this packages and maybe tell me if I am doing something wrong.
They go from a simple a cube to medium complexity to fairly complex hierarchies.
Samples are important, and we have neglected that part so far. We have just released 1.4.1 samples, and want to grow a database of sample data. I’ll get someone to contact you to see if you would accept to donate those samples to the community, provided they pass the coherency test !