This document:Public document·View comments·Disposition of Comments·
Nearby:Efficient Extensible Interchange Working Group Other specs in this tool
Quick access to LC-2103 LC-2104 LC-2105 LC-2106 LC-2107 LC-2108 LC-2109 LC-2110 LC-2130 LC-2132 LC-2133 LC-2164 LC-2165 LC-2166 LC-2167 LC-2168 LC-2169 LC-2170 LC-2171 LC-2172 LC-2173 LC-2174 LC-2175 LC-2176 LC-2177 LC-2178 LC-2179 LC-2180 LC-2181 LC-2182 LC-2183 LC-2184 LC-2185 LC-2186 LC-2187 LC-2188 LC-2189 LC-2190 LC-2191 LC-2192 LC-2193 LC-2194 LC-2196 LC-2197 LC-2198 LC-2227 LC-2248
Previous: LC-2193 Next: LC-2198
3) DataTypeRepresentationType question I would like a confirmation of the current DataTypeRepresentationType behaviour. Let's have a schema with the following attribute definition: <xs:attribute name="test" type="xs:string"/> In that case, the only way to change the encoding for @test1 values with the DataTypRepresentationType feature is to redefine xs:string which may have great impact. If we only want to change the @test values with the DataTypRepresentationType feature, we would need to change the schema as follow: <xs:simpleType name="mystring"> <xs:restriction base="xs:string"/> </xs:simpleType> <xs:attribute name="test" type="mystring"/> DataTypeRepresentationType could then be used to redefine mystring. Is it correct? If so, the interoperability will generally be lost, since interoperable DataTypeRepresentationType use is currently limited to XML Schema part 2 predefined types redefinition (end of section 7.4). What about extending that behaviour to all simple types that have been gathered by consuming the schema in use? Is there any rationale behind that specific constraint?