XML의 미래 이제 여러분은 XML을 알게 되었습니다. 구조가 약간 복잡한 것은 사실이며 DTD에는 문서에 포함될 수 있는 내용을 정의하기 위한 다양한 옵션이 있습니다. 하지만 그게 전부는 아닙니다.
은행과 같이 데이터 교환이 중요한 산업을 생각해 보십시오. 은행은 내부적으로 거래를 추적하기 위해 소유권 시스템을 사용하지만, 웹에서 공통 XML 형식을 사용하는 경우 거래 정보를 다른 기관이나 애플리케이션(예: Quicken 또는 MS Money)에 설명해야 합니다. 물론 웹 페이지의 데이터를 나타낼 수도 있습니다. 참고: 이 태그는 존재하지 않습니다. OFEX, 오픈 금융 거래소(Open Financial Exchange)라고 합니다.
특정 상황에서 PC의 IE 4가
여기에는 Andy Grove가 1970년대에 본 추가 기계, 타자기, 연필과는 다르게 보이는 세 가지 XML 응용 프로그램이 있습니다. 그러나 결국 PC에 등장한 응용 프로그램과 마찬가지로 XML의 이점은 일반적으로 다음과 같이 설명할 수 있습니다. "사람이 읽을 수 있고 기계가 읽을 수 있는 태그를 사용하여 데이터를 설명하면 좋은 일이 일어납니다.
" ? 나는 모른다. 하지만 내 PC의 차세대 프로그램이 어떤 모습일지는 알 수 없습니다. 데이터에 이러한 방식으로 태그를 지정하면 다양한 애플리케이션이 생성될 수 있습니다.
그것이 얼마나 확장될 수 있는지 생각하기 시작했나요?
우리는 XML의 실용적인 응용에 대해 이야기할 것이 많으며 가까운 시일 내에 이에 대해 다룰 것입니다. 우리 모두는 인터넷 사용자이기 때문에 미래는 XSL(Extensible Style Language-
확장 가능 스타일 언어).
그건 그렇고, 이 요리법은 정말 우리 엄마의 요리법이고 정말 훌륭해요. 그것을 사용하는 경우 강판 코코넛 반 컵을 더 추가하십시오.
나는 당신이 나를 어떻게 생각하는지 진심으로 궁금해서 이 글을 쓰고 있습니다. 내 관심사는 이것이다: 당신이 XML에 대한 내 소개를 읽고 자신만의 XML 문서를 작성할 준비가 되었는지 여부입니다. 따라서 귀하는 귀하의 정보를 나타내기 위해 이미 확립된 DTD를 찾기 시작합니다. 아래와 같이 하나를 찾습니다.
%attr.lang;
값 CDATA #FIXED "TEXT">
img.type CDATA #REQUIRED
img.data ENTITY #REQUIRED">
곧바로 당신은 Jay가 바보임에 틀림없다고 생각합니다. 그는 ATTLIST와 ENTITY에 대해 아무 말도 하지 않았습니다.
그러니 먼저 약간의 인내심을 갖고 이것에 대해 이야기해 봅시다.
위의 줄은 보기에 좋지 않을 수도 있지만 실제로는 아무것도 아닙니다. 이는 XML 문서의 속성과 엔터티를 정의하기 위해 DTD에서 사용됩니다. HTML을 아는 사람이라면 이 사실을 아주 잘 알 것입니다. 속성은 태그를 더 정확하게 설명하는 HTML 태그가 포함된 항목입니다. 자주 등장하는 
에는 높이(height)와 너비(width)라는 두 가지 속성이 있습니다. 나중에 보게 되겠지만 XML 문서에서 속성을 사용하는 것은 매우 유사합니다.
엔터티에 대해서도 새로운 것이 없습니다. &를 사용해 본 적이 있다면 이미 기본 사항을 알고 있는 것입니다. &와 세미콜론으로 묶인 문자열은 다른 문자나 문자 집합을 나타냅니다. (ISO 엔터티의 전체 목록은 여기에서 확인할 수 있습니다.)
물론 XML의 특성과 엔터티에는 다른 기능이 있습니다. 너무 많지는 않지만 필연적으로 구문이 도입됩니다. 이 사실을 알고 나면 XML 문서 작업이 쉬워집니다.
단순화된 조리법
XML에 대한 소개를 읽으면 조리법의 재료가
이 접근 방식은 실질적인 이점이 있습니다. 즉, 데이터를 더 쉽게 제어할 수 있습니다. 첫 번째 접근 방식에서는
다음 구조를 사용하여 유사한 기능을 달성할 수 있습니다.
<수량>2
<단위>컵
이는 처리할 수 있지만 두 가지 문제가 있습니다. 첫째, 항목 요소에 텍스트와 기타 마크업이라는 혼합 콘텐츠가 포함되어 있습니다. 나는 가능하면 이 구조를 피해야 한다는 것을 금방 깨달았습니다. 두 번째는 마커에는 독립적인 의미가 거의 없다는 것입니다. 유닛만 있고 실제 구성요소가 없는 상황은 상상하기 어렵습니다. 이러한 항목은 간단하게 설명할 수 있으며 속성으로 생각하는 것을 선호합니다.
가장 먼저 주목해야 할 점은 속성 이름, 수량 및 단위는 이를 번역할 수 있는 애플리케이션에서 처리할 때만 의미가 있다는 것입니다.
유효한 문서에 포함되기 전에 DTD에 이를 허용하도록 지시해야 합니다. 위의 성분 요소의 경우 DTD에 다음 코드만 포함했습니다.
첫 번째 줄은 친숙해 보입니다. 모든 DTD에서 볼 수 있는 표준 요소 정의입니다. 각 ATTLIST 줄에는 다음 정보가 차례로 포함됩니다.
이는 속성이 첨부되는 요소입니다.
속성 이름이 여기에서 정의됩니다.
여기에서 속성 유형을 설정합니다. CDATA는 문자 데이터를 나타냅니다. 이는 프로세서가 속성 내의 텍스트를 가져올 수 있음을 의미합니다.
마지막 부분은 속성의 기본값을 정의합니다. 3과 같은 실제 숫자 값을 사용할 수 있습니다. 이렇게 하면 XML의 공백 길이 속성 값은 3이 됩니다. 입력한 값은 기본값을 재정의합니다.
위의 예에서는 특정 수량을 설정하지 않고 XML 키워드 #REQUIRED를 사용했습니다. 이는 보조 속성에 값이 포함되어야 함을 프로세서에 알려줍니다. 비어 있으면 문서가 처리되지 않습니다.
기본값에는 두 개의 추가 키워드가 있습니다. 첫 번째는 #FIXED입니다. 속성 값이 문서 전체에서 동일한 값으로 유지되는 경우입니다. 이미지 태그 속성을 정의하고 모든 이미지의 크기가 100*50픽셀과 같다고 가정해 보겠습니다. DTD에서 다음과 같이 속성을 정의할 수 있습니다.
또 다른 키워드는 #IMPLIED로, 속성이 값을 포함하거나 비어 있을 수 있음을 나타냅니다.
속성 유형을 살펴보겠습니다.
자신만의 DTD를 작성하기로 결정했다면 ATTLIST 문의 모든 조합에 대한 XML을 설명하는 책이 필요할 수 있습니다. 하지만 DTD를 빌리면 CDATA와 다른 세 가지 속성만 알 수 있습니다.
첫 번째는 아이디입니다. 속성 값이 문서에서 반복되지 않아야 합니다. 데이터베이스를 사용해 본 사람이라면 누구나 고유 식별자의 필요성을 알고 있습니다. DTD ATTLIST 문은 다음과 같습니다.
기본값인 #REQUIRED가 없으면 ID 속성 유형을 상상하기 어렵습니다. 이 경우 ID가 중복되거나 비어 있으면 프로세서가 오류를 반환하게 됩니다. ID는 문자나 밑줄로 시작해야 하며 공백을 포함할 수 없습니다.
NMTOKEN 유형도 위의 명명 규칙을 사용합니다. 단, 복제는 허용됩니다. 이는 애플리케이션에 데이터를 전달하기 위한 보증으로 사용됩니다. Java 및 JavaScript를 포함한 대부분의 프로그래밍 언어는 모듈 이름에 공백을 포함할 수 없습니다. 대부분의 경우 부동산이 해당 규칙을 준수하는지 확인하는 것이 가장 좋습니다.
마지막으로 특정 키워드가 필요하지 않은 열거형이 있습니다. 대신 "|" 기호를 사용하여 값을 괄호로 묶습니다. 예:
이 접근 방식은 가능한 속성 값의 수가 제한된 경우에 사용할 수 있습니다.
오늘 강좌가 지루할 것 같지 않으니 계속 읽어보세요!