extension specifications require namespace clarification

[pencerw]

No description provided.

[martinweismann]

There are two things to consider:

1. https://github.com/3MFConsortium/spec_core/blob/master/3MF%20Core%20Specification.md#231-support-for-versioning-and-extensibility could use some clarification or an example.
   (e.g. https://github.com/3MFConsortium/spec_core/blob/master/3MF%20Core%20Specification.md#appendix-b2-3mf-metadata-example already shows the use of a different namespace)
2. The illustrations of the XSD-schemata in all extension specification show their attributes and element-names without a namespace prefix: e.g.
   
   from the slicespec
   shows all core-spec attributes of and the slicespec attribute "slicestackid" without denoting/respecting different namespaces. This is a bit misleading and takes a way the focus from the actual addition to object, in this example only the slicestackid and the meshresolution.

   Potential resolutions for 2. could be
   a) change images to something like this
   from the beamlattice spec with an explanation of the namespace-shorthand "b" (which could of course be any string).
   This would clutter images like this with lot's of "b", though:
   .

   b) make a general explanation of these representations of XSD-schema objects.

[pencerw]

@martinweismann Do I recall correctly that at the Seattle F2F we had a discussion about providing a fully merged XSD schema for all specs? It seems like if we were to provide that, then would that offer an opportunity to include namespace shorthands for each of the extension specifications? In other words, all screenshots could be taken from the merged schema and would therefore include shorthands as defined in that schema.

If it is feasible to do this, then perhaps we could:

• Create a new repo called schemas
• Remove the schemas from the individual specification markdown documents, move them to the schemas repo, and link to that repo from each of the specification documents (this might be controversial to anyone who wants an easily printable package...)
• Create a merged schema in the schemas repo
• Make a note in the "Document Conventions" section of the Core Spec (which is linked to from the extension specs; the note could also be duplicated in each of the extension specifications) that all screenshots are taken from the merged schema
• Profit!

I may be misunderstanding how a merged schema would work, so please forgive me. I also seem to recall that there was some discussion of how difficult it would be to create such a merged schema, so the point may be moot.

[JimZuber]

Spencer, QualityLogic developed a consolidated 3mf schema to validate test cases as part of our test case development work with HP. We included more constrained versions of this consolidated schema as part of the the test suites we are porting for the Consortium. So, yes it is very feasible to put together a consolidated schema and I would say that 95% of the work is already done. We did run into a few places where we needed to comment out the "any" element statement as XMLSpy was giving us ambiguous reference warnings. I am sure solutions to these issues can be found. As to the wisdom of maintaining both the decoupled and consolidated schemas, that is a separate topic. Happy to share the consolidate schema work we have already done if the consortium decides to go down this path. Regards, Jim

…

On Fri, Sep 14, 2018 at 5:10 AM Spencer Wright ***@***.***> wrote: @martinweismann <https://github.com/martinweismann> Do I recall correctly that at the Seattle F2F we had a discussion about providing a fully merged XSD schema for all specs? It seems like if we were to provide that, then would that offer an opportunity to include namespace shorthands for each of the extension specifications? In other words, all screenshots could be taken from the merged schema and would therefore include shorthands as defined in that schema. If it is feasible to do this, then perhaps we could: - Create a new repo called schemas - Remove the schemas from the individual specification markdown documents, move them to the schemas repo, and link to that repo from each of the specification documents (this might be controversial to anyone who wants an easily printable package...) - Create a merged schema in the schemas repo - Make a note in the "Document Conventions" section of the Core Spec (which is linked to from the extension specs; the note could also be duplicated in each of the extension specifications) that all screenshots are taken from the merged schema - Profit! I may be misunderstanding how a merged schema would work, so please forgive me. I also seem to recall that there was some discussion of how difficult it would be to create such a merged schema, so the point may be moot. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#23 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AB4DLdtSzLvQOqbPmfFjgTLFxBrc2a5Dks5ua5yggaJpZM4WjE_B> .

[pencerw]

@JimZuber ah, yes! I think I remember you mentioning this.

@martinweismann maybe let's chat about this on this week's call?

[martinweismann]

@pencerw :
Such a resolution would be great. I have played around a bit with linking the different XSDs into one, but cannot quite get it to the desired result.
@JimZuber : could you share the consolidated version?

ACTION: @kris: Will try out getting desired images of combined XSD-schema

[martinweismann]

From @JimZuber :

Attached is the consolidated schema that I put together when developing test cases for HP so that we could validate our test cases. qli_3mf.xsd is the root schema to load. The OPC schemas are in the zip but not really part of the consolidated schema. There are a few embedded comments in the schema where I had to work around problems getting the schema to validate.

Note that the one issue I ran into needing to comment out the "any" element in CT_Resourses might be resolved by restructuring CT_Resources along the lines of the recent update to the Core schema...

I hadn't thought of nesting a choice in side a sequence, so that might address the issue.
At any rate, hope this is useful. The consolidated schema should include all the latest changes to the 3MF specifications and all the currently released extensions.
Consoldated_3mf_Schema_091918.zip

Thanks

[JimZuber]

Just a follow up note on the consolidated schema I put together. There are some tricky issues with the consolidated schema. For instance, the consolidated schema has vertices and triangles as mandatory elements. However, if beamlattice is present in the mesh, triangles are conditionally optional. My goal for the consolidated schema was to use it for validation of test cases and we were not working with beamlattice, so I wanted it to trigger a schema violation if triangles were missing. Another instance is that instance UUID is a mandatory attribute of the build element unless it is in a non-root model part. I left the UUID as optional in the build element to avoid getting lots of false positive schema violations in non-root models. These are all judgement calls based on how you see the consolidated schema being used. Regards, Jim

…

On Fri, Sep 21, 2018 at 6:13 AM Martin Weismann ***@***.***> wrote: From @JimZuber <https://github.com/JimZuber> : Attached is the consolidated schema that I put together when developing test cases for HP so that we could validate our test cases. qli_3mf.xsd is the root schema to load. The OPC schemas are in the zip but not really part of the consolidated schema. There are a few embedded comments in the schema where I had to work around problems getting the schema to validate. Note that the one issue I ran into needing to comment out the "any" element in CT_Resourses might be resolved by restructuring CT_Resources along the lines of the recent update to the Core schema... [image: image] <https://user-images.githubusercontent.com/30837766/45883176-9c5c7980-bdb0-11e8-9805-2a54fb4433a4.png> I hadn't thought of nesting a choice in side a sequence, so that might address the issue. At any rate, hope this is useful. The consolidated schema should include all the latest changes to the 3MF specifications and all the currently released extensions. Consoldated_3mf_Schema_091918.zip <https://github.com/3MFConsortium/spec_core/files/2405461/Consoldated_3mf_Schema_091918.zip> Thanks — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#23 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AB4DLbAfSLF9oa-ojgg-hRpxQGxeNW5Yks5udOYQgaJpZM4WjE_B> .

[sranawade]

I see that :
It is RECOMMENDED that producers of 3MF Documents use the following part naming convention:
The 3D Model part name SHOULD contain two segments, the first being "/3D/" and the second with the extension ".model" on the last segment, for example "/3D/3dModel.model".

Is it a must to have a 3D Model part name as 3dmodel.model ??
Or I cane name it to anyfile.someotherextension and keep this file under /3D/ directory?

Basically 3dmodel.model is a must have naming conversion , or it is a should have conversion, which could be changed ?
please reply as its very urgent issue.

[jordig100]

Hi @sranawade, using the following path is a recommendation and it good practice to help when trying to debug files by having a consistent naming.

But being strict what defines the root model file path and name is the following relationship, where the relationship type identifies it:

<Relationship Target="/3D/3dmodel.model" Id="rel-1" Type="http://schemas.microsoft.com/3dmanufacturing/2013/01/3dmodel"/>

However if you have the change to use the recommended naming my advise would be to use it.

[sranawade]

@jordig100

Thank you for the detailed information.
To brief about topic: I asked this question , because I have some CAD files ( more specifically CATIA v4 files) wich already has .model extension to it.
Now my CAD tool is getting confused because of .model extension for 3mf file and CATIA file.
So I wanted to know, while creating .3mf file from my CAD tool , can I name .model file to name.someextension?

What will be the impact of it, while 3d printer prints it?

[jordig100]

@sranawade
What you are suggested is valid. Nevertheless I'd recommend to select an extension which is meaningful, like "3dmodel" or similar.
What I suggest you to look a the new test suite just made available where you can find a great number of test files to test importing from an application or printer. We'll announce it in short.

https://github.com/3MFConsortium/test_suites

You can look at the test specification for the test P_???_0325 Two Segment Model Part Name. You could find it in several tests suites, for the different combinations of extensions. You can take the one in the suite3_core: P_XXX_0325_01.3mf.

In this file it was renamed to "part". You there are two relationships modified: the one in root and the one in _rels.

[jordig100]

@martinweismann, the merged shema we use for testing is very strict. It has all the "any" removed so it test only for what it is defined. However it you use in in a final product, it would reject content from an unknown extension.
So I think it's usage gets limited to testing.

[martinweismann]

@jordig100 please close once you publish your new issue about this.