오늘날 요청하는 브라우저로 웹 서버가 HTML 페이지를 제공하는 것과 상당히 유사한 방식으로, 요청하는 클라이언트에게 컨텐츠를 제공한다. 하지만 여기에는 한 가지 중요한 차이점이 있는데, 그것은 새로운 프레임워크는 페이지를 제공하지 않으며, 그 대신 페이지의 퍼블리싱 되는 양식을 제공한다는 점이다.
실질적 이행 아직 초기 단계
역동적인 HTML 컨텐츠를 표현할 수 있는 능력은 어떠한 웹사이트나 웹 기반 애플리케이션에서든 가장 중요한 것이다. 정적 컨텐츠로 이루어진 웹사이트는 방문객들의 발길을 다시 찾게 할 수 없을 것이며, 사용자들에게 그들이 찾고 있는 맞춤화 된 개인 경험을 줄 수도 없을 것이다. 웹 애플리케이션들은 웹사이트와 대조적으로 역동적 컨텐츠 개념을 중심으로 설계 및 이행되었다.
하지만 이러한 컨텐츠는 대부분 지속적으로 이것을 만들고 치는 다수의 HTML 편집자 직원들을 둠으로써만 동적인 상태가 유지되었다. CSS(Cascading Style Sheets) 표준은 복합적이고 역동적인 웹사이트의 시각적 부문을 합리화할 수 있게 도와줬지만, 정작 이것이 진정으로 필요로 하는 것은 주지 못했다. 다음 단계는 컨텐츠를 만들어내는 서버 측 기술을 사용하는 것이었다. 이러한 기술에는 ‘페이지 내의 코드(code in your pages)’와 ‘코드 내의 페이지(pages in your code)’라는 두 가지 부류가 있다.
페이지 내 코드 집단에는 ASP(Active Server Pages), JSP(JavaServer Pages) 및 PHP(PHP Hypertext Processor) 표준이 포함된다. 모든 경우에 서버 측 스크립트는 HTML 코드와 혼합되어 역동적 컨텐츠를 제공한다. 분명히 로직, 컨텐츠 및 사용자 인터페이스는 긴밀하게 혼합된다. 따라서 부담은 HTML 코드에서부터 PHP, JSP 및(혹은) ASP 코드로 옮겨지지만 문제는 여전히 남아 있다.
코드 내 페이지 집단에는 자바 서브릿(Java servlets)과 마이크로소프트의 웹 클래스(web classes)가 포함된다. 역시 개발자들은 이런 기술들이 컨텐츠를 사용자 인터페이스로부터 분리시킬 것이라는 약속을 받았지만, 대신 이들은 자바나 비주얼 베이직 내부에서부터 HTML 태그를 만들어내는 과다한 코드만 접하게 됐을 뿐이다.
XML의 출현과 함께, 새로운 웹 퍼블리싱 프레임워크는 발전하고 있다. 이 프레임워크는 XML(Extensible Markup Language)과 그 형제들인 XML(Extensible Style Language) 및 XSLT(Extensible Style Language Transformation)을 기반으로 한다. 이 프레임워크는 오늘날 웹 서버가 요청하는 브라우저로 HTML 페이지를 제공하는 것과 상당히 유사한 방식으로, 요청하는 클라이언트에게 컨텐츠를 제공한다.
하지만 여기에는 한 가지 중요한 차이점이 있다. 새로운 프레임워크는 페이지를 제공하지 않으며, 그 대신 페이지의 퍼블리싱 되는 양식을 제공한다. 비록 컨텐츠는 동일하지만, 퍼블리싱 되는 페이지는 클라이언트에 따라 다르다. 예를 들어, 애크로뱃 리더(Acrobat reader)가 요청을 만들었다면, 퍼블리싱 되는 페이지는 PDF 문서로 돌아올 것이다.
WAP(Wireless Application Protocol) 장비는 WML(Wireless Markup Language) 페이지를 받게 될 것이며, 일반 웹 브라우저는 HTML 페이지를 받게 될 것이다. 웹 브라우저의 경우, 들어오는 요청이 텍스트 전용의 Lynx 브라우저에서 오는지, 아니면 넷스케이프 네비게이터나 마이크로소프트 인터넷 익스플로러에서 오는지에 따라 서로 다르게 퍼블리싱 되는 페이지를 지원하게 할 수도 있다.
