2007. 3. 13. 15:22
JSON vs. XML 그거/Tech2007. 3. 13. 15:22
Ajax를 이용한 웹 애플리케이션이 늘어나면서부터 서버와의 통신에 있어 어떠한 데이터 교환 형식을 이용할지에 대한 관심이 부쩍 늘어난 것 같다. 이러한 관심의 예로 JSON(Javascript Object Notation)을 기존 XML을 대체할 데이터 교환 규약으로 보고 있는 사람들이 많으며 26일 InfoQ에서도 이러한 JSON과 XML에 대한 논쟁?을 기사로 올렸다. XML은 지난 몇년에 걸쳐 업계의 노력으로 이제는 완전히 시장이 포화상태에 있다. 반면 JSON은 그동안 사람들에게 많이는 알려지지 않았지만, 그 고유의 단순함 내지는 경량모델로 최근에 개발자들 사이에서 인기를 얻고있는 데이터 교환이다. 뭐 사실 구글에서 조금만 검색해도 JSON에 대한 이런 이야기는 많이 찾아볼 수 있다. -_-;
JSON은 Head Rush Ajax라는 책에서 처음 접했는데, 처음보는 것이고 또 아직은 XML이 더 눈에 익숙하고 더 연마해야 하는지라 자세히 살펴보지는 않았는데, JSON에 관한 ppt를 보니 사람들이 왜 JSON에 열광하는지 조금 이해가 갔다. 사실 XML은 그 규약 자체도 상당히 엄격한(XML의 well-formedness를 준수하는 데만도 10가지 규칙을 내세운다.)데다 네임스페이스나 그런것도 복잡하고...
아무튼 JSON을 지지하는 측에서 JSON이 데이터 교환에 있어서의 장점은 이렇단다. (대충 직역)
1. 사람과 동시에 기계도 읽을 수 있는 형식이다.
2. 유니코드를 지원하는데, 따라서 거의 모든 인간 언어가 소통 가능하다.
3. 자기문서화적이다(? 원문 - self-documenting). 즉, 특정 값 뿐만 아니라 구조와 필드명까지 서술한다.
4. 엄격한 문법과 필수적인 알고리즘을 허용하는 파싱 요구조건이 단순하며, 효율적이고, 일관성있다.
5. 대부분의 일반 컴퓨터 과학에서 제시하는 자료구조인 레코드, 리스트, 트리를 표현할 수 있는 능력을 지녔다.
반면에 JSON 사용에 대해 반박하는 일반적인 논쟁거리는 다음과 같다.
1. JSON은 네임스페이스를 갖지 않는다. 따라서 모든 객체 자체가 네임스페이스이며 키 집합은 다른 객체에 독립적이며 심지어 배타적으로 중첩된다. 또한 JSON은 애매모호함을 피하기 위해 다른 언어에서 하는 것과 같이 컨텍스트를 이용한다.
2. JSON은 검증기가 없다. 궁극적으로 모든 애플리케이션이 입력에 대한 검증을 책임져야 한다. 이는 위임될 수 없으나 YAML 검증기는 사용할 수 있다.
3. JSON은 확장될 수 없다. 사실 그럴필요가 없다. JSON은 유연하며 어떠한 비순환 데이터 구조를 표현할 수 있다. 새로운 필드가 기존 구조를 폐기시키지 않고도 추가될 수 있다.
4. JSON은 XML이 아니다. Douglas는 JSON이 XML에 비해 훨씬 더 심플하다고 주장한다.
읽고나서 보니 Douglas 이 사람 JSON을 발명한 아키텍트네.. -_-;;
아무튼 JSON이 XML에 비해 데이터 교환에 있어서는 상당히 간단한 것임에는 틀림없고, 어디에 어떻게 사용되는 지는 그 상황이 어떠한 상황이냐에 달린 것 같다.(어중간한 으로 마무리.. -_-v)
그나저나 JSON은 뭐라고 발음한다냐? '제이손'? '제이에스-온'? '제이에스오엔'?, '자바스크립트 오브젝트 노테이션~ 헉헉'?
출처 : decoder.egloos.com
JSON은 Head Rush Ajax라는 책에서 처음 접했는데, 처음보는 것이고 또 아직은 XML이 더 눈에 익숙하고 더 연마해야 하는지라 자세히 살펴보지는 않았는데, JSON에 관한 ppt를 보니 사람들이 왜 JSON에 열광하는지 조금 이해가 갔다. 사실 XML은 그 규약 자체도 상당히 엄격한(XML의 well-formedness를 준수하는 데만도 10가지 규칙을 내세운다.)데다 네임스페이스나 그런것도 복잡하고...
아무튼 JSON을 지지하는 측에서 JSON이 데이터 교환에 있어서의 장점은 이렇단다. (대충 직역)
1. 사람과 동시에 기계도 읽을 수 있는 형식이다.
2. 유니코드를 지원하는데, 따라서 거의 모든 인간 언어가 소통 가능하다.
3. 자기문서화적이다(? 원문 - self-documenting). 즉, 특정 값 뿐만 아니라 구조와 필드명까지 서술한다.
4. 엄격한 문법과 필수적인 알고리즘을 허용하는 파싱 요구조건이 단순하며, 효율적이고, 일관성있다.
5. 대부분의 일반 컴퓨터 과학에서 제시하는 자료구조인 레코드, 리스트, 트리를 표현할 수 있는 능력을 지녔다.
반면에 JSON 사용에 대해 반박하는 일반적인 논쟁거리는 다음과 같다.
1. JSON은 네임스페이스를 갖지 않는다. 따라서 모든 객체 자체가 네임스페이스이며 키 집합은 다른 객체에 독립적이며 심지어 배타적으로 중첩된다. 또한 JSON은 애매모호함을 피하기 위해 다른 언어에서 하는 것과 같이 컨텍스트를 이용한다.
2. JSON은 검증기가 없다. 궁극적으로 모든 애플리케이션이 입력에 대한 검증을 책임져야 한다. 이는 위임될 수 없으나 YAML 검증기는 사용할 수 있다.
3. JSON은 확장될 수 없다. 사실 그럴필요가 없다. JSON은 유연하며 어떠한 비순환 데이터 구조를 표현할 수 있다. 새로운 필드가 기존 구조를 폐기시키지 않고도 추가될 수 있다.
4. JSON은 XML이 아니다. Douglas는 JSON이 XML에 비해 훨씬 더 심플하다고 주장한다.
읽고나서 보니 Douglas 이 사람 JSON을 발명한 아키텍트네.. -_-;;
아무튼 JSON이 XML에 비해 데이터 교환에 있어서는 상당히 간단한 것임에는 틀림없고, 어디에 어떻게 사용되는 지는 그 상황이 어떠한 상황이냐에 달린 것 같다.(어중간한 으로 마무리.. -_-v)
그나저나 JSON은 뭐라고 발음한다냐? '제이손'? '제이에스-온'? '제이에스오엔'?, '자바스크립트 오브젝트 노테이션~ 헉헉'?
출처 : decoder.egloos.com
'그거 > Tech' 카테고리의 다른 글
| 패턴과 프레임워크 (0) | 2007.03.14 |
|---|---|
| Crossing borders: JavaScript의 특징 (한글) (0) | 2007.03.13 |
| JSON (JavaScript Object Notation) 개요 (0) | 2007.03.13 |
| 소프트웨어 개발 방법론 충격진화「MDA」 (0) | 2007.03.05 |
| MDA는 소프트웨어 개발의 산업혁명을 가져올 것인가? (0) | 2007.03.05 |
