XML은 HTML을 대신할 것인가?
http://www.ozlap.com/_temp/xml.zip
위의 첨부 파일을 풀면 xml.doc, sales.xml, transform.xsl 파일이 나옵니다. xml.doc 파일은 이 질문을 위해서 관련 배경 지식을 설명하는 내용입니다. xml.doc 파일을 한번 읽어보시고 sales.xml 파일을 웹브라우저에서 한번 열어보시고, 코드를 조금 보신 뒤에 질문에 답변해주시면 감사드리겠습니다. (물론... 바로 답변해주셔도 되고요...).
이제부터 질문입니다. 좀 길어요...
요즘 XML을 좀 heavy 하게 공부하고 있는 데...(서버 프로그래머 입장이 아니라 HTML 코더 입장에서...)
앞으로 월드와이드웹이 XHTML(XML에 기반해서 수정된 HTML) + SVG(벡터 그래픽 XML 포맷. 어도브 일러스트레이터!!!) + SMIL(멀티미디어 동기화) + MathML(수식 표현 언어)의 결합된 형태로 갈것이라는 결론을 내렸습니다.
워드나 파워포인트를 생각해보면 그대로 웹으로 구현하는 데 있어서 문제가 되는 것이 도형과 수학식입니다. SVG와 MathML이 마크업으로 그러한 정보를 기술하는 데는 문제가 없는 수준에 와있습니다.
SMIL의 경우 IE가 이미 지원하고 있으며, MathML은 모질라가 지원하고 있으며, 인터넷 익스플로러에서도 7.0이나 8.0 버전쯤에서 지원할 것 같습니다(인터넷 익스플로러 개발 팀장이 MathML이나 SVG 특히 MathML을 구현하는 것에는 관심이 있다고 말했습니다).
SVG의 경우 어도브에서 플러그인 형태로 SVG Viewer를 이미 오래전에 배포하고 있고 일러스트레이터에서 SVG 포맷으로 저장 가능합니다. SMIL의 경우, Real Player가 부족하지만 쓸 수 있는 수준까지 지원하고 마이크로소프트사는 Windows Media 플레이어로 지원하려다가 바로 인터넷 익스플로러에서 지원하는 것으로 방향을 돌렸습니다. (Direct Animation이라는 예전 자료를 msdn에서 많이 지워버렸네요...).
W3에서는 XHTML+SVG+SMIL+MathML 결합과 관련된 규약이 만들어지고 있고요...
그래서... XHTML+SVG+SMIL+MathML 형태로 웹 문서가 표현되는 것은 맞을 것 같은 데...
첨부한 sales.xml과 같은 순수히 데이터만을 나타내는 문서가 IE나 모질라와 같은 클라이언트(XML 브라우저)에서 XSL로 XHTML로 변환되는 형태로 웹문서의 포맷이 바뀔 가능성은 없을까? 하는 점이 궁금합니다.
물론 서버에서 XML을 XSL로 XHTML 변환하여 전송하는 것은 이미 우리곁에 와 있는데 웹브라우저가 XSL을 충분히 지원하는 것을 보고 그 역할을 클라이언트가 맡게 될 가능성은 없을까 하는 생각을 했습니다.
이전에는 XML은 HTML을 대체하는 것은 아니다라고 항상 이야기되었지만, 유럽에서 열린 W3C 컨퍼런스 자료를 보면, 그리고 W3C의 TBL이 최근에 쓴 글을 가만히 읽고 있으면, 미래에는 XML이 HTML을 대체한다는 느낌도 주고 있습니다. HTML을 XML이 완전히 대체하면 웹이 무척 좋아집니다. 검색엔진도 그러하고 인공지능처리엔진도 가능하고...
HTML을 XHTML로 규약을 수정하는 정도가 아니라 XML 그 자체가 웹의 문서 표준 형태로 바뀔 가능성(XML이 HTML을 완전히 대체하는 그런 상황)도 있다는 생각을 했습니다.
질문을 간략하게 정리하면...
XML을 XHTML로 변환하는 역할을 서버가 아니라 클라이언트에서 하게 되는, 즉 XML이 HTML을 완전히 대체하게 될 가능성이 있는가 하는 점입니다.
다르게 이야기해서 HTTP 프로토콜로 오는 데이터가 HTML 포맷이 아니라 XML 포맷이 바로 브라우저에서 오고 브라우저가 변환을 하는 것이 일반화될 것인가?
휴~~~ 여러 분의 의견을 듣고 싶습니다. 미래의 웹이 어떤 모습일까에 대한 궁금증에서 질문을 올려봅니다.
댓글
XML 은 대세입니다.곧 xml 까지 지원되는것 멀지않을겁니다.
XML 은 대세입니다.
곧 xml 까지 지원되는것 멀지않을겁니다.
당연히 웹서버의 부하를 줄여주기 위해서라도 브라우저에서 xml 문서를 읽을수 있어야 합니다.
그러나 xml 이 많이 쓰인다고 해도 html 문서는 없어지지 않을겁니다. 프로그래머야 xml 문서는 어렵지 않게 만들수 있겠지만 일반사람은 html 문서 만드는 것 조차도 힘들어 하는 사람이 많습니다.
처음의 브라우저는 html문서만 읽었지만 지금은 거의 모든 문서포맷을 읽어들입니다. xml 이 보편화 된다해서 브라우저가 html 문서를 지원하지 않는 일은 없을겁니다.
그래서 웹서버는 브라우저의 요청에 따라 html,xml 을 선택적으로 보내줄겁니다.
아마도 http 프로토콜이 버전업 되겠지요.
지금 웹서버가 xml 을 바로 보내지 못하는것은 아마 xml의 표준이 정착되지않고 브라우저도 지원하지 않기 때문에 그럴거라 생각이 듭니다.
표준만 정해진다면 브라우저가 xml 을 지원하는것도 그리 오래걸리지 않을겁니다.
차라리 경제학적인 문제라고 생각됩니다. 일개의 문서 형식이었던,
차라리 경제학적인 문제라고 생각됩니다.
일개의 문서 형식이었던, HTML이 산업의 성장으로 인해, 그 이상의 요구를 받으면서, 각종 꽁수들이 등장해야 했던 데에는, 그 나름의 필요가 있었습니다만. 산업의 거품이 빠지는 지금, 웹에 대한 기대가 줄어든 것은 사실입니다. 당분간( 혹은 앞으로도) 별 일 없을 것이라고 생각합니다. 산업이 이미 안정화되지 않았습니까? 기존의 기술은 교육을 통해 재생산되고 있구요. 어떤 요구가 있다면, 기존의 기업에서 더 민첩하게 만영하겠죠.
단지 브라우져 시장을 독점하고 있는 MS의 발언권이 커진다는 것만 분명한 것같습니다.
파이팅. 이혁. 재윤아빠가.
다들 잘못생각하고 계신듯.XML은 HTML을 대체하고자 나온게 아닙니
다들 잘못생각하고 계신듯.
XML은 HTML을 대체하고자 나온게 아닙니다.
XML은 서버,클라이언트 어플리케이션, 혹은 프로세스간의 데이터 전송규약입니다. 객체지향의 개념이 들어간...
데이터 전송할때 표준을 정할려고 만든게 xml입니다. 근디 html 대체하냐 마냐로 국한해서
생각하는건 기본 개념부터 잘못잡으신거에요.
실예로 xml을 이용한 SOAP(Simple Object Access Protocol), UUDI(Universal Description, Discovery, and Integration) 서비스 연구가 윈도우나 리눅스에서 한창 보완되고 있습니다.
또 요즘의 거의 모든 랭기지가 xml 파서를 지원하고 있구요.
XML의 적용분야는 데이터 전송개념이 들어간 모든 분야입니다. 그리고 많은 서비스, 어플리케이션에서 이 표준을 따르는 추세인걸로 암.
XML이 왜 필요한가를 먼저 공부해보시고,
XML을 나중에 어플제작하면서 유익하게 활용해보시길 바랍니다.
XML을 쓰는 이유는 다른 프로그램,회사에서도 이것을 쓰고 있고, 또 표준을 따름과 동시에 많은 라이브러리들이 XML을 지원하기때문에 프로그래밍하기에도 편하기때문입니다.
프로그래머시라면 아마 앞으로 다른사람한테 데이터전송해야될 프로그램짤일이 생길테고, 그때 프로토콜의 필요성을 느끼면 XML을 한번 배워보시기 바랍니다.
본문수정: UUDI -> UDDI또 오해의 소지가 있을까바..
본문수정:
UUDI -> UDDI
또 오해의 소지가 있을까바..
데이터 전송규약 -> 정보데이터 교환규약
저도 늦었지만 몇마디 적겠습니다.저도 XML을 데이터 뷰의 관점보
저도 늦었지만 몇마디 적겠습니다.
저도 XML을 데이터 뷰의 관점보단 데이터를 외부에 전달할때 쓰는 문서로 공부와 연구를 합니다.
XML이 w3c내에서도 구조적인 면에 속하는 만큼 view 부분이 떨어져 있기 때문에 향후 XML이 html을 대체하기란 상당히 시간이 흐를것으로 생각됩니다.
저 또한 XML이 향후 1,2년안에 HTML을 대체할 수 있다고 생각하였지만 갈수록 늘어나는 XML 수요는 그렇지 않더군요.
지금으로선 XML이 꼭 필요한 부분만을 제외하곤 별 다른 이견이 없을 것 같네요...
이만 제 글을 마칠까 하네요^^
서치!!
아래 글들 보면 XML에 무게가 좀 많이 실려 있군요.하지만 저는 '
아래 글들 보면 XML에 무게가 좀 많이 실려 있군요.
하지만 저는 'HTML'은 영원하리라고 생각됩니다.
XML의 장점들... 그것 대부분 서버스크립트들이 지금 다 처리하고 있지 않나요?
XML태풍이 몰아친지가 제법되었는데
눈이 보이는 것은 없군요.
원래 눈에 보이는 것이 아니지만...
모질라, 스타오피스.... 프로그램 집약적인 그런 것들 빼놓고
실제 '문서' 혹은 접근적인 것들 중에 XML을 못 보고 있습니다.
전 XML의 영역은 프로그램의 영역이지
HTML과 같은 범용의 정보 출력은 아니라고 생각됩니다.
친근한 HTML, 쉽고 편안한 친구...
음... 내공이 좀 부족한 글이군요.
Docbook이 SGML로 작성되거나 XML로 작성되지요...여기 K
Docbook이 SGML로 작성되거나 XML로 작성되지요...
여기 KLDP에 등록된 많은 문서들이 Docbook으로 제작된겁니다...
xml로 작성한 다음 스타일시트에 따라서
html,pdf등의 파일로 바뀌는 것이지요...
html이 성공할 수 있었던 것은 쉬웠기 때문이 아니었던가요? 제작이 쉬
html이 성공할 수 있었던 것은 쉬웠기 때문이 아니었던가요? 제작이 쉬웠기 때문에 웹이라는 것이 확산 될 수 있었지여.
여러 요구가 생겨나면서 xml에 대한 수요가 발생하였지만 xml은 html처럼 만만히 접근할 수 없다는 단점이 있다고 생각됩니다.
기업이나 전문적인 웹페이지의 경우 xml의 존재가 필요하지만 단순한 개인 홈같은 경우 별 필요없다는 것이지여. html하나만 충분하다 할까..
그리고 xml이 아니더라도 왠만한 스크립트 언어는 xml의 기능을 대체할 수 있지 않나요?
머 그런저런 이유로 공존하거나 현재상태에 머물지 않을까 생각됩니다.
XML은 HTML을 대신할 것인가?그럴수도 아닐수도...현재 W3
XML은 HTML을 대신할 것인가?
그럴수도 아닐수도...
현재 W3C에서 논의중이라면 포함이 가능 할수도 있겠지만
제가 보기엔 덩치가 너무 커질것 같네요.
해석을 서버에서 하느냐 클라이언트에서 하느냐를 떠나서
기존 HTML을 분석하는 간단한 브라우져들이 XML을 지원
하지 못해서 접근이 불가능하다면...
음... 어쨌든 표준은 정해질 것이고 거기에 맞는 브라우
져도 생기겠죠.
하지만 생각보다 덩치가 커지고 기존에 사용하던 브라우
져를 포기해야한다는 결론이 나온다면 제가 볼때는 다른
포트를 새롭게 지정하지 않을까 생각도 듭니다만...
즉, 기존에 사용하던 80은 계속적으로 HTML만을 위해서
남아있고 새롭게 적용되는 XML+어쩌구... 는 새로는
포트를 지정해 주는것도 관리면에서 편리할 것도 같네요.
어쨌든 제가 생각하는 결론은 XML이 HTML을 대처하는 것
보다는 서로 공존을 하지 않을까 생각합니다.
단순한 Hello를 찍는데도 복잡한 XML을 이용하고 컴파일
(XML에서도 컴파일이라고 하나요? 잠시 한번밖에 안해봐서...)
을 한다면 효율적이지가 않은건 당연할거고...
제가 내린 결론은 '공존은하되 다른 포트가 생길것이다.'
라는 것입니다.
8 0포트를 놓고 xml과 html이 경쟁할 일은 없으니..굳이 xm
8 0포트를 놓고 xml과 html이 경쟁할 일은 없으니..
굳이 xml을 위해 다른 포트가 생기지는 않을 겁니다.
이혁님이 쓰신 책 잘 보고 있습니다~~(이런 책을 써주셔서 정말 감사
이혁님이 쓰신 책 잘 보고 있습니다~~
(이런 책을 써주셔서 정말 감사합니다. 웹 레퍼~~)
여기서 이렇게 뵐줄이야...(걍 아는척 해봄^^)
질문하신 분의 문제의 핵심은 아마도 XML을 지금 배울까 말까가 아닐까
질문하신 분의 문제의 핵심은 아마도 XML을 지금 배울까 말까가 아닐까 생각합니다. 버뜨, 이러한 기술의 흥망성쇄와 상관없이 개인이 자신의 인생을 특정 기술에 매다는 것은 위험합니다.
신기술이 나오면 대체 보다는 공존하게 되는것이 서구과학의 특징이라고 생각
신기술이 나오면 대체 보다는 공존하게 되는것이 서구과학의 특징이라고 생각합니다.(뒤집기는 없음--;)
이러한 풍습(?)은 전산쪽에도 비슷하게 전승되고 있는 것이라고 생각됩니다.
제가 XML을 최초 접했을때, "장님 코끼리만지기"식이지만 정의를 다음과 같이 했었습니다.
XML은 게이트웨이(gateway)이다. 중간 매개체로 사용되는게 가장 합당할것 같다. 터미널단에는 RDB, File Format, HTML, 다양한 보안메칸니즘등 다양한 것이 있을테니, 이들 사이에 중간자 역할이 적당하지 않을까? 이런 식이었지요.
HTML을 대체하기에는 전세계가 HTML을 너무 많이 사용하고 있는듯 합니다. 인터넷상에 HTML이 등장한지 8-9년정도 되었으니, 전부 대체해야한다는 명제를 전세계인이 가진다고 할지라도, 그거 바꾸기도 어려구, 귀찮지 않을까요?
한다고 해도, 8-9년 되었으면 8-9년은 걸리지 않을까요.
환상적인 기대로는, XHTML등 웹이 XML을 준수하는 형태로 작성되어 진다면, 그리고 그 많은 정보가 잘 저장및 유지된다면, 다시 한번쯤은 검색엔진 분야가 뜨겁게 다시 시장에서 화두가 되지 않을까? 합니다.
초보--html -> html/xml 공존 -> xml
초보
--
html -> html/xml 공존 -> xml
내 생각엔 한 순간에 xml로 팍 대체되기 보다, 점차적으로 xml 로 이동할듯..
완전히 xml 세상이 되기 까지 걸리는 기간은 확실치 않음. 5년후가 아닐지...
끝.
안녕하세요. 제가 보기에 질문의 핵심은 XML이 HTML을 대체
안녕하세요.
제가 보기에 질문의 핵심은 XML이 HTML을 대체 할것인가가 아니라 3-5년후 라는데에 더 무게 중심을 두고 싶습니다. 정말 대답하기 힘든 부분이 아닐까 생각됩니다. 3-5년후면 너무도 예측하기 힘들것 같습니다. 저도 지금 XML을 사용하고 있는데 제가 접근하는 방법은 XML을 문서로서가 아니라 데이터와 VIEW의 관점에서 접근을 했습니다. 잠깐만 곁다리로 나가 보겠습니다.
제가 만드는것은 C/S 시스템인데 C/S 모두 많은 부분에서 리소스를 외부로 빼는것인데 그것을 XML로 이용한것입니다. 클라이언트쪽에서는 일반적인 (공용)컨트롤들을 미리 만들어 두고 XML로 정의해서 실행하는 방법입니다. 이부분이 정확히 맞지는 않지만 지금 현재로서는 약간의 가능성을 내포하고 있습니다. 즉, 일반 에플리케이션을 XML로 정의해서 사용하는 것입니다. 예를 들면 드랍다운 박스나 그리드를 XML로 정의해논 양식에 맞게 실행시 보여주는 VIEW 시스템입니다. 윈도우즈의 리소스를 XML로 정의해 놓은것인데 완전한 XML VIEWER는 아니고 단지 XML 형식을 차용한 정도입니다.
다른 한 부분은 XML 문서를 만들어 낼수 있게 데이터를 XML형(실제는 XML 바로 이전 단계)으로 교환하는 것입니다. 물론 DB를 이용하거나 다른쪽으로 이용하는데 별로 부담이 없습니다.
어떤분이 XML로 RDB를 이용하는것이 삽질중의 삽질이라고 말씀 하셨는데 실제로는 자동화 툴(개별 시스템에 맞게 개발해서)을 이용하면 이것 만큼 편한 방법은 아직 없는것 같습니다. 단지 제가 접근한것은 VIEWER도 단지 1-2년 내에는 유효하겠지만 그 이후에는(아마 그전부터 차세대를 준비하겠지만)별 의미가 없을듯 싶습니다. 분명 다른 방법들이 제시 될것이니깐요.
하지만 지금 현재도 그렇고 앞으로도(1년 전후) XML은 다른 형식으로 가공하기 손쉬운 포맷으로 존재하는것이 훨씬더 괜찮지 않나 생각됩니다. XML 형식이 VIEWER에서 직접 보여준다는것은 유의미 하지 않을듯 싶습니다. 이것은 XML의 VIEWER 부분으로 따로 빠져 나오지 않을까요.?
1-2년이라는 기간을 놓고 보면 현재 HTML을 보여주기 위해 JSP/PHP/ASP등 스크립터들의 역할이 상당부분 쉬워질것 같아 보이는데 이것의 부담을 덜어 주는것만해도 대단할것 같습니다. 지금 제가 C/S에서 XML을 탑재해서 자동화하는것을 1999년에 구상했는데 당장이라도 탑재되서 기업들이 사용할줄 알았는데 그게 아니더군요. 2002년말.. 거의 3년 가까이 되서야 기업들이 이것을 원하게 되네요. 아직도 반신반의 하면서 말입니다.
제 생각에 지금 이 아이디어는 궁극적으로 XML을 완전히 탑재했다는 의미로는 아닌데도 불구하고 아마 2003년도 말쯤에 적극적으로 기업에 채용되지 않을까 생각됩니다. 그러면 지금 우리가 꿈꾸는 환경은 아마도.... 흐~~
링크 걸어 놓으신 파일은 제가 열어서 보도록 하겠습니다. 읽어 보고 다시 말할 꺼리가 생기면 리풀 달겠습니다.
건강하세요.
XML이 데이터패킷으로 HTML보다 5년안에 많이 사용 하게 하려면 XM
XML이 데이터패킷으로 HTML보다 5년안에 많이 사용 하게 하려면 XML 웹서비스 부터 성공해야 할것입니다.
HTML 파싱해서 뭔가 만들어 보면 그 노가다를 다시 하기는 싫죠.. XML이었다면 아주 쉽게 할 수 있습니다...
여튼 기업환경에서는 XML은 HTML를 밀어낼것입니다.. 언젠가..(한5년 ~ 10년안에).
하지만 비기업환경에서는 HTML이 더 오랫동안 계속 사용 될거라고 생각합니다..
응용분야가 약간 다르지 않나 싶군요.XML은 단순히 데이터를 표시
응용분야가 약간 다르지 않나 싶군요.
XML은 단순히 데이터를 표시하는 규약일 뿐입니다. 거기에는 어떠한 문서의 형태를 나타내주는 기능도 없습니다.
XML+XSL이 널리 퍼지더라도 결국에는 최종 말단의 문서 포맷이 필요합니다. XML+XSL도 결국에는 스크립트(라고 할수 있으려나;;;)를 이용해서 최종 HTML 문서를 만들어줄 뿐입니다. 그리고 그런 의미의 문서 포맷이라면 XHTML이 있습니다.
데이터는 XML로, 문서 템플릿(??)은 XSL로, 웹을 위한 최종 출력물(??)은 XHTML로... 뭐 이런 식으로 분화되겠지요.
ps.방명록 CGI에 비교해 보자면... 데이터 파일은 XML이고, 방명록 스크립트는 XSL이고, 방명록이 출력해주는 HTML파일은 XHTML입니다.
글쎄요... 저는 XML은 XML이고 HTML은 HTML이라고 생각합니다
글쎄요... 저는 XML은 XML이고 HTML은 HTML이라고 생각합니다.
(따지고 들면 HTML은 SGML/XML의 subset이지만... ^^)
HTML/XHTML을 사용하지 않는다면 지금 현재로선 웹에서 XML을 제대로 보여줄 수도 없죠.
어차피 웹쪽 퍼블리싱은 타겟이 HTML이기 때문에 XSLT를 사용해서 만들어 내는것이죠.
XML의 강점내지 의미는 target device나 style에 무관하게 내용/구조에만 집중할 수 있는 것에 있다고 봐야겠습니다.
어떤 툴을 사용하든, 처리과정을 거치든 제대로 보여지기 위해선 XSL(T)로 처리를 해서 target device에서 적절히 보이게 하는 과정이 필요한 것이죠.
획기적인... 웹에 쉽게 응용할 수 있는 DTD(XML의 경우 schema도 가능)/XSL(style spec)/전용브라우저/기존 HTML 문서 변환기 등등의 솔루션(?)이 나온다면... 그래서 다양한(일반적인) XML을 지금의 HTML 보다 더 잘 표현할 수있다면, HTML은 수명을 다하겠죠.
하지만, 다년간 웹용 응용을 위해 발전해왔던 HTML을 대체할 만한 굉장한 그 무엇(?)을 금방 쉽게 만들어 내기는 쉽지 않을 것같네요.
지금의 IE에서의 처리방식도 내부적으로 MSXML을 사용해서 XML문서를 XSLT를 적용해 HTML로 변환된 결과를 보여주는 것입니다.
<?xml-stylesheet type="text/xsl" href="transform.xsl"?>
여기 href를 url로 설정하면 서버에서 가져와서 제대로 보여줍니다. 즉, 서버에서 처리(또는 변환?)를 거치지 않는 것이죠.
이걸 두고 뭐 어느정도의 분산처리가 이루어지는 것으로 봐야한다고 설명한 책도 있더군요.
참 IE 6.0 기준의 설명입니다. 제가 알기론 5.5이하는 제대로 안되는 걸로 알고 있습니다.
오랜 시간동안 문서 구조(의미 또는 내용)와 스타일을 분리시키지 못해 겪어왔던 고통(?)을 해결해 줄 수 있는 방편으로 SGML/XML을 찬양하는 사람들도 많더군요.
같은 원본에서 HTML/PDF/PS 등등 다양한 결과물을 뽑아낼 수 있다는 것은 크나큰 매력이죠. 문서 생성 뿐만아니라 유지관리에도 상당히 메리트가 있다고 봐야되겠습니다.
음... 장황설을 늘어놓았네요...^^;
그럼 이만.
흠 글을 보고 이해가 되지 않아서 여쭈어봅니다. "XML이 HTML을 대
흠 글을 보고 이해가 되지 않아서 여쭈어봅니다. "XML이 HTML을 대체할수도 있지 않겠는가?"라고 질문 하셨는데여. 제 서투른 지식으로는 XML은 커스터마스된 DTD를정의하는것 이고 HTML은 W3C에서 이미 규약된 DTD라고 알고 있습니다. 마크업이란 언어라는 점만 같고 쓰임새는 완전히 틀리다고 알고 있거든요. XML이 HTML을 대치한다는 말을 잘 이해 못하겠습니다. 설명 부탁 드립니다.
웹브라우저가 XML 문서를 XSL로 포맷팅해서 HTML 형태로 표시해준다
웹브라우저가 XML 문서를 XSL로 포맷팅해서 HTML 형태로 표시해준다면,
웹사이트 구축자의 입장에서 보면 XML이 HTML을 대체하는 것이 됩니다.
3~5년 뒤에 어떤 URI를 입력했을 때 서버에서 보내는 그 문서는
HTML 포맷으로 되어있을까요? XML 문서로 되어있을까요? 라는 것이
제 질문의 핵심입니다.
다시 말해서... XML을 HTML 포맷팅하는 역할을 웹브라우저가 맡게 되는
것이 보편화 될 것인가라는 질문입니다.
그러나 어디까지나 업체들에 의해서 자주 사용되는 XML DTD만 HTML
그러나 어디까지나 업체들에 의해서 자주 사용되는 XML DTD만 HTML을 대체하게 되겠지요.
위에서 주제를 내어놓으신 분이 의미하는 XML도 바로 이렇게 업체(또는 업계)표준처럼 인식되는
DTD만을 의미하는 게 아닐까 싶습니다.
개개인이 작성한 DTD들을 브라우저에서 다 지원할 수 있다고 보지는 않습니다.
(당연한 얘기죠.앞서 언급된 SMIL같은 것들만 지원이 확실...)
'98th student of KW-Univ., Dept of CE.
개개인이 작성한 DTD를 브라우저에서 지원하지 못할 이유가 없습니다.
개개인이 작성한 DTD를 브라우저에서 지원하지 못할 이유가 없습니다.
DTD까지 XML문서에 포함해버리면 됩니다. 또는, XML은 SGML과는 달리
DTD 없는 웰폼드 문서도 지원합니다.
위엣분이 얘기하신 표준처럼 인식되는 DTD같은 경우에는
DTD 정의가 굳이 포함되지 않더라도, 문서만으로 브라우저가 인식되는
것을 의미하는 것이겠죠.
네, 그렇습니다. 제 생각은 님이 마지막에 말씀하신 대로 입니다.그리
네, 그렇습니다. 제 생각은 님이 마지막에 말씀하신 대로 입니다.
그리고 DTD까지 XML문서로 포함해버리면 가능해지겠지요.
그러나 DTD를 만든 개인이 그것이 실제 문서로 어떻게 표
현되어야 하는지를 알리지 않으면, 본인의 의도와는 다른
파서가 등록될 수 있습니다. 한가지 대안으로 브라우저에서
플러그인 형태로 XML파서를 지원할 경우, 제작자가 자기
DTD에 대한 파서를 플러그인으로 만들어 배포하면 됩니다.
그리고 전용 파서를 따로 만들어서 다른 분들이 간편히 사용
할 수 있게 하는 방법도 있습니다.
'98th student of KW-Univ., Dept of CE.
XML을 클라이언트가 포매팅하는 것이 의미가 있을까요? 그러면 어떤 정해
XML을 클라이언트가 포매팅하는 것이 의미가 있을까요? 그러면 어떤 정해진
스키마로만 XML을 만들어야한다는 의미가 될텐데... 차라리 XHTML로 통일
이 되고 서버가 XML + XSL -> XHTML을 만들어 주겠지요.
XML이 HTML을 대신할 것인가?HTML은 분명 문제가 많습니다
XML이 HTML을 대신할 것인가?
HTML은 분명 문제가 많습니다. 데이터 중심이기보다는 문서 렌더링을 위한 표준이
므로, HTML을 처리하여 정보를 얻는데 문제가 많습니다. 특히 IE가 오류난 HTML문
서도 웬만큼 잘 보여주는 것도 HTML를 처리하는데 많은 부담을 주고 있습니다.
그래서 XML을 따르는 HTML규격이 표준화되었고 향후 XHTML 형태로 웹문서가 작성
될 전망입니다.
많은 브라우저들이 XML처리를 지원하고 있으나 이러한 방식은 아직 표준화되지 못
했습니다. IE에서 XML,XSLT로 HTML문서를 렌더링하여 보여주는 것은 앞으로 웹의
변화 모습의 한 예일 수도 있으나 어쩌면 IE만의 기능을 일 수도 있습니다.
지금 문제는 다양한 단말환경을 현재의 방식으로 지원하기 힘들다는 점입니다. PC
뿐만 아니라 PDA나 핸드폰같은 작은 화면을 가진 단말환경에서도 웹브라우징을 하
고 있습니다. 하지만 여러 제약으로 제대로 이루어지지 않고 있습니다.
결국 서버에서 XML을 이용하여 다양한 단말환경을 지월할 수 있는 체제로 변화되
지 않을까 생각합니다. 단말환경에서 바로 XML데이터를 받아 변환과정을 거쳐 화
면에 보여주는 것은 부담이 클 것 같습니다.
DB에서 생성된 데이터는 다양한 단말환경에 따라 서버에서 렌더링된 문서를 생성
하여 전송하는 형태로 갈 것입니다.
이때, 단말환경이 수용할 수 있는 다양한 XML응용표준이 XHTML안에 포함되어 클라
이언트에 전송되면 브라우저에서 이를 렌더링하여 화면에 보여주겠죠. MathML이나
SVG가 이런 형태가 될것입니다. 부분적으로 지금 웹브라우저에서 가능하며 앞으로
이런것들이 표준화되면 일반화될것입니다.
경우에 따라 MathML이나 SVG가 서버에서 이미지로 처리되어 클라이언트에게 전달
될수도 있습니다. PDA나 핸드폰에서는 후자 방식이 채택될 것입니다.
사실 XSL은 디자인 유연성이 많이 떨어집니다. 그냥 문서를 출력한다면 괜찮겠지
만 요즘처럼 복잡한 구조의 웹페이지를 구현하기는 힘들것입니다.
결론적으로 HTML은 XHTML로 진화하여 화면 렌더링을 위한 표준안으로 살아남을 것
이고 클라이언트 보다는 서버에서 XML을 이용한 컨텐츠 생성이 이루어질 것입니다
. 데이터 교환에는 XML데이터가 중심이 되겠지만 웹브라우저에 문서가 렌더링되기
위해서는 여전히 HTML이 XHTML이 되어 전송될 것입니다.
_________________________
http://joone.net
https://kldp.org/blog/2725
http://opensoftware.tistory.com
http://joone4u.blogspot.com
https://gnome.or.kr
xml 요세도 쓰나여???불편하고 코딩하기 힘든데 그걸 왜 사용하
xml 요세도 쓰나여???
불편하고 코딩하기 힘든데 그걸 왜 사용하는지....쯧쯧..
http://www.sys-con.com/xml/articlenews.c
http://www.sys-con.com/xml/articlenews.cfm?id=513
쓰는 사람들도 있군요.
[ganadist@ganadist ganadist]$ locate *.x
[ganadist@ganadist ganadist]$ locate *.xml |wc -l
4316
불편한게 제 시스템에 너무나도 많군요. :)
XML을 전혀 손대보지 않은 분 같군요. :( 반복되는 부분이 많이
XML을 전혀 손대보지 않은 분 같군요. :(
반복되는 부분이 많이 나오는 코드의 경우에는 HTML로 만드는 건 정말 삽질입니다. 디자인이라도 바꾸려고 하면 573배 삽질이죠.;
스태틱한 그런 페이지를 XML+XSL로 만들면, 문법 까다로운거랑 처음에 삽을 좀 크게 떠야 한다는 단점이 있지만 페이지 유지보수하기에는 졸라짱좋습니다.
{R}
저는 위에 글쓴 사람이 아닙니다-_-;;;저는 그런 경우 perl을
저는 위에 글쓴 사람이 아닙니다-_-;;;
저는 그런 경우 perl을 씁니다만, 어쨌거나 다중 계층의 HTML을 만들때 노가다하는건 완전 삽질입니다. 글자 한자만 바뀌어도 수십개의 HTML 파일을 건드려야 하는데... 죽을맛이죠-_-;; 이런 경우에는 졸라 짱쎈 투명 드래곤... 아니, 투명 스크립트를 쓰면 노가다가 쫄아서 다 도망가게 되어 있습니다.
ps. 573배...의 기원은 어디인지요? 자주 보는 표현인거 같은데...
xml 문서와 html은 함께 존재할 것 같네요.그이유는 디자이너
xml 문서와 html은 함께 존재할 것 같네요.
그이유는 디자이너가 xsl문서를 작성해야 할텐데. 그러기에는 아직 툴들이 너무 어렵고 복잡합니다.
xml문서에 대응되는 xsl문서를 쉽게 만들 수 있는 방법이 필요하겠지요.
물론 복잡한 디자인이 필요없다면, 브라우저쪽에서 xml과 xsl의 결합에 대한 것이 표준화가 진행되어야 할 것입니다.
그렇지 않다면 익스플로러 6.0에서는 잘 보이는 것이 익스플로러 5.5에서는 안보일테고
더군다나 다른 브라우저는 말할 것도 없겠지요.
xml은 데이터로서의 의미가 강하니 보여주는
쪽보다는 soap등으로 데이터 통신을 하는 쪽과
데이터 저장쪽(그럴러면 엑셀론과 같은 xml전용 어플리케이션 서버를 이용하는 것이 훨씬 좋을 것입니다.)에서 이용하는 것이 유리할 수 있겠지요.
xml데이터를 rdbms에 집어넣는 것은 정말
삽질중의 삽질입니다.
개인적으로 엑셀론, svg에디터등을 만들어
봤었는데 svg는 가능성이 강하더군요.
특히나 나모에서 svg에디터를 이미 출시한
상태지요.
그리고 voiceXML등도 앞으로 쓸만할 것 같구요
하지만, 그런 모든 것들이 가능할려면
앞으로 훌륭한 툴들이 많이 나와야 할 것입니다.
프로그래머가 그런 것을 모두 이용한다면,
새로운 노동만 추가되는 것이지요.
글을 끝가지 안 읽고 답글을 달았군요.XML을 브라우저에서 바로 해석
글을 끝가지 안 읽고 답글을 달았군요.
XML을 브라우저에서 바로 해석해서 볼 수 있다면 멋지겠군요.
지금 당장은 HTML이 워낙 많이 퍼져 있어서 XML로 대체되는 건 어렵겠지만, 장기적으로는 가능성이 있어 보입니다.
--
세벌식은 쉽다
세벌식은 쉽다
HTML이나 XML 한쪽이 죽는 게 아니라 서로 보완하는 방향으로 가지
HTML이나 XML 한쪽이 죽는 게 아니라 서로 보완하는 방향으로 가지 않을까 생각됩니다.
지금 XML을 사용하고 있는 곳도 내부적으로는 XML을 사용하더라도 브라우저에 나타날 때는HTML로 변환하는 식으로 사용하는 것으로 알고 있습니다.
--
세벌식은 쉽다
세벌식은 쉽다
저두 xml에 대해서 오느정도 살펴보고 한 정도라서 그렇게 많은 지식은
저두 xml에 대해서 오느정도 살펴보고 한 정도라서 그렇게 많은 지식은 없지만 일단 지금의 추세라면 아직은 html입니다.
하지만 MVC(Model + View + Control)의 개념으로 설계를 한다면 xml 로 데이터만 생성하고 자신이 원하는 view를 만들기 위해서는 xsl stylesheet로 충분히 생성시키는 것이 가능하므로 변화하는 데이터만 전송하고 html로 생성하는 것은 웹브라우저에 맡기는 것도 좋은 방법이죠.
하지만 문제가 있는것이 클아이언트의 xml파서의 버전과 지원하는 성능에 대해서는 동일한 성능을 보장하기 어렵다는 것이 아직은 문제인 것같습니다.
XML문서 생성때에도 어떤 파서를 사용하느냐에 따라서 다른 파서에서 깨지는 것을 감수해야하는 경우도 있습니다.
아직은 클라이언트에서 xml파싱에 대해서 크게 만족할 만한 표준이 확립된 것이라고 보기는 힘든 것같군요.
아직은 시간이 더 있어야 할 것 같습니다.
10년 지났는데 아직은 아니네요.
10년 지났는데 아직은 아니네요.
재벌 2세가 재벌이 될 확률과
금메달리스트 2세가 금메달을 딸 확률이 비슷해지도록
자유오픈소스 대안화폐를 씁시다.
아이디의 아이디어 무한도전
http://blog.aaidee.com
귀태닷컴
http://www.gwitae.com
댓글 달기