Summary

  • W3C는 2003년 10월 14일 XForms 1.0을 권고안으로 발표했다. 양식을 모델, XML 인스턴스 데이터, 사용자 화면으로 나누고 바인딩으로 화면의 입력 요소를 데이터 노드에 연결했다.
  • 권고안의 결제 예시에서 카드 번호와 만료일은 신용카드를 선택했을 때에만 관련된다. relevant 판단은 입력 요소의 사용 가능 여부와 제출 XML에 포함될 데이터 노드 모두에 영향을 준다.

현금을 내밀자 점원이 지폐를 센다. 그런 다음 카드 번호와 만료일을 적으라고 한다. 이유는 신청서에 그 칸이 인쇄돼 있어서다. 웹 양식에도 이런 점원이 산다. 그려 둔 입력 칸을 모두 고객의 의무로 착각한다. W3C가 2003년 10월 14일 발표한 XForms 1.0은 질문의 필요성을 화면의 고집이 아니라 데이터 모델의 규칙으로 다루었다.

구조는 세 부분이다. 모델에는 데이터의 모양과 조건을 쓴다. 인스턴스는 사용자가 답할 때마다 값이 채워지는 XML 문서다. 사용자 화면은 그 답을 받는 입력 요소를 보여 준다. ref 바인딩은 각 요소가 인스턴스의 어느 노드를 다루는지 연결한다. 그래서 칸의 모양을 바꾸더라도 무엇을 수집하며 어떤 규칙을 적용하는지 추적할 수 있다.

규격 자체의 예시는 현금과 신용카드 중 하나를 고르는 간단한 결제다. instance에는 결제 방법, 카드 번호, 만료일의 자리가 XML 뼈대로 놓인다. submission은 결과를 보낼 곳을 지정한다. 화면의 select1은 결제 방법을 고르게 하고, 두 input은 카드 정보를 받는다. 입력 요소마다 자식 label이 붙고, ref는 그것을 데이터 자리와 잇는다. 답이 들어오면 인스턴스가 갱신되고, 제출할 때 처리기가 XML로 직렬화한다.

select1은 한 가지를 선택하라는 뜻이지 모든 기기에서 똑같은 버튼을 그리라는 명령이 아니다. 화면과 음성 인터페이스는 서로 다른 방식으로 선택지를 제시할 수 있다. 데이터와의 연결은 그대로다. 표현의 자유에는 주소를 정확히 적어야 한다는 조건이 붙는다. 카드 번호 칸이 엉뚱한 XML 노드에 연결되면 예쁜 화면은 친절한 오류 안내판일 뿐이다.

현금 고객을 구해 주는 규칙은 bind에 놓인다. 예시에서 카드 번호와 만료일의 relevant 식은 결제 방법이 신용카드를 뜻하는 cc인지 검사한다. 그 경로에서는 두 값이 required로 요구되고, 값의 형식에도 제한이 붙는다. 번호 예시는 14~18자리 숫자 패턴을, 만료일은 xsd:gYearMonth를 사용한다. 고객이 현금으로 바꾸면 처리기는 조건을 다시 계산한다. 점원은 이제 지폐에서 카드 만료일을 찾지 않는다.

XForms의 relevant 정의는 화면뿐 아니라 전송 기록까지 다룬다. 관련 없다고 판정된 데이터 노드는 제출 XML로 직렬화되지 않는다. 연결된 입력 요소는 사용할 수 없고, 탐색 순서에서 빠지며, 포커스도 받지 못한다. 신용카드가 선택되면 필요한 칸이 활성 경로에 들어온다. 현금이 선택되면 카드 데이터는 바깥으로 보내는 기록에서도 빠진다.

두 번째 변화가 특히 중요하다. 화면의 칸만 가리면 오래된 입력값이 전송 데이터에 남을 수 있다. XForms는 같은 관련성 규칙을 사람에게 보이는 질문과 기계가 보내는 XML에 적용한다. 모델이 조건을 정하고, 처리기가 실행하며, 화면과 인스턴스가 각각 결과를 드러낸다. 서류 세 장이 한 결제에 대해 서로 다른 말을 하지 않도록 묶은 셈이다.

W3C의 당시 발표는 목적, 표현, 결과를 나누는 설계라고 설명했다. 결제 예시에서는 결제 방법을 기록하는 것이 목적이고, 기기에 맞게 보여 주는 것이 표현이며, 제출 XML이 결과다. 복잡한 이름의 규격이 시도한 사소하고도 반가운 일은 고객의 첫 답을 듣고 다음 질문을 고르는 것이었다.