JSON 스키마와 XML 스키마 비교

JSON 스키마 표준과 해당 PHP 구현을 찾고있었습니다. 거기서 약간의 오픈 소스를 기대하고 나는 단지 하나의 PHP 구현을 발견하고 놀랐다. 이 기술 (JSON)과 스키마 lib를 사용하여 들어오는 브라우저 요청을 구문 분석했습니다.JSON 스키마와 XML 스키마 비교

이 자연스러운 구문 분석/유효성 검사 활동은 XML에서 자연스러운 것처럼 보이며 왜 이것이 JSON의 경우가 아닌지 궁금하게 만듭니다.

나는 의심의 여지가있다. JSON 구조체 데이터 교환을 수행하거나 XML로 전환해야합니까? 필자는 XML에 비해 JSON을 간단하고 덜 복잡한 구문으로 선택했습니다.하지만 전 세계에서 기존 표준을 모두 재개발해야한다면 이러한 인수가 더 가볍게됩니다. 또한 JSON을 선택하여 웹 서버와 모바일 앱 간의 통신 크기를 제한하고자했습니다. 혜성 응용 프로그램을 가지고 노는 XMPP는 실시간 채팅 대화 텍스트 또는 비디오 기반 메시지를 위해 Google, Facebook과 같은 큰 이름으로 구현되고 사용되는 것 같습니다.

그래서 실제 질문은 다음과 같습니다

는 트래픽이 일어날 것을 알고, 단순 이상에 초점을 원하는 가난한 웹 서버 개발자 JSON을인가 (여기, 착각하지, 나 자신을 포함)?
JSON 스키마 용 IETF 초안은 서버 측 (PHP)에 구현이 거의 없으므로 심각한 작업입니까?
내가 누락되었거나 어쩌면 가장 좋은 통신 패턴은 서버에서 XML로 데이터를 보내고 json 응답 (많은 json 스키마 구현이 javascript에 있음)을 기대하는 것입니까?
아니면 JSON을 사용하는 웹 개발자가 들어오는 요청 데이터를 깊이 테스트하지 않기 때문에 개발자 커뮤니티가 이러한 우려를 제대로 충족시키지 못했다는 실제적인 증거에 직면 했습니까?

여기에 몇 가지 경험이 누락되었습니다.

출처

2012-03-24 Alain

다른 사람들이 귀하의 실제 질문에 답하는 것처럼 보이지만, 한 가지 구현만을 발견하면 몇 가지를 놓친다는 점을 지적하고 싶습니다. 예 : Java의 경우는 https://github.com/fge/json-schema-validator이고 JavaScript로 구현 된 몇 가지 사례가 있습니다. – Eric

이 자연 구문 분석/검증 활동은 XML 자연 보인다 이것이 JSON의 경우가 아닌 이유 나를 궁금합니다.

JSON은 JavaScript로 작성된 풍부한 기능의 사용자 인터페이스가있는 웹 애플리케이션을 유명하게 만들었습니다.JSON은 서버의 데이터가 JavaScript 객체에 직접 매핑 되었기 때문에 완벽했습니다. Ajax를 사용하여 GET URL을 방문하고 객체를 다시 가져오고, 구문 분석이나 다른 것을 할 필요가 없습니다.

이러한 풍부한 인터페이스는 JavaScript를 매우 대중적인 언어로 만들어 주었고 JSON이 분명히 탔고 인기가 높아짐에 따라 "꺾쇠 괄호"를 뒤집을 최고의 후보가되었습니다.

그러나 XML에는 오랜 역사가 있습니다. 그것은 accompanying specifications의 제비를 가진 성숙한 기술입니다. JSON은 그걸 따라 잡고 있습니다.

2011 년 5 월에 the draft specification 년이 만료되었지만 JSON 스키마 지지자는 해당 항목을 have reached a pretty close to final version라고 생각합니다. 그렇다면 JSON 스키마에 대한 미래가 무엇인지 파악할 수 있습니다.

나는 놀랐다
는 단 하나의 PHP를 구현을 찾을 수 [...] 단지 몇 구현이 서버 측 (PHP)에 존재하기 때문에, JSON 스키마에 대한 IETF 초안은 심각한 일이다합니까?

이 PHP 구현은 JSON 스키마 초안의 마지막 버전에 따라 JSON의 유효성을 검사합니까? 그렇다면 다른 구현이 필요합니까? 명세가 심각하다는 것을 입증하기 위해 많은 구현이 필요합니까? 그게 바로 XSLT 2.0 is not serious because Microsoft didn't bother to implement it입니다.

마지막 질문은 수신 데이터의 유효성을 검사해야합니다. 사용자 요청을 받아서 서버에 던지거나 "붙어 있기를 바랍니다". 당신은 그것을 확인합니다; JSON 스키마는 JSON 데이터의 유효성을 검사하는 유일한 방법이 아니므로 JSON을 사용하는 웹 개발자가 들어오는 요청 데이터를 심층적으로 테스트하지 않는다고 가정하지 마십시오.

결론적으로 말하자면 JSON이 XML을 완전히 대체 할 수 없다는 것입니다. So use each technology where appropriate.

출처

2012-03-25 17:41:10 Bogdan

IETF JSON 수비수에게 불쾌감을 주면 사과드립니다. 내 생각은 내 실제 연구에 대한 순진한 분석에서 비롯된 것이다. 세 번째 초안, 잠시 후 만료되었으며, industrie의 구현에 대한 제한된 약속. 내 의도는 순수하게 이해하고있다. 왜 아무도 서버 측 (php)에서이 문제를 더 널리 구현하지 못한 것 같다. 진짜 질문은 : 내 데이터의 유효성을 검증하려고합니까? 그렇지 않다면, 당신이 언급 했으므로 json 입력의 유효성을 검사하는 좋은 일을하는 곳에서 당신이 선호하는 라이브러리는 무엇입니까? 마지막으로 관련 SO 질문 (나는 그것을 놓친) 주셔서 감사합니다. – Alain

@Alain : 나는 당신을 이해는이 기술의 낮은 채택 자체가 활성화되지 않습니다 ((http://sourceforge.net/projects/jsonschemaphpv/) [언급 할 가치가 하나의 PHP 구현이] 정말이 있다는 사실에 관심있다) 그러나 때때로 이러한 일들이 일어납니다. ** JSON의 인기로 인해 모든 종류의 상황에서 사용되기 시작했으며 모범 사례에는 따라갈 시간이 없었습니다. **. 유효성 검사의 경우 JSON은 대부분의 언어에서 기본 형식이 아닙니다. 즉, JSON이 기본 객체로 변환됩니다. – Bogdan

... 변환에 실패하면 첫 번째 유효성 검사를받습니다. 변환이 통과되면 언어가 표현 대신에 을 사용하여 네이티브 객체의 유효성을 검사하는 것이 더 적합합니다. 스키마는 실제로 유효성 검사 프로세스를 단계적으로 수행함에 따라 매우 유용하지만 스키마가 누락 된 것은 JSON 유효성 검사를 수행하는 데있어 중요한 요소가 아닙니다. – Bogdan

데이터 교환에 대한 많은 대안이 있으며 여기서는 2 가지 유명한 기술을 살펴 보겠습니다. XML은 일반적으로 JSON보다 크기가 크지 만 XML은 더 유연하며 더 많은 작업을 수행 할 수 있습니다. 설탕의 관점에서 콜라와 다이어트 콜라처럼.

XML을 제공하는 서비스가있는 경우 XML을 JSON에 직렬화하고 둘 다 제공하는 어댑터를 만드는 것이 좋습니다. 다른 레이어를 추가하여 재개발을 피하기 만하면됩니다.

읽었습니다. http://www.thomasfrank.se/xml_to_json.html

HTTP 압축을 사용하면 XML 파일을 네트워크 전체에서 작게 유지할 수 있습니다.

내 말. 복잡한 데이터의 경우 XML을 사용하고, 간단한 데이터의 경우 JSON을 사용합니다. 나는 둘 다 사용할 것이다.

미래는 어떨까요? 나는 내가 모른다는 것을 말할 것이다.

건배!

출처

2012-03-25 03:29:32 DAEMYO

귀하의 기사와 다른 기사를 읽었습니다. 내가 이해하는 것을 설명하고 내 가정을 확인해 보도록하겠습니다. + 내 서버에서 xml 응답으로 재생하는 것은 힘들 수 있으므로 개발자의 작업을 단순화하기 위해 동등한 xml을 JSON 객체로 변환합니다.이 객체는 브라우저 환경에서 조작하기 편리한 객체가됩니까? 좋아, 그건 플러스 야. – Alain

+ 그러나 주요 점은 검증에 관한 것입니다. 서버 또는 클라이언트는 수신 된 데이터와 다른 품질을 검증해야합니다. 내 서버와 내 클라이언트의 브라우저 안정성 및 온 전성을 위해 내 데이터를 테스트하지 않은 경우 데이터를 처리 할 수 없습니다. 그렇다면 왜 JSON 세계에서는 여전히 존재하지 않는 것일까 요? – Alain

데이터 유효성 검사 : 예를 들어,이 데이터 구조의 균형이 맞춰 졌거나 속성이 누락되었거나 일부 데이터가 경계를 벗어났습니다. 프로세스의 일부 해커 또는 수정하지 않은 버그로 인해 데이터가 손상되었습니다. 나는 강력하게 믿을 수있다. (논란의 여지가 있기 때문에 자유롭게 의견을 말하기 바란다.) 내 서버와 내 클라이언트의 브라우저 안전성과 온전함에 대해 이러한 (그리고 그 이상의) 주장에 대해 테스트하지 않았다면 어떤 데이터도 처리 할 수 없다. – Alain

이 유용한 것으로 나타났습니다. Google groups #json-schema 및 JSON Schema: specifying and validating JSON data structures.

출처

2012-03-25 03:44:04

당신은 당신의 질문에 많은 다른 것들을 물어와 내가 제대로 당신이 정말로 원하는 것을 캡처 한되지 확신하지만, 여기에 몇 가지 생각이 있습니다 : 당신은 그들이 있습니다 JSON과 XML 데이터를 모두 표시 할 수 있지만

꽤 다릅니다. 심지어 여기에 정확한 것을 시도 할 것이다, 그러나 당신에게 올바른 생각주고 희망하고 있지 않다 :

JSON가 경량 방법을 (비) 직렬화 및 주변 값의 키/값 및 목록을 전달합니다. 가벼우 며 쉽고 편리하며 일부는 XML보다 더 읽기 쉽다고 주장합니다. 직렬화/역 직렬화는 모든 언어에서 쉽게 수행됩니다.
XML은 확장 가능한 마크 업 입니다.은 데이터를 나타낼뿐만 아니라 규칙 (또는 원하는 경우 프로토콜)을 지정합니다.

이것은 스키마를 제공하는 것 뿐만이 아닙니다.

<album> 요소가 정의 된 곳에서 음악 정보를 교환하도록 설계된 XML 기반 표현을 예로 들어 보겠습니다.

<album>The Contino Sessions</album>

이 XML을 구문 분석하기 위해 개발 된 클라이언트는 태그를 해석하는 방법을 알게됩니다. 이제, 푸 바는 나중에 올 등으로 확장 프로토콜에 구축 할 수있는 다음 foobar 네임 스페이스에 대해 아무것도 알고하지

<album foobar:genre="Electronica">The Contino Sessions</album>

기존 고객은 평소와는 foobar:genre을 무시로 작업을 계속합니다. foobar을 이해하도록 개선 된 사람들은 장르 주석을 구문 분석합니다. 이것은 XML이 단순히 데이터 표현이 아닌 방법을 예시로 보여줍니다. JSON을 사용하여 동일한 작업을 수행하는 방법을 생각해보십시오. 당신은 동일한 비용으로 할 수 없다는 것을 알게 될 것입니다. 따라서 JSON에서 XMPP 구현을 수행 할 가능성은 거의 없습니다.

즉, XML에는 자체 부담이 있습니다. 좋은 XML 파서를 만드는 것은 어렵습니다. 간단한 직렬화에 XML을 사용하는 것이 어렵다.

JSON 잘하고 쉽게 주위에 당신은 단지 데이터를 전달하는 경우 : 그것은 요컨대 등

긴 문서를 파악에 올 때 인간의 가독성은 두통에 대한 완곡 어법이다.
제 3 자 XML에 의해 다른 방식으로 확장 될 프로토콜을 개발할 때입니다.
앞뒤 전환은 나쁜 생각입니다. XML을 JSON으로 변환 할 수는 없습니다.

출처

2012-03-25 10:42:47 ggozad

그래서 내 데이터에 대한 많은 클라이언트를 발견하면 xml을 사용하여 해당 클라이언트와 해당 확장 기능을 보호해야합니다. 좋습니다. 정교한 응답을 주셔서 감사합니다, 그것은 천천히 내 생각을 분명히. 나는 왜 JSON 스키마 lib의 무리 같은 것이 없는지에 대해 의아해하고있다. ** 내가 말하고있는 사람 (클라이언트, 서버, ...)과 상관없이 항상 들어오는 것을 검증하지 않아야합니까? 요구 사항이 너무 많거나 개발자 팀이 자체 서버와 클라이언트간에 손상된 (해킹 된) 데이터를 테스트하지 않아도 되나요? ** – Alain

많은 웹 앱에서 유효성 검사를 수행하지 않는다고 생각할 것입니다. 물론 이것은 나쁜 습관이며 당연히 피해야합니다. 반면 JSON에 대한 스키마 지원이 없다고해서 유효성 검사가 중단되는 것은 아닙니다.실용적인 응용 프로그램이 JSON의 문제라고 생각하지 않습니다. – ggozad

답변

관련 문제