jquery ajax 을 사용한 xml parsing

Js & Css/jQuery 2009. 12. 16. 09:46 posted by 무명시인
사용자 삽입 이미지



위 와같은 xml 을 jquery 로 분리를 해보자..

jquery 의 ajax 연동은 따로 설명 하지 않겠다. 아래 참고

http://docs.jquery.com/Ajax

	$.ajax({
		type: 'get'
		, dataType: "xml"
		, url: "Service.aspx"
		, data: "arg=L
		, success: function(xml) {
			// xml 노드 null 확인
			if ($(xml).find("list").find("item").length > 0) {

				// totalitem 찾기
				var totitem = $(xml).find("totalitem").text();
				
				// item 노드 loop
				$(xml).find("list").find("item").each(function(idx) {				
					
					var idx = $(this).find("idx").text()
					var title = $(this).find("title").text()
					var content = $(this).find("content").text()
					
				});
			}			
		}
		, error: function(xhr, status, error) {alert(error); }
	});


ajax 를 콜한이후에.. xml 개체가 넘어온다.
최상위 노드가 "list" 이기 때문에
jquery 의 find 메소드로 "list" 노드를 찾고
totalitem 값(.text() 메소드 사용) 을 찾고..
"item" 노드를 찾아서
반복(.each 메소드 사용) 에서 "item" 노드 의 값들을 분리 하면된다.
여기서 .each 메소드 내부에서 $(this) 개체는 "item" 노드 이다.


XSLT Element

Xml 2009. 8. 14. 10:41 posted by 무명시인
사용자 삽입 이미지


하나씩 살펴보자

확장 가능한 마크업 언어 표준 - 그 이름 XML [2]

Xml 2009. 8. 13. 09:31 posted by 무명시인
http://www.devpia.com/MAEUL/Contents/Detail.aspx?BoardID=66&MAEULNO=25&no=180&page=2


2. 문서

   데이터 객체가 명세에 정의된 대로 좋은-형식(well-formed)이면 XML 문서이다. 좋은-형식 XML 문서는 임의 추가적인 제약을 만족시키면 유효 문서가 수도 있다.

   모든 XML 문서는 논리적 구조와 물리적 구조를 가지고 있다. 물리적으로 XML 문서는 엔티티(entity)라 불리는 요소들로 구성된다. 엔티티는 다른 엔티티들을 참조해 이것들을 문서안에 포함시킬 수도 있다. 문서는 "루트(root)" 또는 문서 엔티티로 시작한다. 논리적으로 XML 문서는 선언, 요소, 주석, 문자참조, 처리 명령을 포함하며 이들은 명시된 마크업에 의해 문서안에 표시된다.

   논리적, 물리적 구조는 "4.3.2 : 좋은-형식의 파싱된 엔티티"에 기술된 것처럼 올바르게 중첩되어야 한다.


2.1 좋은-형식의 XML 문서


   다음의 조건을 충족하는 텍스트는 좋은-형식의 XML 문서이다.


     1. 전체적으로 문서의 형식과 정합되어야 한다.

     2. 명세에 기술된 모든 좋은-형식 제약을 만족한다.

     3. 문서 내에서 직간접적으로 참조되는 모든 파싱된 엔티티들이 좋은-형식이다.


 문서

 [1] 문서 ::= 서언 요소 기타*

 


   문서의 형식에 정합한다는 것은 다음 내용의 포함을 의미한다 :


1. 하나 또는 이상의 요소들을 포함한다.

2. 루트 또는 문서 요소라 불리는 요소는 정확히 하나 존재하며, 다른 어떠한 요소의 내용에 이를 위한 시작 태그나 종료 태그가 나타날 없다. 모든 다른 요소들은 다른 요소의 내용에 시작 태그가 있으면 종료 태그도 같은 내용 내에 있다. 더욱 간단히 말하면 시작 태그와 종료 태그로 구분된 요소는 적절하게 중첩된다.


   결과적으로 문서 내의 루트가 아닌 모든 요소 C에 대해, 요소 C를 내용으로 하는 다른 하나의 요소 P가 문서 내에 있으나, C는 P의 내용 안에 존재하는 다른 어떤 요소 안에 존재하지 않는다. 그러면 P는 C의 부모로, C는 P의 자식으로 불린다.


2.2 문자


   파싱된 엔티티는 마크업 이나 문자 데이터를 표현하는 문자들의 연속체인 텍스트를 포함한다. 문자란 ISO/IEC 10646에 정의된 것처럼 텍스트의 최소 단위를 말한다. 유효 문자들은 (tab), 복귀(carriage return), 개행(line feed), 그리고 Unicode ISO/IEC 10646의 유효 그래픽 문자들이다. Unicode의 6.8에 정의된 것처럼 호환성 문자 사용하는 것은 권장하지 않는다.

 문자의 범위

[2] 문자 ::=  #x9 | #xA | #xD | [#x20-#xD7FF]            /* FFFE, FFFF를 제외한

             | [#xE000-#xFFFD] | [#x10000-#x10FFFF]       임의 유니코드 문자 */

 



   문자 코드 값들을 비트 패턴으로 부호화 하는 기법은 엔티티에 따라 변화할 있다. 모든 XML 처리기는 10646의 UTF-8와 UTF-16 부호화를 수용해야 한다. 어느 것을 사용해야 것인가, 다른 부호화 방법을 가져오기 위한 기법은 "4.3.3 엔티티 문자 부호화"에서 다시 논의할 것이다.


2.3 공통 문법 구조


 

 [3] S ::= (#x20 | #x9 | #xD | #xA)+

 


   절에서는 문법에서 널리 쓰이는 몇몇 심볼들을 정의한다.


   S(여백)는 하나 또는 하나 이상의 공백(#x20) 문자들, 복귀, 개행 또는 탭으로 구성된다.


   문자는 편의상 글자, 숫자, 기타 문자로 분류된다. 글자들은 하나 또는 하나 이상의 결합문자가 따라올 있는 알파벳과 같은 표음 문자나 표의 문자로 구성된다. 부류의 특정 문자에 대한 상세한 정의는 "부록B : 문자 집합"에 주어진다.


   이름 글자 또는 개의 구두점 문자로 시작하여 이름 문자로 알려진 글자, 숫자, 하이픈(hypen), 밑줄, 콜론(colon), 마침표 등이 이어지는 토큰이다. 문자열 xml' 또는 (('X'|'x') ('M'|'m') ('L'|'l'))과 정합하는 임의 문자열로 시작하는 이름들은 명세의 이번 버전 또는 다음 버전에서 표준화로 지정된다.


   비고  XML 이름내 콜론 문자는 이름 공간의 시험을 위해 예약되었다. 이는 장래 어느 시점에서 표준화 것으로 기대되며 시험적으로 콜론을 사용한 문서들은 갱신되어야 것이다(XML에 채택된 이름 공간 기법들 어느 것이 실제로 이름-공간 구분자로 콜론을 사용할 없다). 이는 실제적으로 XML 저자들이 이름-공간 시험 부분을 제외하고는 XML 이름에 콜론을 사용하지 않아야 되나, XML 처리기는 콜론을 이름 문자로 받아들여야 됨을 의미한다.

  

   Nmtoken(이름 토큰)은 이름 문자들의 혼합이다.

  




 이름과 토큰

 [4] NameChar   ::= Letter | Digit | '.' | '-' | '_' | ':' | CombiningChar | Extender

 [5] Name         ::= (Letter | '_' | ':') (NameChar)*

 [6] Names        ::= Name (S Name)*

 [7] Nmtoken      ::= (NameChar)+

 [8] Nmtokens    ::= Nmtoken (S Nmtoken)*

 



   리터럴(literal) 데이터는 구분자로 쓰이는 인용 부호를 포함하고 있지 않은 인용된 문자열이다. 리터널들은 내부 엔티티들의 내용(EntityVAlue), 속성 (AttValue), 외부 식별자(Systemliteral)를 기술하기 위해 사용된다. SystemLiteral은 마크업을 검사하지 않고도 파싱될 수 있다는 점을 주목하라.

 리터럴

 [9] EntityValue                ::=  '"' ([^%&"] | PEReference | Reference)* '"'

                            |? "'" ([^%&'] | PEReference | Reference)* "'"

 [10] AttValue                  ::=  '"' ([^<&"] | Reference)* '"'

                            |? "'" ([^<&'] | Reference)* "'"

 [11] SystemLiteral          ::=

                          ('"' [^"]* '"') |?("'" [^']* "'")

 [12] PubidLiteral           ::= '"' PubidChar* '"' | "'" (PubidChar - "'")* "'"

 [13] PubidChar                                     ::= #x20 | #xD | #xA |?[a-zA-Z0-9]|?[-'()+,./:=?;!*#@$_%]


 




2.4 문자 데이터와 마크업


   텍스트는 문자 데이터와 마크업이 혼합되어 구성된다. 마크업은 시작-태그, 종료-태그, 공백-요소 태그, 엔티티 참조, 문자 참조, 주석, CDATA 부분 구분자, 문서형 선언, 처리 명령의 형식들을 갖는다.


   마크업이 아닌 모든 텍스트는 문서의 문자 데이터로 이루어진다.


   앰퍼샌드 문자(&)와 왼쪽 꺾쇠 괄호(<)는 마크업 구분자로 사용되거나, 주석, 처리 명령 또는 CDATA 부분내에 사용될 때만 리터럴 형식으로 나타날 수 있다. 이들은 또한 내부 엔티티 선언의 리터럴 엔티티 값내에서 유효하다(이는 "4.3.2 : 좋은-형식의 파싱된 엔티티"를 참고). 만약 다른 곳에서 필요 시에는 숫자 문자 참조나 "&amp;"와 "&lt;" 문자열을 각각 사용하여 해결한다. 오른쪽 꺾쇠 괄호(>)는 "&gt;" 문자열을 이용하여 표현될 수 있으며 내용중 "]]>" 문자열에 사용되는 경우 (단, 그 문자열은 CDATA 부분의 끝을 의미하는 것이 아닐 경우)에는 반드시 호환성을 위해 "&gt;"나 문자 참조를 사용해야 한다.


   요소들의 내용에서 문자 데이터는 어느 마크업의 시작 구분자도 포함하지 않는 문자들로 구성된 임의 문자열이다. CDATA 부분에서 문자 데이터는 CDATA 부분 종료 구분자("]]>")를 포함하지 않는 임의 문자열 이다.

 주석

 [15] Comment ::=  '<!--'((Char - '-') | ('-' (Char - '-')))* '-->'

 



   속성 값에 단일 따옴표()와 이중 따옴표()를 모두 포함하도록 하려면 단일 따옴표(')는 "&apos;"로 이중 따옴표(")는 "&quot;"로 표현할 수 있다.


2.5


   주석은 문서에서 마크업 외부 어디에서나 나타날 있으며, 더우기 문법에 의해 허용된 장소에 있는 문서형 선언 내에 나타날 있다. 주석은 문자 데이터의 일부분이 아니다. XML 처리기는 응용이 주석 텍스트를 검색할 수 있도록 할 수도 있지만 꼭 필요한 것은 아니다. 문서의 호환성을 위하여 이중 하이픈("- -") 문자열은 주석 안에 올 수 없다.

 문자 데이터

 [14] CharData    ::= [^<&]* - ([^<&]* ']]>' [^<&]*)

 



   주석의 :


    <!-- <head>와 <body>를 위한 선언 -->


2.6 처리 명령


   처리 명령(PIs)은 문서가 응용 프로그램의 명령을 포함하도록 허용한다.

 처리 명령

 [16] PI                  ::= '<?' PITarget (S (Char* - (Char* '?>' Char*)))?'?>'

 [17] PITarget    ::= Name - (('X' | 'x') ('M' | 'm') ('L' | 'l'))




   처리 명령은 문자 데이터의 일부가 아니며 응용 프로그램에 반드시 전달되어야 한다. PI는 명령이 전달되어야 할 응용 프로그램을 인식하기 위해 사용되는 목표(PITarget)로 시작한다. "XML", "xml"과 같은 목표 이름들의 표준화는 본 명세의 이번 버전 또는 앞으로 나올 버전의 일로 남긴다. XML 표기 기법은 PI 목표들의 정식 선언들로 사용될 수 있다.


2.7 CDATA 부분


   CDATA 부분은 문자 데이터가 발생하는 어느 곳에든 올 수 있다. 이는 문자를 포함하고 있는 텍스트 블록을 회피하기 위해 사용되는데 만약 그렇지 않으면 텍스트는 마크업으로 인식된다. CDATA 부분은 "&ltl![CDATA[" 로 시작해서 "]]>": 로 종료한다.

 CDATA 부분

 [18] CDSect       ::= CDStart CData CDEnd

 [19] CDStart     ::= '<![CDATA['

 [20] CData          ::= (Char* - (Char* ']]>' Char*))

 [21] CDEnd    ::=  ']]>'





   CDATA 부분 내에서는 CDEnd 문자만이 마크업으로 인식되므로, 왼쪽 꺾쇠 괄호(<)나 앰퍼샌드(&)는 “&lt;"나 "&amp;"를 사용하여 회피할 필요 없이(할 수도 없다) 리터럴 형식으로 표현할 수 있다. CDATA 부분은 중첩할 수 없다.

 <![CDATA[<greeting>Hello, world!</greeting>]]>



   "<greeting>"와 "</greeting>"가 마크업이 아니라 문자 데이터로 인식되는 CDATA의 한 예를 들어 보자.

2.8 서문과 문서형 선언


   XML 문서들은 사용된 XML의 버전을 알려주는 XML 선언으로 시작해야 한다. 예를 들어 보자. 다음은 완전한 XML 문서로 좋은-형식 문서이지만 유효 문서는 아니다.

    <?xml version="1.0"?>

    <greeting>Hello, world!</greeting>




   다음도 마찬가지다.

     <greeting>Hello, world!</greeting>




   버전 숫자 1.0은 본 명세의 버전에 따른다는 것을 나타낸다. 문서가 본 명세의 버전을 따르고 있지 않은데도 1.0이란 숫자를 사용하는 것은 오류이다. 본 명세의 이후 버전에 1.0이 아닌 숫자들을 주려는 것이 XML 워킹 그룹의 의도다. 그러나 이런 의도가 다른 특정한 숫자 부여를 위해 XML의 어떤 이후 버전들을 개발하겠다는 언질을 주는 것은 아니다. 이후 버전들을 배제하는 것이 아니므로 이런 구조는 중요해지게 되면 자동 버전 인식의 가능성을 주는 방법으로 쓰일 수 있다.

   처리기들은 지원하지 않는 버전을 갖는 문서를 수신시 오류 신호를 보낼 수 있다.


   XML 문서에서 마크업의 기능은 문서의 저장 구조와 논리적 구조를 기술하고 속성-값 쌍을 논리 구조와 연관지우는 것이다. XML은 논리적 구조에 관한 제약을 정의하고, 미리 지정된 저장 장치의 사용을 지원하기 위해 문서형 선언이라는 기법을 제공한다. XML문서는 관련된 문서형 선언을 가지고, 이 선언에 명시된 조건을 따르면 유효하다.


 서언

 [22] prolog                          ::= XMLDecl? Misc* (doctypedecl Misc*)?

 [23] XMLDecl                     ::= '<?xml' VersionInfo EncodingDecl? SDDecl? S? '?>'

 [24] VersionInfo                          ::= S 'version' Eq (' VersionNum ' | " VersionNum ")

 [25] Eq                       ::= S? '=' S?

 [26] VersionNum             ::= ([a-zA-Z0-9_.:] | '-')+

 [27] Misc                      ::= Comment | PI | S



   문서형 선언은 문서 내의 최초 요소 이전에 나타나야 한다.


   XML 문서형 선언은 문서 부류에 대한 문법을 제공하는 마크업 선언들을 포함하거나 가리킨다. 문법이란 문서형 정의, 즉 DTD를 말한다. 문서형 선언은 마크업 선언들을 담고 있는 특별한 외부 엔티티들을 가리키거나 내부의 부분집합에서 직접 마크업 선언들을 포함할 수 있고, 둘 모두를 포함할 수 있다. 문서의 DTD는 함께 받아들여지는 두 부분집합으로 구성된다.


   마크업 선언은 요소형 선언, 속성 목록 선언, 엔티티 선언, 또는 표기법 선언이다. 이런 선언들은 아래의 좋은-형식이나 유효성 제약에 기술된 것 처럼 매개변수 엔티티 안에 부분적으로 또는 전체가 다 포함될 수 있다. 보다 자세한 사항은 "4. 물리적 구조"에 기술되고 있다.   

 문서형 정의

 [28] doctypedecl                        ::= '<!DOCTYPE' S Name      [VC : 요소 ]

                          (S ExternalID)? S? ('['

                           (markupdecl | PEReference

                          | S)*']' S?)?  '>'

 [29] markupdecl            ::=  elementdecl | AttlistDecl    [VC : 적절한 선언/PE 중첩]

                           | EntityDecl | NotationDecl

                           | PI | Comment             [WFC : 내부 부분집합내

                                                        PEs]




   마크업 선언은 매개변수 엔티티의 대체 텍스트 안의 한 부분, 또는 전체로 구성된다. 개개 비종단을 위한 본 명세의 뒤쪽에 있는 생성규칙들은(elementdecl, AttlistDecl 등) 모든 변수 엔티티들이 포함되고 난 다음의 선언들에 대해 기술하고 있다.


   유효성 제약 : 루트 요소형.

   문서형 선언에서의 이름은 루트 요소의 요소형과 정합되어야 한다.


   유효성 제약 : 적절한 선언/PE 중첩.

   변수 엔티티를 대신하는 텍스트는 마크업 선언들과 올바르게 중첩되어야 한다. 다시 말하면 마크업 선언의 처음 문자 또는 마지막 문자(위에 있는 markupdecl)는 매개변수에서 변수 참조의 대체 텍스트에 포함되며, 둘 모두는 같은 대체 텍스트 안에 포함되어야 한다.


   좋은-형식 제약 : 내부 부분집합의 PEs.

   내부 DTD 부분집합에서 매개변수 엔티티 참조는 마크업 선언이 있는 곳에서만 발생하며 마크업 선언 내에서 일어나지는 않는다(이는 외부 매개변수 엔티티들 안에서 또는 외부의 부분집합에게 일어나는 참조에는 적용되지 않는다).


   내부 부분집합과 같이 DTD 내에서 참조된 외부 부분집합과 임의 외부 매개변수 엔티티들은 여백 또는 매개변수 엔티티 참조로 산재된 비종단 기호 markupdecl에 의해 허용된 유형들의 완전한 마크업 선언의 연속체로 구성되어야 한다. 그러나 외부 부분집합이나 외부 매개변수 엔티티 내용의 부분들은 조건적인 부분 구성자를 이용하여 조건적으로 무시할 수 있다. 이는 내부 부분집합에는 해당하지 않는다.

 외부 부분집합

 [30] extSubset                                     ::= TextDecl?extSubsetDecl

 [31] extSubsetDecl        ::= (markupdecl | conditionalSect | PEReference | S)*




   외부 부분집합과 외부 매개변수 엔티티들은 이들내의 내부 부분집합과 역시 구별되며 매개변수 엔티티 참조는 마크업 선언들 사이뿐만 아니라 마크업 선언내에 허용된다.


   문서형 선언을 가진 XML 문서의 예 :

 <?xml version="1.0"?>

 <!DOCTYPE greeting SYSTEM "hello.dtd">

 <greeting>Hello, world!</greeting>




   시스템 식별자 "hello.dtd"는 문서에 대한 DTD의 URI를 준다.

   선언들은 예에서 보여주듯이 부분적으로 주어질 수도 있다.

 <?xml version="1.0" encoding="UTF-8" ?>

 <!DOCTYPE greeting [

 <!ELEMENT greeting (#PCDATA)>

 ]>

 <greeting>Hello, world!</greeting>




   외부와 내부 부분집합이 모두 사용되면 내부 부분집합은 외부 부분집합이 발생하기 전에 발생한다. 이는 내부 부분집합내 엔티티와 속성 목록 선언이 외부 부분집합의 엔티티와 속성 목록 선언보다 우선하게 되는 효과를 갖는다.


2.9 독립적인 문서 선언


   마크업 선언들은 문서가 XML 처리기로부터 응용 프로그램으로 전달될 때 문서의 내용에 영향을 미칠 수 있다. 속성 초기값이나 엔티티 선언들이 이 예이다. XML 선언의 구성요소로 나타나는 독립적인 문서 선언은 문서 엔티티의 외부에 나타나는 선언들이 있어야 할지 없어야 할지를 신호로 알려준다.

 독립적인 문서 선언

 [32] SDDecl      ::= S 'standalone' Eq (("'" ('yes' | 'no') "'")   [VC : 독립적인 문서

                   | ('"' ('yes' | 'no') '"'))                                                          선언]




   독립적인 문서 선언에서 "yes"라는 값은 XML 처리기로부터 응용 프로그램에 전달되는 정보에 영향을 미치는 문서 엔티티(DTD 외부 부분집합에 있든지, 내부 부분집합으로부터 참조된 매개변수 엔티티에 있든지)의 외부에 있는 마크업 선언들이 없다는 것을 나타낸다. "no"라는 값은 이러한 외부 마크업 선언들이 있거나 있을 수 있다는 것을 나타낸다. 독립적인 문서 선언은 단지 외부 선언들의 존재를 나타낸다는 점에 주목하라. 한 문서에서 내부적으로 선언된 엔티티들이 있을 때 외부 엔티티에 대한 참조는 독립적인 상태를 변화하지 않는다.

   외부 마크업 선언들이 없으면 독립적인 문서 선언은 아무런 의미가 없다. 독립적인 문서 선언이 없고, 외부 마크업 선언들이 있다면 값은 "no" 값으로 간주된다.

   Standalone="no"가 효력을 갖는 임의 XML 문서는 알고리즘적으로 몇몇 네트워크 전달 응용에 적합한 독립적인 문서로 변환될 수 있다.


   유효성 제약 : 독립적인 문서 선언.

   독립적인 문서 선언은 임의 외부 마크업 선언이 다음과 같은 선언을 포함할 경우 "no" 라는 값을 가져야 한다.


l 디폴트(default) 값을 갖는 속성(속성들이 적용되는 요소들이 문서내에서 이 속성들을 위한 값의 명세가 없이 나타나는 경우), 또는

l amp, lt, gt, apos, quot 이외의 엔티티들(이 엔티티들에 대한 참조가 문서내에 나타나는 경우), 또는

l 정규화(normalization)에 속하는 속성들(정규화는 속성들이 문서내에서 정규화의 결과로 변하는 값을 가지고 나타나는 곳을 말한다), 또는

l 요소 내용을 가지는 요소 형들(여백이 이들 요소형의 임의 실례내에서 곧바로 발생하는 경우).


   독립적인 문서 선언을 가지는 XML 선언 예 :

 <!ATTLIST poem   xml:space (default|preserve) 'preserve'>





2.10 여백 처리


   XML 문서들을 편집할 때 가독성을 위해 마크업을 분리하기 위해 여백(본 명세에 비종단 단말인 S로 표현되는 공백, 탭, 공백행)을 사용하는 것이 편리하다. 이러한 여백은 문서의 배포 버전에 포함하고자 한 것은 아니다. 반면에 예로서 시 또는 소스 코드내에 있는 배포 버전에 남아 있는 “의미 있는” 여백이 일반적이다.

   XML 처리기는 문서 내의 모든 마크업이 아닌 문자를 응용 프로그램에게 항상 전달하여야 한다. 유효성을 검사하는 XML 처리기는 이들 문자들중 어느 것이 요소 내용에 나타나는 여백을 구성하는지 응용 프로그램에 알려주어야만 한다.

   xml:space로 명명된 특별한 속성은 이 요소 내에 여백이 응용에 의해 유지되어야만 함을 알리기 위해 요소에 첨부된다. 유효 문서에서 이 속성은 다른 속성과 마찬가지로 사용되는 경우에 선언되어야만 한다. 선언될 경우 이는 값이 ‘default'와 ’preserve'만 가능한 열거형식으로 주어져야만 한다. 예는 다음과 같다.

     <?xml version="1.0" standalone='yes'?>


   'default'값은 이 요소에 대해 응용들의 디폴트 여백 처리 모드가 수용됨을 표시하고, ‘preserve'는 응용들이 모든 여백을 유지해야 함을 나타낸다. 이 선언은 xml:space 속성의 다른 실례를 무시하지 않고 지정된 요소의 내용내 모든 요소에 적용되도록 하고 있다.

   임의 문서의 루트 요소는 속성에 디폴트 값을 제공하거나 속성이 디폴트 값으로 선언된 경우가 아니라면 응용 프로그램 공백 처리에 관해 아무런 의도가 없다고 신호한 것으로 고려한다.


2.11 행끝 처리


   XML의 파싱된 엔티티들은 종종 편집상의 편의를 위해 행으로 구성된 컴퓨터 파일에 저장된다. 이 행들은 전형적으로 복귀(#xD)와 개행(#xA) 문자의 몇몇 조합에 의해 전형적으로 분리된다.

   외부의 파싱된 엔티티 또는 내부의 파싱된 엔티티의 리터럴 엔티티 값이 두개의 문자를 연속적으로(#xD#xA) 포함하든지 아니면 #xD와 같이 하나의 문자를 포함하든지에 상관없이 XML 처리기는 응용 프로그램의 작업을 단순화하기 위해 하나의 #xA 문자를 응용 프로그램에 보내야만 한다(이러한 동작은 파싱하기 전에 입력할 때 모든 줄바꿈을 #xA로 표준화함으로써 가능하다).


2.12 언어 식별


   문서 처리에서 내용이 쓰여진 자연 언어나 형식 언어를 정의하기 위해 종종 유용하다. xml:lang로 명명된 특별한 속성은 XML 문서내 임의 요소의 속성값이나 내용에 사용된 언어를 설명하기 위해 문서에 삽입될 수 있다. 유효 문서에서 다른 속성들과 마찬가지로 이 속성을 사용할 경우 선언하여야 한다. 이 속성값들은 "언어 식별을 위한 태그들"[RFC1766]에 정의된 것처럼 언어 식별자이다.

 언어 식별

 [33] LanguageID                ::= Langcode ('-' Subcode)*

 [34] Langcode              ::= ISO639Code | IanaCode |  UserCode

 [35] ISO639Code         ::= ([a-z] | [A-Z]) ([a-z] | [A-Z])

 [36] IanaCode              ::= ('i' | 'I') '-' ([a-z] | [A-Z])+

 [37] UserCode               ::= ('x' | 'X') '-' ([a-z] | [A-Z])+

 [38] Subcode                ::= ([a-z] | [A-Z])+


   Langcode는 다음과 같은 경우를 말한다.


l [ISO 639]에 정의된 것 처럼 두 개의 문자로 된 언어코드로 “언어들의 이름을 나타내기 위한 코드”

l IANA[Internet Assigned Numbers Authority]에 등록된 언어 식별자, 이들은 "i"나 "I"로 시작한다.

l 사용자에 의해 지정되거나 개인적인 사용시 단체들 간에 동의된 언어 식별자, 이들은 이후에 표준화되거나 IANA에 등록된 이름들과 혼돈을 빚지 않기 위해 "x"나 "X"로 시작해야 한다.


   몇 개의 Subcode 부분이 있을 수 있다. 첫 번째 서브코드 부분이 존재하고 서브코드가 두개의 문자로 구성되어 있다면, 이는 “국가명을 나타내기 위한 코드”[ISO 3166]로 부터의 나라 코드임이 분명하다. 만약 첫번째 서브코드가 두개 이상의 글자로 구성되고, Langcode가 "x"나 " X"로 시작하지 않는다면 이는 IANA에 등록된 것 중 해당되는 언어를 위한 서브코드 임에 틀림없다.

   소문자로 언어 코드를 부여하고, 대문자로 나라 코드를 부여하는 것은 관례다. XML 문서의 다른 이름들과는 달리 이 값들은 경우에 따라 달라진다는 것을 주목하라.

   이에 대한 예는 다음과 같다.

 <p xml:lang="en">The quick brown fox jumps over the lazy dog.</p>

 <p xml:lang="en-GB">What colour is it?</p>

 <p xml:lang="en-US">What color is it?</p>

 <sp who="Faust" desc='leise' xml:lang="de">

      <l>Habe nun, ach! Philosophie,</l>

      <l>Juristerei, und Medizin</l>

      <l>und leider auch Theologie</l>

      <l>durchaus studiert mit heißem Bemuh'n.</l>

      </sp>


   xml:lang를 가지고 선언한 것은 그 내용내 다른 요소상 xml:lang의 실례를 무시하지 않고 지정된 요소의 모든 속성들과 내용에 적용되도록 하는 것이다.

   xml:lang에 대한 간단한 선언 다음의 형식을 갖는다.

 xml:lang  NMTOKEN  #IMPLIED


   그러나 유효하면 특정한 디폴트 값이 주어질 수도 있다. 영어로 주석를 갖는 영어권 학생들에 대한 프랑스 시 모음집에서 xml:lang은 다음과 같이 선언될 수 있다.

확장 가능한 마크업 언어 표준 - 그 이름 XML [1]

Xml 2009. 8. 13. 09:30 posted by 무명시인
http://www.devpia.com/MAEUL/Contents/Detail.aspx?BoardID=66&MAEULNO=25&no=179&page=2

1.  

 

   확장 가능한 마크업 언어는 SGML의 부분 집합으로 표준에서 자세히 기술한다. XML의 목적은 일반적인 SGML을 지금의 HTML처럼 웹상에서 보내고, 받고, 처리할 있도록 하는 것이다. XML은 SGML과 HTML 양쪽 모두와의 상호운용과 구현이 용이하도록 설계되었다.

 

1.1 기본 문서

 

IETF RFC-XML "Extensible Markup Language"

 

1.2 문서의 상태

 

   표준은 현재 가장 널리 쓰이는 국제 텍스트 처리 표준(SGML, ISO 8879)을 웹에서 사용하기 위해 간편하게 만든 문법에 관한 명세이다. 문서는 W3C 산하 XML 분과 활동의 노력으로 작성된 문서를 참고하여 작성된 확장 가능한 마크업 언어 표준(안) 이다.  문서는 아무런 제약 없이 배포 가능하다.

 

1.3 요약

 

   XML은 'XML 문서'라 불리는 데이터 객체들의 집합을 설명하고 부분적으로 XML 문서을 처리하는 컴퓨터 프로그램들의 동작에 대해 기술한다. XML은 SGML의 응용 프로파일(profile) 또는 제한된 형식이다. 구조적으로 XML 문서는 SGML 문서의 특징을 따른다.

   XML 문서는 파싱된 혹은 파싱되지 않은 데이터를 포함하는 엔티티라는 저장 단위로 구성된다. 파싱된 데이터는 문자들로 이루어지는데 문자들의 일부는 데이터를 구성하고 일부는 마크업을 구성한다. 마크업은 문서의 배치적 논리적 구조에 관한 기술을 부호화한다. XML은 배치적 논리적 구조에 제약을 가하는 기법을 제공한다.

   XML 처리기라 불리는 소프트웨어 모듈은 XML 문서들을 읽고 이들의 내용과 구조에 접근하는데 사용한다. XML 처리기는 응용이라 불리는 또다른 모듈을 대신해 작업하는 것으로 간주된다. 명세는 XML 처리기가 갖추어야 기능들을 기술하고 있는데 , XML 처리기는 XML 데이터를 읽을 있어야 하며 정보를 응용에 제공할 있어야 한다.

 

1.4 개발 배경과 목적

 

   XML은 1996년 W3C의 후원으로 형성된 XML 작업 그룹에 의해 개발되었다. 이에 문서는 이를 기본으로 하여 확장 가능한 마크업 언어 표준(안)을 개발하였다.

 

   XML의 설계 목적은 다음과 같다.

 

     1. XML은 인터넷상에서 쉽게 사용될 있어야 한다.

     2. XML은 다양한 응용들을 지원해야 한다.

     3. XML은 SGML과 호환성이 있어야 한다.

     4. XML 문서를 처리하는 프로그램을 작성하기 쉬워야 한다.

     5. XML에서 선택 가능한 특성은 없는 것이 좋으며, 있어도 극히 적은 수로 유지

       하도록 한다.

     6. XML 문서들은 사람이 인식할 있어야 하며 합리적으로 명확해야 한다.

     7. XML 설계는 빨리 준비되어져야 한다.

     8. XML의 설계는 형식에 맞아야 하고 간결하여야 한다.

     9. XML 문서는 만들기 쉬워야 한다.

    10. XML 마크업의 간결성은 최소한의 중요성이다.

 

   명세는 관련 표준들(문자에 관련된 표준인 Unicode와 ISO/IEC 10646, 언어 식별 태그를 위한 인터넷(Internet) RFC 1766, 언어명 코드를 위한 표준 ISO 639, 국가명 코드를 위한 ISO 3166)과 함께 확장 가능한 마크업 언어 버전 1.0을 이해하고 XML을 처리할 컴퓨터 프로그램을 설계하는데 필요한 정보들을 제공한다.

 

1.5 용어 정의

 

   명세의 본문에는 XML 문서를 기술하는데 사용하는 용어들을 정의한다. 아래에 열거한 용어들은 이러한 정의를 내리고 XML 처리기의 기능을 기술하는데 쓰인다.

 

해도 좋다(may)

    적합한 문서와 XML 처리기가 허용되지만 기술된 대로 동작하지 않아도 좋다.

 

해야 한다(must)

   적합한 문서와 XML 처리기가 기술된 것처럼 동작하여야 하고, 그렇지 않으면 오류이다.

 

오류(error)

   명세에 있는 규칙들에 위반되는 것으로 결과는 정의되지 않는다. 적절한 소프트웨어가 오류를 발견하여 알려주고 이를 복구할 수도 있다.

 

치명적 오류(fatal error)

   적절한 XML 처리기가 반드시 발견하여 응용에 보고하여야 오류이다. 치명적 오류가 발생하면 처리기는 이상의 오류가 있는지 탐색을 계속해 응용에 알려 준다. 오류를 수정하기 위해 처리기는 응용에 접근할 있는, 문자 데이터와 마크업이 뒤섞인 문서로부터 처리되지 않은 데이터를 만들 수도 있다. 치명적 오류가 발견되면 처리기는 정상적인 처리를 멈추어야 된다. 예를 들어 처리기는 정상적인 방법으로 응용에 문서의 논리적 구조에 관한 문자 데이터와 정보를 계속 보내지 말아야 된다.

 

사용자 선택(at user option)

   적절한 소프트웨어는 기술된 대로 동작을 해도 좋거나 동작해야 한다(문장내 실행 방법을 지정한 동작에 따라서), 만약 그렇다면, 사용자가 설명된 동작을 선택하거나, 거절 방법을 제공하여야 한다.

 

유효성 제약(validity constraint)

   유효한 XML 문서에 적용되는 규칙. 유효성 제약에 대한 위반은 오류이고, 사용자의 선택 시에 이들은 유효한 XML 처리기에 의해 반드시 보고되어야 한다.

 

좋은-형식 제약(well-formedness constraint)

   모든 좋은-형식 XML 문서에 적용되는 규칙. 좋은-형식 제약의 위반은 치명적 오류이다.

 

정합(match)

   (문자열 또는 명칭에 관하여) 비교되는 개의 문자열이나 명칭은 반드시 같아야 한다. ISO/IEC 10646로 표현 가능한 문자들(예를 들면 미리 만들어지거나 기본+구별부호 형식의 문자들)은 양쪽의 문자열에서 동일하게 표현되었을 경우에만 정합된다. 사용자 선택에서 처리기는 이러한 문자들을 어떤 정규화 형식으로 일반화 있다. 어떤 경우에도 폴딩(folding)은 이루어지지 않는다. (문법에서 문자열과 규칙에 관하여) 문자열이 어떤 문법적으로 올바른 제품에 의해 만들어진 언어에 속한다면 문법과 정합된다. (내용과 내용 모델에 관하여) 요소는 "유효 요소"의 제약에 기술된 형식에 부합하면 이들 선언과 정합된다.

 

호환성에 대하여(for compatibility)

   오로지 XML이 SGML과 호환성이 있도록 하기 위하여 포함된 XML의 특성.

 

상호운용성에 대하여(for interoperability)

XML 문서들이 SGML 처리기들(ISO 8879에 WebSGML 적응 부록의 포함이전)의 현재 설치된 기본에 의해 처리될 있는 기회를 높이기 위해 포함된 구속력이 없는 추천사양.

[Net] Xsl 의 사용 Tip ..

.Net 2008. 10. 15. 15:46 posted by 무명시인

요런 기능이 필요 했어~~

DataSet(DataTable) -> ........... -> 웩셀~

그동안은 꽁수로 페이지에 뿌려 헤더 정보를 읽어 주저리 주저리..

머 그랬었는데..

그냥은 안되나??

하는..

그래서..

방법은 이거야~

DataSet(DataTable) -> Xml -> Xsl -> 웩셀~

빠뜨...

Xsl 이...

맘대로 컨트롤이 안되~~

역시 궁극의 필살기 삽질 + 구글링에 들어 갔지..

여기서 TIP !!

<?xml version="1.0" encoding="utf-8"?>

<xsl:stylesheet version="1.0"
    xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

<xsl:template match="/">
 <HTML>  
  <BODY>
   <TABLE>
    <TR>
     <TD>ID</TD>
     <TD>CODE</TD>
     <TD>COUNTRY</TD>
    </TR>
    <!--//roop-->
    <xsl:for-each select="dsRoot/tb01">
     <TR>
      <TD>
       <xsl:value-of select="ID"/>
      </TD>
      <TD>
       <xsl:value-of select="CODE"/>
      </TD>
      <TD>
       <xsl:value-of select="COUNTRY"/>
      </TD>
     </TR>
    </xsl:for-each>
    <!--//roop-->
   </TABLE>
  </BODY>  
 </HTML>
</xsl:template>

</xsl:stylesheet>

빨간 부분의 맵핑!!


[雜說] 메타 블로그를 위한 아이디어

雜物 2008. 9. 12. 14:16 posted by 무명시인

1. 다른 곳에 블로그를 개설한다.

2. 메타 블로그사이트에 가입을한다.

 -> 가입하고 RSS Feed 등록시 우선 포스트를 읽어 온다.
 -> 신규 포스트는 읽어 오기 버튼을 둔다

3. 메타 블로그 로그인시 우선 포스트를 읽어온다.


--------------------------------------------------------------------

** 참고 사이뚜 **

http://www.hoons.kr/MetaBlog/Main.aspx
http://mixsh.com/
http://www.pressblog.co.kr/
http://www.blogkorea.net/
--------------------------------------------------------------------

** Rss 피드 테스트 **

 http://blog.daum.net/xml/rss/limhyunc
http://stg.mixsh.net/img/medium/4/2/0/1697420.png
http://stg.mixsh.net/img/medium/2/6/2/1697262.png
http://stg.mixsh.net/img/medium/2/7/5/1697275.png
http://mixsh.com/media/11827

--------------------------------------------------------------------

** 결국 **

중요한것은 Xml 파싱과..

에러 발생의 최소화..

XML 파싱하는 중..

은근히 Exception이 많더라는..