XML 스키마(XSD)를 정의할 때 '그룹' 요소를 '선택'하는 것이 유효한가요?

StackOverflow https://stackoverflow.com/questions/101338

  •  01-07-2019
  •  | 
  •  

문제

XML 스키마(XSD)를 정의할 때 '선택' 또는 '그룹' 요소를 갖는 것이 유효한가요?

즉.다음은 유효합니다

<xs:complexType name="HeaderType">
  <xs:sequence>
    <xs:element name="reservation-number" type="ReservationNumberType" minOccurs="1" maxOccurs="1" nillable="false" />
    <xs:choice minOccurs="1" maxOccurs="1">
      <xs:group ref="ReservationGroup" />
      <xs:group ref="CancellationGroup"/>
    </xs:choice>
  </xs:sequence>
</xs:complexType>

예를 들어 XML 메시지는 신규 예약이나 기존 예약 취소를 나타낼 수 있습니다.

예약에 대한 메시지인 경우 ReservationGroup 그룹에 정의된 모든 요소를 ​​포함해야 합니다.

취소인 경우 CancellationGroup 그룹에 정의된 모든 요소를 ​​포함해야 합니다.

어떤 이유에서인지 내 XML 편집기(Eclipse)는 이것을 좋아하지 않지만 그 이유를 나타내지는 않습니다.<xs:complexType name="HeaderType"> 줄에 오류가 있음을 표시하지만 오류가 무엇인지는 알려주지 않습니다.

도움이 되었습니까?

해결책

나는 XML 전문가는 아니지만 꽤 많이 사용하고 있습니다.이것은 제가 일반적으로 이런 종류의 구조를 수행하는 방식이 아닙니다.나는 두 그룹을 선택하는 것보다 별도의 복합 유형을 선호합니다(이 답변의 맨 끝 부분 참조).

문제는 ReservationGroup과 CancellationGroup이 동일한 요소로 시작한다는 것입니다. 이 경우 스키마 구성 요소 제약 조건을 위반하게 됩니다.고유한 입자 속성(아래).

http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/#cos-nonambig

스키마 구성요소 제약조건:독특한 입자 속성

컨텐츠 모델은 요소 정보 항목 시퀀스의 · 검증 중에 입자 구성 요소가 직접적으로, 간접적으로 또는 암시 적으로 함유 된 · 암시 적으로 포함되도록 · 검증을 시도 할 수 있도록 · 순서대로 각 항목을 차례로 결정할 수 있도록 컨텐츠 모델을 형성해야합니다. 해당 항목의 내용 또는 속성을 검사하지 않고 나머지 시퀀스의 항목에 대한 정보가 없습니다.

메모: 이 제약 조건은 XML 스키마에 대해 [XML 1.0 (두 번째 판)] 및 SGML의 동등한 제약 조건을 재구성합니다.요소 대체 그룹 및 와일드 카드의 존재를 고려할 때,이 제약의 간결한 표현은 어렵다. 추가 논의는 고유 한 입자 귀속 제약 (비정규 적) (§h)의 분석을 참조하십시오.

예를 들어, 아래의 두 그룹은 동일한 선택에서 유효하지 않습니다. 왜냐하면 첫 번째 요소 각각이 "이름"이기 때문입니다. 이는 보고 있는 그룹을 식별할 수 없음을 의미합니다.그러나 ReservationGroup의 첫 번째 요소는 취소 그룹 (Resdate 및 Cancdate 아마도)과 다릅니다.

편집하다: 저는 이전에 이런 종류의 문제를 접한 적이 없으며 그룹의 정의가 완전히 합법적이라는 점이 매력적이라고 ​​생각합니다. 그러나 이를 선택 항목으로 합치면 각 그룹의 정의로 인해 해당 선택이 불법이 됩니다.

법적 선택을 할 수 없는 집단

<xs:group name="ReservationGroup">
    <xs:sequence>
        <xs:element name="date"/>
        <xs:element name="name"/>
        <xs:element name="address"/>
    </xs:sequence>
</xs:group>

<xs:group name="CancellationGroup">
    <xs:sequence>
        <xs:element name="date"/>
        <xs:element name="name"/>
        <xs:element name="address"/>
    </xs:sequence>
</xs:group>

법적 선택을 할 수 있는 집단

<xs:group name="ReservationGroup">
    <xs:sequence>
        <xs:element name="resDate"/>
        <xs:element name="name"/>
        <xs:element name="address"/>
    </xs:sequence>
</xs:group>

<xs:group name="CancellationGroup">
    <xs:sequence>
        <xs:element name="cancDate"/>
        <xs:element name="name"/>
        <xs:element name="address"/>
    </xs:sequence>
</xs:group>

위에서 언급했듯이 복잡한 유형을 사용하여 이런 종류의 작업을 수행합니다.예, 또 다른 요소를 추가합니다. 하지만 그것은 당연한 방식인 것 같고 저는 뻔한 것을 좋아합니다.

<xs:complexType name="HeaderType">
  <xs:sequence>
    <xs:element name="reservation-number" type="ReservationNumberType" minOccurs="1" maxOccurs="1" nillable="false" />
    <xs:choice minOccurs="1" maxOccurs="1">
      <xs:element name="reservation" type="ReservationType" />
      <xs:element name="cancellation" type="CancellationType" />
    </xs:choice>
  </xs:sequence>
</xs:complexType>

다른 팁

예.ReservationGroup과 CancellationGroup 모두 동일한 첫 번째 요소, 즉 ReservationGroup의 'Reservation'과 Cancellationgroup의 'Cancellation'이라는 고정 값을 갖는 'reservation-type' 요소를 갖고 있었기 때문입니다.

이것이 유효한지 여부는 그룹의 내용에 따라 다릅니다.'순서' 또는 '선택' 모델 그룹인 경우 완전히 합법적입니다.'모든' 모델 그룹은 더 문제가 많으며 이 경우 일반적으로 허용되지 않습니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top