많은 xsd 파일로 작업하고 있습니다. xsd : token 및 xsd : string을 기반으로하는 몇 가지 유형 정의가 제한없이 있음을 확인했습니다. 예를 들어xsd : token 또는 xsd : string을 기반으로 유형을 정의하는 이유가 있습니까?
<xsd:complexType name="BaseString">
<xsd:simpleContent>
<xsd:extension base="xsd:token"/>
</xsd:simpleContent>
</xsd:complexType>
이런 종류의 정의가 필요한 이유가 있는지 궁금합니다. BaseString 형식 대신 xsd : token 또는 xsd : string을 사용하지 않는 이유는 무엇입니까? 아이디어가 있으십니까?
아주 좋은 디자인처럼 보일 수는 없지만,이 예제로 우리에게 보여주지 않는 더 넓은 환경에 달려 있습니다.
특수 ID를 정의하는 스키마를 보았습니다. 도메인에 FooObjects이 있다고 가정 해 보겠습니다. 그들은 FooObjectIDs으로 식별됩니다. 종종, FooObjectID은 FooObjectIDType 유형으로 정의됩니다. 그 유형은 차례로 xsd:token 또는 xsd:string의 확장으로 정의 될 수 있습니다. 이 형식은 FooObjectID를 바닐라 문자열과 다른 것으로 (따라서 다르게 처리합니다) 구분합니다.
ID가 실제로 복합 값인 "스마트 ID"인 경우 가끔 표시됩니다. CUST-VA-3391과 같은 모양의 고객 ID를 상상해보십시오. 모든 데이터 관리에서 일반적으로 발견 된 나쁜 디자인은 ID (Virginia 고객 # 3391)에 여러 정보를 인코딩하는 이러한 "스마트 키"입니다. ID와 같은 ID 유형은 (내 경험상) 여기에있는 유형과 비슷하게 보이는 경우가 많습니다.
이 특수한 것과 바닐라 문자열을 구별하기 위해 인공 형식이 추가되었지만, 게으름으로 인해 바닐라 기본 형식 (xsd : token, xsd : string)에서 제한/비 구분이 이루어지지 않습니다.
결론 - 몇 가지 추가 의미 체계로 유형을 지정하기 위해 파생 유형을 부분적으로 작성합니다. 바닐라 문자열이 아니에요. FooObjectID입니다. 그러나 우수 사례는 추가 확장/제한이 적절하다고 제안하는 경향이 있습니다.
도움말의 형식 정의는 xsd : token보다 더 유익한 이름을 지정하여 형식의 의도 된 사용을 문서화합니다. 또한 부적절한 파생 및 대체를 방지하는데도 도움이됩니다 (모자 크기 및 퀴즈 등급은 모두 작은 정수일 수 있지만 실제로는 교환 할 수 없음).
물론 FrobberOfBits가 관찰 한 것처럼 패턴이나 다른 패싯을 사용하여 형식을 더 제한 할 수있는 기회가 종종 있습니다. 표시된 파생과 같은 파생물은 이러한 기회를 놓칠 수 있습니다. 필자는 FrobberOfBits보다 반드시 나쁜 디자인의 징후라고 확신하지 않습니다.
"모자 크기와 퀴즈 등급은 모두 작은 정수일 수 있지만 실제로는 교환 할 수 없습니다"- 훌륭합니다. 그것은 내가 "여분의 의미론을 가진 것들을 묻는"것에 대해 간단한 예제를 통해 만들려고했던 것입니다. – FrobberOfBits
하지만 우리가 프로그래밍 할 때 우리는 모자 크기와 퀴즈 등급 모두에 int를 사용하고 있습니다. 우리는 그들을 구별하기 위해 이름을 사용하고 있습니다. 모든 변수에 대해 유형을 정의하는 것은 적절하지 않습니다. jaxp와 같은 api를 사용하여 xml 용 Java 클래스를 만들 때 문제가 발생합니다. 우리가 자체 정의 된 (예를 들어 baseString) 타입을 기반으로 모자 크기를 정의한다면, 우리는 자체 정의 된 타입을 상속받는 클래스를 가질 것이다. 그러나 xsd : string 또는 xsd : int를 사용하는 경우 클래스의 필드 또는 변수로 사용하게됩니다. – Govan
Govan, 내가 말하는 것은 XSD에서 Java 클래스로의 번역자가별로 영리하지 않다는 것입니다. 그것은 부끄러운 일입니다. 모자 크기와 퀴즈 등급이 XML 문서에서 상호 교환 가능해야한다는 것을 의미하지는 않습니다. –