Page 2 of 2 FirstFirst 12
Results 11 to 18 of 18

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

  1. #11
    Member
    Join Date
    Dec 2004
    Location
    SCEA, Foster City
    Posts
    36
    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

  2. #12
    Senior Member
    Join Date
    Aug 2004
    Location
    California
    Posts
    771
    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.

  3. #13
    Senior Member
    Join Date
    Aug 2005
    Location
    California
    Posts
    165
    Quote Originally Posted by marcus
    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

  4. #14
    Senior Member
    Join Date
    Aug 2004
    Location
    California
    Posts
    771
    Quote Originally Posted by alorino
    I think you have that backwards... ie) a xs:NCName is always a valid xs:string but a xs:string is not always a valid xs:NCName.
    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:
    1. 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]
    2. 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]

    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?

  5. #15
    Senior Member
    Join Date
    Jul 2004
    Location
    Santa Clara
    Posts
    356
    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 ?

  6. #16
    Senior Member
    Join Date
    Aug 2004
    Location
    California
    Posts
    771
    Quote Originally Posted by remi
    yes, 1.4.0 software cannot handle 1.4.1 documents without having some additional code in it.
    If the software is forward-compatible then it can handle them just fine.
    Quote Originally Posted by remi
    For example every 1.4.1 documents will have <bind_vertex_input>, and no 1.4.0 application will know how to handle it.
    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.
    Quote Originally Posted by remi
    Changing the names to strings will potentially bring the same compatibility issue. So why is it a different issue ?
    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.

  7. #17
    Senior Member
    Join Date
    Jul 2004
    Location
    Santa Clara
    Posts
    356
    Quote Originally Posted by marcus
    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>.
    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.

  8. #18
    Senior Member
    Join Date
    Aug 2004
    Location
    California
    Posts
    771
    Quote Originally Posted by remi
    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>.
    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.
    Quote Originally Posted by remi
    In other words, I thought that a 1.4.0 document that contains 1.4.1 elements is not valid.
    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).

Page 2 of 2 FirstFirst 12

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •