No spaces in NCName allowed: (re)naming conventions?

name and sid attribute in <rigid_body> are of type NCName, which means they are not allowed to contain spaces or colons, even when you put quotes around it. (unless I misunderstood)

Someone brought up the discussion that 3DS Max names the bones with spaces. The naming becomes a issue when you convert the skeleton into a ragdoll and create rigid bodies for each bone.

By default 3D Studio max creates a ‘biped skeleton’ which has spaces in it.

Do we need to convert them in underscores? How do people deal with this naming issue?

Thanks,
Erwin

From COLLADA 1.41 Specification pdf from COLLADA Overview - The Khronos Group Inc website:

Quote from XML.COM
http://www.xml.com/pub/a/2001/06/06/xsltspec.html

NCName The XSLT specification describes many components of XSLT syntax as “NCNames,” a term that comes from the W3C namespace specification. To simplify a little, an NCName is any name that begins with a letter or underscore and has no space or colon in it (“NC” = “No Colon” ). It can’t have a colon because it may have a namespace prefix added to its beginning, and namespace prefixes themselves are also defined as NCNames. Because the prefix and the part after it are connected by a colon, a colon within these names would confuse a processor trying to figure out where the prefix ended and the other part began, so they both must be “No Colon” names. See also “QName.”

By default 3D Studio max creates a ‘biped skeleton’ which has spaces in it.

Do you mean the ColladaMax does this? In other words the COLLADA documents do not validate against the schema ? That would be a major bug, please report to feeling software bug system, and post the bug # here.

Thanks

No,

This is not about the max exporter. It is about COLLADA not allowing spaces in the name attribute.

Someone didn’t believe the fact that COLLADA names cannot have spaces.
Then he used Max as an example of typical name generation that creates spaces. It was NOT about the Max COLLADA export.

So, everyone fixes their names with underscores? Is there some convention there?
Thanks,
Erwin

Seems to me that ‘name’ attributes should allow any string value, and that they should never be used as identifiers. <node> has ‘name’ and ‘id’, which allows you to escape the id of a node and make it unique without mangling the human readable name.

Hi Erwin,

In ColladaMax, for names, we use the FUDaeWriter::CleanName function that simply takes out all the invalid characters and replaces them with underscores.

3dsMax can generate some pretty fun names too, for materials: like ’ # ‘, ’ ’ and ’ " “”’.

This generates this great, and valid, material library in ColladaMax :slight_smile: :

<library_materials>
  <material id="_" name="_">
    <instance_effect url="#_-fx"/>
  </material>
  <material id="___" name="___">
    <instance_effect url="#___-fx"/>
  </material>
  <material id="______" name="______">
    <instance_effect url="#______-fx"/>
  </material>
</library_materials>

Personally, I have no issue with letting the name attribute contain a pure string, rather than NCName. We do use the name to generate the ids, though, so we’ll keep some code to stick in underscores for invalid characters and since Maya doesn’t accept spaces either, we’ll probably keep ‘CleanName’ around for quite some time.

Sincerely,

I realize that you are saying that the ‘name’ field can not have spaces. However, to be frank, I find this to be absurd.

It is the only name field available in most nodes. It is almost always ‘optional’. I can respect that the ‘id’ or ‘sid’ might need to have naming restrictions on it since it can be thought of as a ‘key’. However, the ‘name’ field is controlled by the user.

I can’t very well tell artists ‘You can’t put spaces in your names’. And, as Erwin points out, by default a 3DSMAX biped skeleton has spaces in all of the node names.

I realize I could do a horrific hack to munge the names going both into and out of my exporter, but there is not going to be any standardization on this kind of a hack.

I would strongly suggest this so called ‘restriction’ be removed from the spec. There is absolutely no reason for it whatsoever. The ‘name’ field is a user supplied attribute and XML doesn’t care what is in that attribute so long as it is in a quotated string.

I have been fairly patient putting up with all of the arcane features of COLLADA but to suggest that a name field, inside a quotated string cannot contain spaces is just ridiculous.

I can think of no rational reason why an optional user supplied annotated name field cannot be an ordinary string value.

I hope this can be corrected, because I currently have no plans of bastardizing all of the name fields in my data files.

Thanks,

John

You are right that the restrictions on the name attribute do not need to be as stringent as for the id attribute. This is a very good feedback and need to be raised as a RFE or bug against the specification.

Here is the place where bugs against the specification are collected:

The Khronos Group · GitHub.

Please take the time to post the request there.

has been submitted here:

http://www.khronos.org/bugzilla/show_bug.cgi?id=9

Thanks Erwin.

Do people really want to have strings as names? In XML Schema, strings can have all manner of characters and whitespace including newlines, carriage returns, vertical tabs, etc. etc…

Perhaps the best data type for name attributes is xs:token? A token is a normalized string that may contain a single space between words.

interesting. a single space is still a bit restrictive I think.

xs:string sounds better then xs:token. We could add additional restrictions there, but that becomes complicated too. I’m curious what others do, and if there is something in between xs:string and xs:token

Only normalizedString. The list of XML Schema Language data types can be found here.

http://www.w3.org/TR/xmlschema-2/#built-in-datatypes

I would also like to point out that changing the type has an impact on backward compatibility. COLLADA 1.4.X will remain backward compatible with COLLADA 1.4.0. Therefore a type like this can become more restrictive and remain compatible, but not less so. What you are proposing breaks backward compatibility I think.

I think you have that backwards. You can make stuff less restrictive not moreso. if you make something less restrictive anything that is more restrictive will still be valid. Therefore this change in types will not break backwards compatibility. ie) a xs:NCName is always a valid xs:string but a xs:string is not always a valid xs:NCName.

-Andy

We are talking about documents not software though… So old software that can handle a NCName will not handle a string.

The way that the 1.4.X schema is evolving means two things to me:

[list=a]
[li] Software must be written to be forward compatible so that new 1.4.x documents do not cause it to crash or fail due to the presence of new optional elements or attributes.[/:m:1gsx71i8][/li][li] Schema changes must not cause existing software to crash or fail due to a change in datatype constraints guaranteed by the 1.4.0 schema.[/:m:1gsx71i8][/list]
[/li]This proposal fails assertion (b) because software written to handle NCName would encounter strings with whitespace and fail to parse them correctly.

I agree that old software written to handle a string can handle a (more restrictive) NCName without problems. Right?

yes, 1.4.0 software cannot handle 1.4.1 documments without having some additional code in it. For example every 1.4.1 documents will have <bind_vertex_input>, and no 1.4.0 application will know how to handle it.

Changing the names to strings will potentially bring the same compatibility issue. So why is it a different issue ?

If the software is forward-compatible then it can handle them just fine.

1.4.0 documents are still valid. You can still create documents that do not export any 1.4.1 specific changes. You can export a document that is “version=1.4.0” and that contains 1.4.1 fixes such as <bind_vertex_input>. The document will validate. The old software will not know how to process the new information, but it can still process the document just the same as it would have without the extra information.

This is a different issue because the schema says a value is an xs:NCName and software can rely on that so as not to parse spaces or it can expect the first character to be a letter, etc. If we change the datatype to xs:token or xs:string then that old software may break. This time the document breaks the software in a manner that the schema promises that it will not break.

I am not sure about that. If a document is 1.4.0, it is supposed to validate against the 1.4.0 schema, which does not contain <bind_vertex_input>.
In other words, I thought that a 1.4.0 document that contains 1.4.1 elements is not valid.

This is a different issue because the schema says a value is an xs:NCName and software can rely on that so as not to parse spaces or it can expect the first character to be a letter, etc.

I understand. An application that received a 1.4.1 element that does not exist can go ahead and ignore it. But if we change the type of an existing element, the application may break.

This old (1.4.0) schema no longer defines the COLLADA namespace (http://www.collada.org/2005/11/COLLADASchema). The 1.4.1 schema does.

The reason this is valid is because the 1.4.0 schema is superceded by 1.4.1. If you have a document that refers to the COLLADA namespace for validation it will access the 1.4.1 schema via the Internet. The only way you can attempt to validate against the old 1.4.0 schema is if you have your own local copy of it.

Any valid 1.4.[01] instance document will validate against the current schema (1.4.1).