Difference between revisions of "Datatypes R2 Issue 32"
Line 21: | Line 21: | ||
NOTE: “CS is represented by both Element and Attribute forms. In the Element form, the type is represented by an XML element whose name is determined by the context in which it is used” -> THIS IS NOT TRUE – Element form is not allowed. fix it. | NOTE: “CS is represented by both Element and Attribute forms. In the Element form, the type is represented by an XML element whose name is determined by the context in which it is used” -> THIS IS NOT TRUE – Element form is not allowed. fix it. | ||
+ | == Status == | ||
+ | |||
+ | Approved | ||
== Links == | == Links == | ||
Back to [[Data Types R2 issues]] | Back to [[Data Types R2 issues]] |
Revision as of 06:13, 3 May 2007
Data Types Issue 32: cd.code rules
Introduction
Whether cd.code can contain spaces is unclear. The schemas for the XML ITS restricts it to not have spaces. The abstract specification says nothing
proposal: clarify that CD.code can contain spaces or any other unicode text. Constrain this to contain no spaces for cs.code. note in the XML ITS that spaces must be conserved in the cd.code.
This change is backward compatible (just clarifies existing practice)
Discussion
Thurs Q3 may 2006: approved in committee: Outcome: abstract explicity says that cd.code is allowed to contain spaces. XML issues to be addressed (constrain cs more tightly where appropriately). Use xs:whitespace=preserve in the schemas on attributes. Update ITS to say that whitespace is preserved in cs.code. NOTE: “CS is represented by both Element and Attribute forms. In the Element form, the type is represented by an XML element whose name is determined by the context in which it is used” -> THIS IS NOT TRUE – Element form is not allowed. fix it.
Status
Approved
Links
Back to Data Types R2 issues