사실 XML이나 JSON이나 거기서 거기같다는 생각을 자주 하는데요..

결과가 비슷하면 상대적으로 XML보다 JSON이 좋은 것 같습니다.

JSON의 장점은

1) 파일이 더 작고

2) 파싱이 더 빠르고 간단하며

3) 파싱 결과가 직접 조작/참조가능한 객체 형태로 나오고

4) JSON 파일은 브라우저쪽에서 직접 가져가서 쓰기에도 좋죠.

XML이 조금 더 형식화되어 쓸 수 있긴 하지만 어차피 큰 차이는

없는 것 같구요...

실제로 요즘 보면 XML은 한물 가고 JSON이 대세인 것 같긴 한데

궁금한건 애초에 왜 XML이 JSON을 젖힐 수 있었느냐는거죠...

JSON이 무슨 최신 기술도 아니잖습니까.. 

왜 옛날엔 JSON의 장점을 몰라주다가 뒤늦게 알게 된걸까요..

흠.. 여기서 저의 추측 회로를 돌려보자면 JSON은 아무래도

자바스크립트 기반 기술이고.. 자바스크립트라는 언어 자체가

메인스트림 언어로 주목받기 시작한지 얼마 안되었기 때문일까요?

그반면에 XML은 웹쪽 말고도 데스크탑 어플에서도 활발하게 쓰이면서

(그쪽은 대안이 없죠) 저변이 넓었으니까요.

실제로 데스크탑 어플들의 상당수는 여전히 설정파일을 xml로

저장하니까요.. 데스크탑 어플이 json 쓸 일은 없겠죠.

XE 사용자 매뉴얼 읽다가 왜 XML을 쓸까 생각해봤습니다.

제가 요즘 쓰는 phalcon 프레임워크도 XML 쓰고

사실 PHP 프레임워크중에 XML 쓰는게 많잖아요...

일종의 유행 아니었나 싶은데...

내 생각엔 XML보다 JSON이 좋은 거 같아! 난 JSON쓸거야

이런 개발자가 별로 없었나보죠...

  • ?

    JSON이라는 형식 자체가 정식으로 제정된것이 2014년이니까요.

    XML은 그 전에도 있었고 대부분 언어가 지원하고 있었으니

     

  • ?
    호환성 문제로 계속 그렇게 쓰거나 지원하거나 겠죠. 유행이었던건 아닙니다 뭐 따지면 XHTML이라는 괴생물체가 있었죠
  • ? ?

    2014년? JSON이 의외로 신기술이었군요.. 겨우 그것밖에 안되었다니..
    웬지 체감상 꽤 오래된 기술같은데 말이죠.. 2014년 이전엔 아예 안쓴건가요?

    AJAX는 되게 오래되었던데 (2006년 책같은 것도 있던데) 

    옛날 AJAX는 그냥 플레인 텍스트로 데이터를 주고 받아서 일일이

    파싱했나보죠?

  • ? ?
    정식으로 지정되기 전에도 통일되지 않은 상태로 쓰이긴 했습니다. 규격이 정해졌다고 봐야죠.
  • profile

    자바나 C#처럼 엄격한 타입 시스템을 갖춘 언어들은 XML과 궁합이 잘 맞습니다. 각각의 태그를 클래스와 매핑하고, DTD를 사용해서 검증할 수 있거든요. 이런 언어의 관점에서 JSON은 지나치게 자유롭지요. Anonymous class, array, dictionary를 마구 섞어 써야 표현할 수 있잖아요. 모든 변수에는 타입을 지정해야 하는데, 파싱 결과가 어떤 타입으로 나올지 전혀 알 수가 없습니다! 대개 자바나 C#을 사용하는 기업용 소프트웨어에서 XML을 선호하는 것은 단지 보수적인 습성 때문만은 아닙니다.

     

    게다가 이런 사람들이 시장을 지배하고 있다 보니 XML이 당연히 버프를 받았습니다. 90년대 말 ~ 2000년대 초에는 XML이 천하를 통일할 거라는 꿈을 꾸기도 했지요. (당시에는 JSON이라는 것 자체가 없기도 했지만...) HTML을 XML화하겠다고 XHTML이라는 것을 만들기도 했고, 심지어 2000년대 중반에 확정된 워드, 엑셀, PPT 파일 표준은 여러 개의 XML 문서와 첨부파일들을 zip으로 묶어놓은 것에 불과합니다. 진짜예요. docx나 xlsx 파일을 압축 프로그램으로 열어보세요. 죄다 XML이예요. 데이터 추출하기 은근히 쉽습니다 ㅋㅋㅋ

     

    XE도 전반적인 구조가 심히 자바스러운(?) 녀석이라... 자연스레 XML로 기울게 된 것 같습니다. 하긴 XE가 처음 나왔을 때는 PHP에서 JSON을 처리할 수 있는 함수조차 없었지요. (XML 처리 기능은 그 때도 막강했습니다.) JSON을 인코딩하는 함수를 따로 만들어 썼는데, 그게 아직도 func.inc.php에 남아 있습니다.

  • profile ?

    하긴.. 제가 설정같은거 저장하는 용도에서만 생각했는데
    구조화된 데이터를 저장한다고 접근하면 XML이 확실히 편리하겠군요.
    설정같은데서야 XML 태그 이름 = json 필드 이름으로 1:1 매치가 되지만
    더 커지면 XML은 태그 이름은 type으로 쓰고 별도 이름 지정이 가능하니...
    요즘 문서 파일이 XML이라는건 알고 있었는데도 미처 떠올리진 못했네요.

  • profile

    PHP, 자바스크립트처럼 엄격한 타입을 강요하지 않는 언어들끼리 데이터를 교환하기에는 JSON이 훨씬 편리한 것은 사실이지요. 라이믹스에서는 exec_xml() 함수를 사용하더라도 내부적으로는 JSON을 주고받도록 고쳐서 XML 인코딩과 관련된 문제를 크게 줄인 바 있습니다.

     

    그러나 XE에서 사용하는 테이블 스키마나 스킨 설정처럼 일정한 구조를 선언하는 "문서"의 형태를 가진 데이터를 JSON으로 표현하려면 은근히 귀찮아요. 배열 안에 객체를 넣고 그 안에 또 객체를 넣고... 쉽게 구분할 수 있는 태그와 달리, 거의 비슷하게 생긴 중괄호 대괄호들 때문에 계층이 늘어나면 한 눈에 들어오지도 않습니다. 사람이 편집해야 하는 파일이라면 순수 PHP로 작성하지 않을 바에야 XML이 그나마 낫습니다. (YAML은 희망사항일 뿐... ㅜㅜ)

     

    라이믹스에서는 앞으로도 XML 의존도를 점점 낮춰갈 계획이지만, 쿼리나 스킨 설정 같은 것까지 JSON으로 대체하기보다는 차라리 순수 PHP를 사용하는 편이 낫다고 생각합니다.

  • ?
    위 기진곰님 말씀대로 윈도우 프로그래밍 조금 하다보면 JSON이 더 귀찮습니... 뭐 하려하면 라이브러리를 따로 달아줘야 하고 이것저것 파싱된 값이 뭔지 체크도 해야하고...이것저것 많이 귀찮아집니다.
  • ? ?
    예.. JSON이 스크립트 언어 전용인건 분명하죠. 저도 자바에서 JSON 쓰니까 미칠 것 같더군요. JSON 라이브러리란 라이브러리는 전부 다 깔아서 써봤는데 맘에 드는게 하나도 없더란...