W3C 활동 소개

김병학

대전 광역시 유성구 구성동 373-1

한국과학기술원 인공지능연구센터

E-mail : bhkim@cair.kaist.ac.kr

URL : http://cair.kaist.ac.kr/~bhkim/

Abstract:

본 강의는 W3C의 활동 소개와 현재 진행 중인 표준화 활동들에 대한 소개 및 제공하는 프로그램, 라이브러리, 그리고 기타 정보들에 대한 소개를 한다.

Keywords:

W3C, WWW

1. 개요

W3C는 WWW과 관련된 표준안의 제작과 새로운 표준안 제안등 급변하는 WWW의 발전에 따른 신속한 안의 제정과 이를 많은 회사들과 연구 기관에서 서로 공유하게 하여 정보화의 세상을 위한 하부 구조로서의 WWW의 기술적, 사회적 확산을 위해 구성된 전세계적 단체이다. 현재 11개 국가 이상에서 가입하여 있으며, 국내에서는 WWW-KR이 가입되어, 국내에 기술 전파등의 역할을 담당하고 있다.

WWW에 대한 기술 표준은 W3C와 IETF에서 하고 있으며, W3C와 IETF(Internet Engineering Task Force)를 서로 구분하고자 한다면 IETF는 어느정도 성숙된 기술에 대해서 표준화를 진행하고 있고 W3C는 현재 당장 필요한 기술들에 표준화를 담당한다. 곧 WWW이 빠른 속도로 발전하고 있는 기술 분야이기 때문에 IETF가 하는 절차에 의해서는 이 빠른 표준화 욕구를 충족시키지 못하는 문제점이 있다. 이를 해결하고, WWW에 대한 발전을 어느 정도의 표준화된 틀 안에서 하기 위해서 W3C가 등장하였다고 볼 수 있다.

2. W3C 팀

MIT Lab for Computer Science

INRIA

Keio University

3. W3C Activity Area

User Interface [Area  Leader: Vincent Quint]

Technology and Society [Area Leader: Jim Miller]

Architecture [Area Leader: Dan Connolly]

3.1 User Interface

주제	요구사항	현재	미래
HTML	모든 플랫폼에서 동작하는 간단하고 확장이 쉬우며, 풍부한 기능을 제공하는 문서 형태 제공	HTML 3.2	Cougar1)
Style Sheet (CSS: Cascading Style Sheet)	일반적인 문서 디자인을 가능하게 하고 외부 내부에서 스타일을 지정할 수 있게 하며, 다른 웹 응용에서도 사용할 수 있으며, 보이는 것뿐만 아니라 다른 형태로 출력이 가능하게 한다. 향후의 확장도 또한 가능해야 한다.	CSS1	CSS Positioning, 프린팅, Aural Cascading Style Sheet, next level of CSS
Internationaliza- tion	HTML, HTTP, CSS, URL에 이르는 모든 분야에 대한 모든 언어의 적용 가능	survey, HTTP/1.1과 현재 가능한 i18n 방법을 위한 제안서	Unicode로의 기존 w3c code 변형, 다른 코드 체계 지원
Graphics	공짜의 시스템에 종속적이지 않는 그래픽 화일 포맷의 정의	PNG	Scalable responsive web graphics
Fonts	시스템에 독립적이면서 네트워크로부터 다운이 가능하며, scalable 한 폰트의 적용을 가능하게 한다.
Arena		과거에 HTML 3.0 구현때 작성한 코드로 source가 공개되어 있다.
Amaya		편집과 더불어, HTML 3.2 표준을 포함하고 있으며, CSS가 지원된다. 현재 Linux, Solaris버젼의 binary가 있고, Source가 공개.

3.2 Technology and Society

주제	요구사항	현재	미래
Content Rating: PICS	□전세계 아무 국가나 기관에서 사용이 가능하며, 모든 전송 시에 label 이 전송이 가능해야 한다.	□PICS 1.1	□PICS의 Digital signature, Privacy, intellectual property등에 적용
Privacy and Demographics	□아직 문제에 대한 정확한 정의가 없음
Digital Signatures	□online문서에 대한 보증을 기존의 표준 위에서 할 수 있게 한다. □문서 내부, 외부에서 지정 ,또한 외부의 trusted 3자에 의한 제공	□방향 : Signature Label, Trust Management (automated tool interpretation) □product □Digital signature system (Prototyping) □Trust system	□표준 제안과 구현, 데모, 가이드 완성
Electronic Commerce: JEPI	□online에서 쇼핑이 가능하게 하며, 일어날수 있는 다양한 금전적 이동에 대한 지원을 한다. 데모와 prototyping 그리고 기존의 SET등의 시스템 지원	□Spec은 초기 버젼이 완성되었으나, 데모는 시간이 지연되고 있다. □PEP, UPP(Universal Preamble) 프로토콜 표준	□PEP위에서의 UPP, 다양한 payment 방법을 위한 UPP확장, Prototype..
Intellectual Property Rights	□사용자가 법규를 지킬 수 있게 지원하고 레이블링 시스템을 이용하여 불법 복제물의 확산을 방지할 수 있게 한다.	□Overview상태. Product도 없다	□PICS와 연계성
Access for the Disabled	□웹 기술의 accessability를 높이기 위한 기술적 guideline 제공

3.3 Architecture

주제	요구사항	현재	미래
Addressing: URLs	□모든 자원에 대한 Addressing, 안전하고 인증가능,URN지원		URL spec revision, Replication, URN , PURLS, link management protocol
Protocols: HTTP	□Performance, Scalability,Extensibility	HTTP/1.1, PEP draft	HTTP-NG (MUX), PEP
Real Time: Audio and Video	□RTP의 지원, 웹을 기반으로 Multimedia presentation, A/V hyperlink, A/V mime type의 지정	<멀티미디어 저작을 위한 지원 > □시간에 대한 표현과 동기화를 위한 문서 포맷 □Audio/Video 재 동작 □Audio/Video 스트림에 대한 URL지정 □Audio/Video의 이부 구간에 대한 주소화 □Internet - Suitable Audio/Video codec □기타 포맷 <멀티미디어 전송을 위한 지원> □RTSP □Audio/Video 스트림에 대한 URL지정 □응용에서 Web data에 대한 framing
Propagation, Replication and Caching	□web 문서의 중복과 캐슁을 위한 노력		□분산된 중복과 에러 회복, multicase를 기반으로 하는 중복, 여러 개의 cache server의 협조에 의한 caching
Generic SGML	□SGML문법을 web에서 바로 사용할 수 있게 한다.	□XML Language, Link Spec, Draft for apply DSSSL style sheet lang	□DSSSL Online(subset). catalog mechanism (SMGL doc entity 관리), SGML fragments에 대한 전송
W3C Reference Library		□libwww 5.0 , HTTP/1.1 , PICS
Modern Server Technology		□Jigsaw	□HTTP/1.1 CGI/1.1, PICS, MUX, ICP(Internet Cache Protocol), Servelets
Original Server: CERN server

기타 package

W3C의 각 working group에서 나오는 issue에 대한 briefing Package가 올해부터 정리되어 제공되고 있다. 여기에는 각 Working Group이 계속적으로 만들고 있는 표준 스펙을 위한 issue를 정리하여 멤버들이 관심을 가지게 하고 내부적으로 기술적 정책을 결정하는 자료로 사용하고 있다.

4. 정보 교환

W3C에서의 정보 교환은 우선 http://www.w3.org/에 있는 홈 페이지에 의해서 이루어진다고 볼 수 있다. 이 외에 Newsletter와 announcement들 그리고 멤버를 위한 메일링 리스트를 통해서 대부분의 정보 교환이 이루어진다.

W3C Newsletter

W3C Newsletter는 W3C의 활동에 대한 이야기와 announcement들, 새로운 가입자 정보, workshop, meeting등에 대한 정보 등을 담고 있다.

Member Mailing Lists

표 1. GENERAL LISTS

List Name	Contact Person	Description	Posting Privileges	Subscribe Privileges
w3c-members@w3.org	Tom Greene	Official messages from the W3C Director to Consortium Members, and W3C Newsletter.	W3C Director	Members
w3c-ac-members@w3.org	Beth Curran	This is the list of W3C Advisory Committee Members.	W3C Director	AC Members ONLY
w3c-tech@w3.org	Dan Connolly	Technical discussion on areas of W3C activity	Members	Members
w3c-ac-forum@w3.org	Sally Khudairi	Advisory Committee Representative Discussion Forum	AC representatives ONLY	AC representatives ONLY
process-erb@w3.org	Sally Khudairi	Discussion for the W3C Process Editorial Review Board	Committee Members ONLY	Committee Members ONLY

표 2. USER INTERFACE LISTS

List Name	Contact Person	Description	Posting Privileges	Subscribe Privileges
html-erb@w3.org	Dave Raggett	Discussion for the HTML Editorial Review Board	Group Members ONLY	Subject to Group Membership Rules
w3c-math-erb@w3.org	Dave Raggett	Discussion for the Math Subgroup of the HTML Editorial Review Board	Subgroup Members ONLY	Subject to Subgroup Membership Rules
w3c-fonts-wg@w3.org	Chris Lilley	Discussion for the Fonts Working Group	Working Group Members ONLY	Working Group Members ONLY

표 3. ARCHITECTURE LISTS

List Name	Contact Person	Description	Posting Privileges	Subscribe Privileges
w3c-http@w3.org	Henrik Frystyk Nielsen	HTTP/1.1 Implementor's Forum	Members	Members
symm@w3.org	Philipp Hoschka	Synchronized Multimedia Working Group	WG Members Only	WG Members Only
w3c-lib@w3.org	Henrik Frystyk Nielsen	Discussion of the libwww - W3C Reference Library	Members	Members
w3c-sgml-erb	Dan Connolly	SGML Editorial Review Board	ERB Members	ERB Members
w3c-sgml-wg	Jon Bosak	SGML Working Group	WG Members	WG Members

표 4. TECHNOLOGY AND SOCIETY LISTS

List Name	Contact Person	Description	Posting Privileges	Subscribe Privileges
w3c-labels-steering@w3.org	Jim Miller	Steering committee of PICS Working Group	Steering Committee Members ONLY	Steering Committee Members ONLY
w3c-labels-paw@w3.org	Jim Miller	Public Affairs Sub committee of PICS Working Group	Sub committee Members ONLY	Sub committee Members ONLY
w3c-labels-tech@w3.org	Jim Miller	Technical subcommittee of PICS Working Group	Subcommittee Members ONLY	Subcommittee Members ONLY
pics-info@w3.org	Jim Miller	Announcements Related to PICS	PICS Steering Committee	Public
pics-ask@w3.org	Jim Miller	Questions about PICS	Public	Steering Committee Members ONLY
w3c-dsig@w3.org w3c-dsig-id@w3.org w3c-dsig-endorse@w3.org	Rohit Khare	Digital Signature Initiative of the W3C Security Working Group	Working Group Members ONLY	Members by permission ONLY
w3c-sec-erb@w3.org	Rohit Khare	W3C Security ERB	ERB Members ONLY	ERB Members ONLY
w3c-sea@w3.org	Rohit Khare	Discussion of Security Extension Architecture Draft	Members	Members

Public Mailing List

□ www-talk

□ www-html

□ www-jigsaw

□ www-international

□ www-annotation

□ www-collaboration

□ www-lib

□ www-style

□ www-font

□ www-next

□ www-speech

□ www-amaya

□ www-amaya-developers

□ www-dist-auth

가입 방법

mailto:mailing-list이름-request@w3.org

subject : subscribe

Advisory Committee Meetings

Advisory Committee meetings는 1년에 두차례 열린다. W3C의 향후 방향과 정보 교환이

이루어진다. 다음 회의는 15-16 January 1997 (London,UK)에서 열린다.

비정기적인 워크샵

특별한 주제에 대한 워크샵이 비정기적으로 열린다. 여기에서는 주로 한 개의 문제에 대

해서만 토론을 하고 앞으로의 일들에 대해서 이야기한다.

올해의 이벤트

□September 2-4 :

Electronic Commerce Interest Group Meeting in Brussels, Belgium

Security Interest Group Meeting in Brussels, Belgium

Public Policy Interest Group Meeting in Brussels, Belgium

□June 18-19: 6th Advisory Committee Meeting to be held in Tokyo

<Addition 1> Project : Cougar

Project : Cougar

W3C's next version of HTML

Cougar는 W3C에서 추진하고 있는 다음 세대의 HTML버젼의 프로젝트 코드명이다.

Cougar가 새로운점?

현재 고려되고 있는 확장은 HTML3.2를 바탕으로 form, interactive 문서, 스크립트를 통한 동적인 문서 변화, frame, 장애자를 위한 HTML확장 그리고 멀티미디어 오브젝트에 대한 것들이다.

W3C는 현재의 META,LINK의 특성을 보다 정교하게 사용할 수 있게 하려고 한다. 이 방법은 메타 데이타를 이용하여 문서의 성질이나 다른 개체와의 관련성을 표현할 수 있게 하고 또한 전자 서명을 이용한 문서 서명등을 가능하게 하려고 한다.

관련 Draft

WD-htmllink

이 Draft는 HTML에 연결 방법을 제시하고 현재 사용 되고 있는 몇가지의 기술, 예를 들면 robots.txt를 이용한 robot access 제한, 문서의 사용 언어 표현, 키워드나 기타 정보의 표현등에 대해서 다른다.

□출발지와 목적지 앵커 : 현재 우리가 주로 쓰고 있는 형태의 앵커

□절대적 상대적 주소 : 현재 우리가 주로 쓰고 있는 형태의 앵커

□링크의 의미 : REL 과 REV 는 예를 들어서 A문서와 B문서에 대해 A가 REV=relation이란  관계를 가진다면 B는 A에대해 REL=relation이란 관계를 갖게 하는 문서의 관계를 정의하는데에 사용된다.

□TITLE : 이 속성은 문서에서 풍선 도움말과 같은 형태로 표현되어서 실제로 페이지를 방   문하지 않고도 그 문서의 제목을 알 수 있게 하는데에 쓰인다.

예 : <A TITLE="Ski Conditions for New Hampshire">ski conditions</A>

□BASE

□LINK : 이 태그는 문서의 관련성, REL,REV 를 비롯해서 LANG, MEDIA, Style Sheet를 지   하는데에 사용된다.

□META : 이 태그는 문서의 특성, Expire Date, PICS정보등을 나타낸다.

□메타 데이타로서의 Profile : 이 메타 정보는 현재 정의되고 있는 표준들이 일반적인 것을 정의하는데에 비춰서, 보다 특별한 용도의 Link 관련성, META정보들, 그리고 CLASS와 같은 사전 정보를 URL로 표현하는 방법이다.

예 : <HEAD PROFILE="http://www.acme.com/profiles/core">

□기타

- 문서 언어 지정

<META HTTP-EQUIV=Content-Language CONTENT=en>

<BODY LANG=fr>

<LINK REL=alternate HREF=mydoc-fr.html LANG=fr TITLE="La vie sousterrainne">

- 로봇으로 부터의 방문 거부 (robots..txt)

User-agent: *    # applies to all robots

Disallow: /      # disallow indexing of all pages

<META NAME="ROBOTS" CONTENT="NOINDEX, NOFOLLOW">

WD-style

HTML이 Style Sheet와 잘 결합해서 동작하기 위해서는 현재의 HTML이 약간은 확장되어야 한다. 스타일은 HTML 의 태그안에 포함될 수도 있고, 문서의 헤더에 넣을 수도 있고 독립적인 파일로 연결시킬 수도 있다. 여기에서는 style sheet에 대한 문법이 아닌 HTML과 Style Sheet와 잘 결합하기 위한 방법을 제시한다.

□ style지정 방법

- 헤터 정보 : <META HTTP-EQUIV="Content-Style-Type" CONTENT="text/css">

- 스타일 지정 :

<STYLE TYPE="text/css">

p { font-size: 12pt }

</STYLE>

- 태그에서 지정 :

<P STYLE="font-size: 12pt; color: rgb(0, 0, 100)">How

- 링크 이용 : <LINK REL=stylesheet HREF="housestyle.css">

□Persistent, Default and Alternate Styles

<!-- a persistent style -->

<link href=xxx.css rel=stylesheet>

<!-- a default style titled "Compact" -->

<link href=xxx.css title="Compact" rel=stylesheet>

<!-- an alternate style titled "Medium" -->

<link href=xxx.css title="Medium" rel="alternate stylesheet">

□Link 태그

<LINK REL=stylesheet MEDIA=print

HREF="printstylesheet.css" TYPE="text/css">

□Style 태그

□Span 태그 : 적은 부분에 대한 style 적용

□Div 태그 : Class속성과 같이 있으며, 챕터, 요약등을 의미적으로 나누는데에 사용한다.

WD-script

HTML을 확장하여 javascript, vbscript와 같은 스크립트 언어를 지원하게 한다.

□Script tag

<SCRIPT type="text/tcl">

document write "<EM>This will work<\/EM>"

</SCRIPT>

□Default Script 언어

<META HTTP-EQUIV="Content-Script-Type" CONTENT="text/tcl">

□NOSCRIPT 태그

<NOSCRIPT>

<P>This document works best with script enabled browsers

</NOSCRIPT>

□이벤트 : onLoad, onUnload, onClick, onMouseOver, onMouseOut, onFocus, onBlur,

onSubmit, onSelect, onChange

WD-frames

프레임은 현재 널리 쓰이고 있는 태그이다. 이 태그에 대한 표준은 아직 없으며, 여기에서는 이 태그에 대한 현재 기준을 표준으로 하려고 하고 있다.

WD-forms

폼은 아직까지 많은 부분에 확장이 필요하다고 생각될 수 있다. 이를 위해서 다양한 폼 형태와 장애자를 위한 폼등이 제안되어 있다.

□ACCESSKEY : 키보드로 폼 선택 가능 (HotKey)

□DISABLED : 폼 입력을 불가능하게 한다.

□READONLY : 폼에서의 수정을 불가능하게 한다.

□LABEL 태그

□FIELDSET 태그 : 폼들의 그룹화를 한다.

□onChange 이벤트

□ACCEPT : 입력에 대한 제한을 가하게 한다.

□BUTTON 태그

□ACCEPT-CHARSET : 언어에 대한 지정을 한다.

□TITLE : 폼에 대한 풍선 도움말을 보여줄 수 있게 한다.

□TABINDEX : 키보드에 의한 tab control이 가능하게 한다.

WD-object

현재 웹에서의 오브젝트는 멀티미디어 데이타를 비롯하여 Java applet, ActiveX Component Object Model (COM) 오브젝트, 그리고 다양한 오브젝트들이 있다. 이를 하나의 태그 형태로 통합하려는 노력이 이루어지고 있다.

□예 :

<OBJECT data=TheEarth.avi type="application/avi" alt="The Earth">

<img src=TheEarth.gif alt="The Earth">

</OBJECT>

□type : application/avi, application/director, application/java-vm

□classid, codebase 속성

□param 태그

□Client Side Image Map : 예

<object data="navbar.gif" shapes>

<a href=guide.html shape=rect coords="0,0,118,28">Access Guide</a> |

<a href=shortcut.html shape=rect coords="118,0,184,28">Go</a> |

<a href=search.html shape=rect coords="184,0,276,28">Search</a> |

<a href=top10.html shape=rect coords="276,0,373,28">Top Ten</a>

</object>

WD-entities

웹에서 ISO-8859-1문자나 Adobe 특수 문자를 사용할 수 있게 하기 위한 문자 정의 그리고 i18N을 하기 위해 필요한 문자들에 대한 정의를 하고 있다.

RFC 1867

이 표준은 File Upload에 대한 내용이다.

RFC 1942

이 표준은 HTML Table에 관한 것이다.

RFC 2070

이 문서는 HTML의 I18N에 대한 내용이다.

<Addition 2> HTML에서의 CSS를 이용한 위치 지정 요약

HTML 에서의 CSS를 이용한 위치 지정 요약

W3C Working Draft 31-Jan-1997

1.  소개

이 문서는 HTML 에서의 위치 지정을 다른다. 위치 지정은 크게 1) '상대적' 위치 지정 2) '절대적' 위치지정으로 나뉜다. 다음의 예에서 자세한 것을 알 수 있다.

2.  위치 지정 예

아래의 예는 다음의 HTML 문장을 이용한다.

<body>

<p>Beginning of body contents.

<span id=outer> Start of outer contents.

<span id=inner> Inner contents.</span>

End of outer contents.</span>

End of body contents.

</p>

</body>

각 예에서 outer 와 inner 에 대한 정의를 다르게 한다.

2.1 '절대적' 위치 지정

예 1:

#outer {position:absolute; top: 200px; left: 200px; color: red;}

#inner {color: green;}

결과는 다음과 같다.:

(0,0)

+----------document window----------+(400,0)

|Beginning of body contents. End of |

|body contents.                     |

|                                   |

|                                   |

|                                   |

|                                   |

|                +-----------------+|

|                |Start of outer   ||

|                |contents. Inner  ||

|                |contents. End of ||

|                |outer contents.  ||

|                +-----------------+|

|                                   |

|                                   |

+-----------------------------------+(400,400)

(0, 400)

절대적 위치 지정은 다음과 같은 특성을 갖는다. :

□이것은 BODY 태그와 같이 사각형의 문서 팬을 만든다.

□top, left와 같은 성질을 이용해서 위치가 지정된다.

□height와 width는 사각형의 높이와 너비를 지정하며, 만약 너비가 지정되지 않으면, 원래	창의 너비만큼이 지정되며, 높이가 지정되지 않으면, 내용의 크기에 의해서 자동조정된	다.

□사각형의 내부에는 다시 새로운 좌표계가 형성된다.

2.2 '상대적' 위치지정

상대적 위치지정은 z-order의 정정이 가능하며, 다른 HTML 문서와 상대적인 위치에 위치할 수 있어서, Overlay나 Underlay와 같은 형태의 응용이 가능하다. 또한 스크립트 언어를 이용해서 동적으로 위치를 바꿀 수도 있다.

'절대적' 위치지정과 같이 사각형안에 새로운 좌표계가 형성된다.

예 2:

#outer {position: relative; color: red;}

#inner {position: absolute; top: 200px; left: -100px; height: 130px; width:	130px; color: green;}

결과는

(0,0)

+----------document window----------+(0,400)

|Beginning of body contents. Start  |

|of outer contents. End of outer    |

|contents. End of body contents.    |

|                                   |

|                                   |

|                                   |

|                  +----------+     |

|                  |Inner     |     |

|                  |contents. |     |

|                  |          |     |

|                  |          |     |

|                  +----------+     |

|                                   |

|                                   |

+-----------------------------------+(400,400)

(400,0)

2.2.1 이동하는 상대적 위치조정

'top' 이나 'left' 특성이 'relative' 특성과 결합되면, 내용은 원래 위치에 대한 offset의 역할을 한다.

예 3 :

<HEAD> 에 다음과 같은 정의가 있고, : <STYLE TYPE="text/css"> BODY {line-height: 200%} </STYLE>

#outer {position: relative; top: -12px; color: red;}

#inner {position: relative; top: 12px; color: green;}

이 결과는 outer 문자는 윗첨자와 같이 나타나고 , inner 문자는 아래첨자와 같이 나타난다.

+----------document window----------+

|                            Start  |

1|Beginning of body contents.        |

|of outer contents.                 |

2|                   Inner contents. |

|End of outer contents.             |

3|                       End of body |

|                                   |

4|contents.                          |

|                                   |

5|                                   |

|                                   |

6|                                   |

|                                   |

7|                                   |

|                                   |

|                                   |

+-----------------------------------+

2.2.2 문서 플로우에 상대적인 '절대적' 위치 지정

'top'특성에 대한 auto값은 다음과 같이 화면에 표현하게 한다.

예 4 :

<SPAN STYLE="position: relative; left: 10px;">

I used two red hyphens to serve as a change bar. They

will "float" to the left of the line containing the following

<SPAN STYLE="position: absolute; left: -10px; color: red;">--</SPAN>

word.</SPAN>

결과는 다음과 같다.:

+----------document window----------+

|   I used two red hyphens to serve |

|   as a change bar. They will      |

|   "float" to the left of the line |

|-- containing the following word.  |

|                                   |

|                                   |

|                                   |

|                                   |

+-----------------------------------+

2.3 정적 위치 지정

'Static' 은 일반적인 HTML과 같다. 이것은 BODY 태그일때만 빼고 'position'에 대한 기본값이다.

예 5 : 예2 와 비교해 보기 바란다.. 유일한 차이는  outer 가 static이란 차이밖에 없다.

#outer {/* position: static; */ color: red;}

#inner {position: absolute; top: 200px; left: -100px; height: 130px; width:	130px; color: green;}

(0,0)

+----------document window----------+(0,400)

|Beginning of body contents. Start  |

|of outer contents. End of outer    |

|contents. End of body contents.    |

|                                   |

|                                   |

|                                   |

|------+                            |

|r     |                            |

|ents. |                            |

|      |                            |

|      |                            |

|------+                            |

|                                   |

|                                   |

+-----------------------------------+(400,400)

(400,0)

2.4 이동하는 위치지정

Floating는 이미 CSS1에서 지정이 가능하다. 이 부분에 대해서는 향후 확장이 기대된다.

예 6 :

#outer {color: red;}

#inner {float: right; width: 130px; color: green;}

(0,0)

+----------document window----------+(0,400)

|Beginning of body contents. Start  |

|of outer contents. End+-----------+|

|of outer contents.    |Inner      ||

|End of body contents. |contents.  ||

|                      +-----------+|

+-----------------------------------+

2.5 가시성

'visibility' 특성은 초기에 보일것인가 아닐것인가를 선택하게 한다. display:none과든 다르게 입력이 올때가지 투명하게 보인다.

예 7 :

<P>Choose a suspect:</P>

<DIV ID="container1" STYLE="position:relative">

<IMG WIDTH=100 HEIGHT=100 SRC="suspect1.jpg">

<P>Name: Al Capone</P>

<P>Residence: Chicago</P>

</DIV>

<DIV ID="container2" STYLE="position:relative">

<IMG WIDTH=100 HEIGHT=100 SRC="suspect2.jpg">

<P>Name: Lucky Luciano</P>

<P>Residence: New York</P>

</DIV>

<FORM NAME="myForm">

<INPUT TYPE="button" VALUE="Capone"

onClick='show("container1");hide("container2")'>

<INPUT TYPE="button" VALUE="Luciano"

onClick='show("container2");hide("container1")'>

</FORM>

form의 버튼을 누를때까지 감춰줘 있다가 입력이 틀어오면 나타난다. 위치지정이 'relative'이기때문에 문서의 모양에는 변화가 없다.

예 8 :

<BODY>

<STYLE type="text/css">

<!--

#container1 { position: absolute; top: 2in; left: 2in;}

#container2 { position: absolute; top: 2in; left: 2in;

visibility:hidden;}

-->

</STYLE>

<P>Choose a suspect:</P>

<DIV ID="container1">

<IMG WIDTH=100 HEIGHT=100 SRC="suspect1.jpg">

<P>Name: Al Capone</P>

<P>Residence: Chicago</P>

</DIV>

<DIV ID="container2">

<IMG WIDTH=100 HEIGHT=100 SRC="suspect2.jpg">

<P>Name: Lucky Luciano</P>

<P>Residence: New York</P>

</DIV>

<FORM NAME="myform">

<INPUT TYPE="button" VALUE="Capone"

onClick='show("container1");hide("container2")'>

<INPUT TYPE="button" VALUE="Lucia	no"

onClick='show("container2");hide("container1")'>

</FORM>

이 예에서 두개의 container는 같은 위치에 같은 크기를 같는다. 그래서 같은 위치에 있는	박스에 글짜가 바뀌는것 같은 효과만이 나타난다.

2.6 Z-order

HTML에 나타난 순서대로 z-order는 정해진다. 순서에 대한 것을 바꾸기 위해서는 z-index라고 하는 특성을 바꾸면 된다.

예 9 :

<STYLE type="text/css">

<!--

.pile { position: absolute; left: 2in; top: 2in; width: 3in; height:

3in; }

-->

<IMG SRC="butterfly.gif" CLASS="pile" ID="image" STYLE="z-index: 1">

<DIV CLASS="pile" ID="text1" STYLE="z-index: 3">

This text will overlay the butterfly image.

</DIV>

<DIV CLASS="pile" ID="text2" STYLE="z-index: 2">

This text will underlay text1, but overlay the butterfly image

</DIV>

이 예에서 z-order는 다음과 같다.:

□image

□text2

□text1

<Addition 3> HTTP 위에서의 Payment

HTTP위에서의 Payment

1. Introduction

JEPI는 PEP를 이용하여 payment 방법을 웹 브라우져와 서버 사이에서 개발하는 것이다. 이를 위해서 Universal Payment Preamble(UPP)란 인터넷 Draft를 채택하여 PEP를 적용하려 한다. 이 문서에는 7가지의 기본적인 동작에 대해서 어떻게 UPP가 PEP위에서 동작하는가를 보여준다.

□7가지 기본 동작

⑴ Request payment choices. client 나 server는 상대방에게 지원하는 payment방법에 대해서 물어볼 수 있어야 한다.

⑵ Present payment choices that it supports. 양측은 자신이 지원하는 지불방법에 대한 리스트를 만들수 있어야 한다. 이때 리스트는 전체리스트가 아닌 자신이 원하는 형태의 지불 방법에 대한 리스트이다.

⑶ Demand payment choice. 상인 서버는 사용자에게 특별한 지불 방법을 선택할것을 요구할 수 있어야 한다.

⑷ Make a payment choice. 사용자는 지불을 위한 방법을 나타낸다. 이것은 서버에게 바로 지불을 시작할 수 있다는것을 나타내고 , 또는 수락이나 거절을 표시 할 수 있다.

⑸ Accept a payment choice. 사용자의 지불방법에 대해서 서버는 선택을 수락하고 실제적인 지불 동작을 할 수 있다.

⑹ Reject a payment choice. 서버는 사용자의 지불 방법에 대해서 거절을 할 수 있다. UPP에서는 사용자가 지불을 위한 동작을 정지해도 같은 형태의 거부가 수행된다.

⑺ Do you accept payment by X? 양측은 상대방에게 특별한 지불 방법이 지원되는가를 물어볼 수 있다.

2. Operation 1: Requesting Preferred Payment Choices

client 나 server는 상대방에게 지원하는 패이먼트 방벙에 대해서 물어 볼 수 있어야 한다.

2.1 Client asks Server

Protocol-Query: 헤더가 첨가된다. 헤더가 첨가된다.

GET URL

Protocol-Query: {http://www.w3.org/UPP upp-params}

이것은 "위의 지정된 URL에 있는 UPP를 가지고 있는가? " 만약upp-params이 지정되면 요구의 의미는 더 한정된다. (예. 만약 {upp {amount {frf}}}이 지정되면 이 말은 French Franc를 지원하는가를 나타낸다.

더 일반적인 질문으로 당신이 지원하는 모든 지불 방법을 묻는 것은 다음과 같다.

GET URL

Protocol-Query: {http://www.w3.org/UPP {for /*} upp-params}

응답은 다음 두가지로 나타날 수 있다.

Protocol-Info: {http://www.w3.org/UPP □} 이 응답은 서버가 모든 PEP를 지원하지 않는것을 의미한다. 서버가 PEP는 지원하는데 UPP를 지원하지 않는 경우에는 Protocol-Info: {http://www.w3.org/UPP {str ref}}]같이 보낸다.

Protocol-Info: {http://www.w3.org/UPP □}는 서버가 PEP를 지원하고 아래의 Operation 2의 형태의 응답이 오면 지불 방법에 대한 표현도 표현할 수 있다. 지불 방법에 대한 표현도 표현할 수 있다.

2.2 Server asks Client

서버가 클라이언트에 요구하기 위해서도 비슷한 방법이 사용된다. 서버는 {for }를 이용하여 서버가 가지는 지불 방법이 있는곳의 URL을 함께 보낸다

200 OK

Protocol-Query: {http://www.w3.org/UPP {for /PaymentPages/*}

upp-params}

3. Operation 2: Present Payment Choices

양측은 지원하는 지불 방식에 대한 리스트를 만들 수 있어야 한다.

이 방법은 하나 이상의 Protocol-Info:헤더 정보를 보냄으로서 가능하다.

200 OK -or- GET ...

Protocol-Info: {http://www.w3.org/UPP [for] [{str strength}]

upp-params}

for는 요구에 의해서 온 for와 같아야 하며, strength는 ref, req, 혹은 opt중에 하나여야 한다. strength는 opt 생략될 수 있으며, for에 지정된 모든 URL에 대해 지불이 허용될 수 없는 경우에는 ref를 쓴다. req는 for에 지정된 것을 요구하는 경우에 한에서 지불이 허용될 때 쓴다..

여기에 또하나의 Protocol-Info:헤더가 상대방에게 지불시스템을 제시하기 위해 쓰인다.

200 OK -or- GET ...

Protocol-Info: {http://...payment-system... [for] [{str strength}]

payment-params}

예를 들어서 클라이언트가 다음과 같은 메시지를 받으면 :

200 OK

Protocol-Query: {http://www.w3.org/UPP {for /PaymentPages/*}

upp-params}

SET을 이용한 VISA와 CyberCash 로 지불하기를 원한다면 다음과 같은 응답이 간다.

HEAD ...

Protocol-Info: {http://www.w3.org/UPP {for /PaymentPages/*}}

{http://www.SET.org/PEPSpec

{params {upp {instrument-brand VISA}}}

{for /PaymentPages/*}}

{http://www.CyberCash.com/PEPSpec

{params {upp {instrument-type ECASH}}}

{for /PaymentPages/*}}

4. Operation 3: Demand Payment Choice

상인 서버는 틀라이언트에서 지불 방법을 선택할 것을 요구한다.

표준 서버의 응답의 일환으로 지불이 필요한 페이지에 대한 정보를 가져올 수 있다.(i.e. a "Pay Button" or "Pay URL")

200 OK

Protocol-request: {http://www.w3.org/UPP {str req} {for /PayButton}}

이 의미는 서버가 클라이언트에게 PayButton을 가져올 때 UPP 프로토콜을 사용한 것을 요구하고 있다는 것을 의미한다. {str req}는 만약 이 프로토콜을 사용하지 않을 경우 요구는 거절된다는것을 의미한다.

5. Operation 4: Make a Payment Choice

사용자는 지불을 위한 방법을 나타낸다. 이것은 서버에게 바로 지불을 시작할 수 있다는것을 나타내고 , 또는 수락이나 거절을 표시 할 수 있다.

실제적으로 이 경우는 클라이언트가 operation 3에 대한 응답을 했을 경우에 해당된다. 두개의 헤더가 이때 필요한데 하나는 UPP와 호환이 가능한 프로토콜을 지정하여 UPP프로토콜을 이용하여 응답하는 것이고 다는 하나는 호환 가능한 프로토콜 헤더로 응답하는 것이다. 예를 들어서 지불 방법이 SET위에서 VISA를 쓰는 경우 다음과 같은것을 예상할 수 있다.

GET ...

Protocol: {http://www.w3.org/UPP {via http://www.SET.org/PEPSpec}}

{http://www.SET.org/PEPSpec

{str req}

{params {upp {instrument-type CREDIT} {instrument-brand VISA}}

other-SET-params}}

예상되는 응답은 operation 5 (서버가 이를 수락하는 ) 이거나 operation 6 (거절)하는 경우이다.

6. Operation 5: Accept a Payment Choice

사용자의 지불방법에 대해서 서버는 선택을 수락하고 실제적인 지불 동작을 할 수 있다.

operation 4는 서버에게 실제로 지불 시스템을 시작할 때 필요한 충분한 정보를 제공한다. JEPI, PEP, 그리고 UPP는 지불 시스템을 시작할 것인가에 대한 정보가 없다.그래서 PEP/UPP의 헤더에 하나의 헤더 정보가 더 보내진다. 만약 MIME에 의한 helper응용이 있을 경우, 이 헤더가 필요치 한다. 하지만 더 좋은 인터페이스로 헬퍼 응용이 끝날때까지 브라우져가 기다려 주는것이 필요하다. 이를 지원하기 위해 UPP는 서버에서 클라이언트로 최종 메시지를 보낸다. 이것은 다음 세가지 경우에 대한 URL을 지정하고 있다.

□지불이 성공적으로 수행

□지불이 사용자의 중단으로 취소

□지불이 다른 문제로 중단

헤더는 다음과 같다.:

200 OK

Protocol: {http://www.w3.org/UPP

{params {upp {abort abort-URL}

{cancel cancel-URL}

{success success-URL}}}

7. Operation 6: Reject a Payment Choice

서버는 사용자의 지불 방법에 대해서 거절을 할 수 있다. UPP에서는 사용자가 지불을 위한 동작을 정지해도 같은 형태의 거부가 수행된다.

만약 서버에 의해 지불 시스템이 받아들여지 않는 경우 서버는 400이나 500 클래스의 PEP 에러 베시지를 보낸다. 그리고 body에는 문제가 발생한 이유에 대한 설명을 포함한다.

420 Client PEP Error -or- 520 Server PEP Error

Protocol-Info: {http://...payment-system...

{str ref} payment-params}

Followed by an operation 3 header

payment-system는 거부된 지불 프로토콜을 나타내고 payment-params는 문제를 일으킨 인수를 나타낸다. pay-URL는 요구한 URL이다. 에러 코드 422는 Protocol Extension Refused 이고 521은 Protocol Extension Not Implemented,520는 Protocol Extension Error ,522는 Protocol Extension Parameters Not Acceptable이다. 다른 에러는 특정 지불 시스템에 관련되어 있다

8. Operation 7: Do you accept payment by X?

양측은 상대방에게 특별한 지불 방법이 지원되는가를 물어볼 수 있다.

Protocol-Query는 위의 질문을 보내는데 어느때라도 사용될 수 있다.

200 OK -or- GET ...

Protocol-Query: {payment-system [payment-system-params]}

payment-system는 지불 시스템 프로토콜의 URL이고 is the URL of the payment system protocol, payment-system-params는 프로토콜에 관련된 인수이다.