모바일 위젯 어플리케이션 요구사항

모바일 위젯 어플리케이션 요구사항

(Requirements for Mobile Widget Application)

포럼 과제번호: MW2.08-010

TTA 과제번호 : 제안중

Editor: 전종홍 (ETRI, hollobit@etri.re.kr)

표철민 (위자드웍스, charlespyo@gmail.com, pyo@wzdworks.net )

김도완 (SKTelecom, dkimsk@sktelecom.com )

조영운 (위자드웍스, duddns@wzd.com )

Version : 0.2

문서 갱신 내역 / 주요 코멘트

용어 관련 부분을 추가했습니다. -Jonathan Jeon 08. 8. 23. 오후 8:24

W3C의 위젯 요구사항 문서를 참조하여 골격 작업 -Jonathan Jeon 08. 7. 1 오후 2:19

http://www.w3.org/TR/2008/WD-widgets-reqs-20080625/ -Jonathan Jeon 08. 7. 1 오후 2:18

목차와 범위를 1차로 확정하도록 하죠 -Jonathan Jeon 08. 6. 17 오후 8:53

1. 개요

참조: http://www.w3.org/TR/widgets-reqs/ -Jonathan Jeon 08. 8. 22. 오전 9:56

위젯(widget)은 로컬 데이타 또는 웹 상의 데이타를 업데이트하거나 또는 보여주기 위해 동작하는 상호작용이 가능한 단일 목적의 어플리케이션으로, 사용자의 단말 또는 모바일 단말에 쉽게 다운로드되고 설치되는 방식으로 패키징되어 제공된다.

위젯은 독립 어플리케이션(의미상으로 웹 브라우저 밖에서 실행되는)처럼 실행될 수 있고, 또는 웹 문서내에 임베드될 수도 있다. 이 문서에서, 위젯이 실행되는 런타임 환경을 위젯 사용자 에이전트(widget user agent)라 부르고, 실행 중인 위젯은 구동된(instantiated) 위젯이라 불리운다. 위젯 구동(instantiation)에 앞서, 위젯은 위젯 리소스(widget resource)로 존재한다. 위젯 현황에 대한 좀더 많은 정보는 Widget Landscape 문서를 참조하면 된다.

Widget Landscape에서 살펴봤듯이, 웹 상에서 배포하고 설치하기 위한 위젯 리소스의 저자, 패키지, 보안 인증 또는 국제화 등에 대해 현재 공식적인 표준화된 방법은 없다. 위젯 공간 내에서, 많은 성공적인 위젯 사용자 에이전트들이 현재 시장에 있지만, 하나의 위젯 사용자 에이전트를 위해 만들어진 위젯들은 통상 다른 위젯 사용자 에이전트 위에서 실행될 수 없다.

이 문서는 W3C 철학에 따르며, 현재 시장을 선도하는 사용자 에이전트와 기존 웹 브라우저들과 가능한 상호호환될 수 있으며, 장치 독립적인 방법내에서 어떻게 위젯이 설치되고, 패키지화되고, 안전해지고, 서명하고, 만들고/기술할 것인지 표준화하는데 필요한 규격들의 설계 목표와 요구사항들을 나열한다.

1.1 용어

이 절에서는 모바일 위젯과 관련된 핵심 용어들을 정의한다.

위젯(Widget): 이 표준화의 목적이기도 한, 위젯(widget)은 로컬 데이타 또는 웹 상의 데이타를 업데이트하거나 또는 보여주기 위해 동작하는 인터랙티브한 단일 목적의 어플리케이션에 대한 개념으로, 사용자의 단말 또는 모바일 단말에 한번에 다운로드와 설치가 이루어지는 방식으로 패키징되어 제공된다.위젯은 독립 어플리케이션(의미상으로 웹 브라우저 밖에서 실행되는)처럼 실행될 수 있고, 또는 웹 문서내에 임베드될 수도 있다. 이 문서에서는, 위젯이 실행되는 런타임 환경을 위젯 사용자 에이전트(widget user agent)라 부르고, 실행 중인 위젯은 구동된(instantiated) 위젯이라 부른다. 위젯 구동(instantiation) 이전에, 위젯은 위젯 리소스(widget resource)와 같이 존재한다.

위젯 사용자 에이전트(Widget user agent): 사용자 에이전트(소프트웨어 어플리케이션)는 인스턴스화된 위젯을 동작하게 만든다. 일반적으로 말할때, 위젯 사용자 에이전트는 직접 만들어지거나, 또는 웹 브라우저에 비슷한 기능을 제공하는 방식 중 하나를 의미한다. 실제로는 웹 브라우저 컴포넌트가 HTML 문서를 처리하고 렌더링할 수 있는 웹 브라우저 상에 구현하는 사례가 많아지고 있고, ECMAScript 인터프리터와 같은웹 브라우저 컴포넌트들이 다른 것이 통합되고 있다. 위젯 사용자 에이전트는 마이크로소프트의 윈도우즈, 애플의 맥OS, 심비안, 리눅스 등과 같은 많은 서로 다른 소프트웨어 플랫폼과 디바이스위에 만들어지고 있다. 또한 Knofabulator와 Opera 위젯과 같은 일부 위젯 사용자 에이전트는 다중 플랫폼 상에서 실행 가능하다.

인스턴스화된 위젯(Instantiated widget): 시작 화일이 위젯 사용자 에이전트 상에서 인스턴트화되어 있는 동안, 압축이 해제된 위젯 리소스의 런타임 표현이다. 인스턴트화된 위젯은 환경 설정 문서를 통해 설정이 되도록 할 수 있다. 순서적 처리나나 인터랙티브하게 행동할 수 있는 인스턴트화된 위젯의 능력은 위젯 API를 통해 제공되는 것이다.

아이콘(Icon): 인스턴스화된 위젯의 기호적 표현 또는 이미지. An image or symbolic representation of an instantiated widget. Icons are usually used to represent the widget in non-running context, such as menus and docks. Some widget user agents, such as Konfabulator, allow authors to dynamically change the icon at runtime. For example, a weather widget might update its icon as the weather or time of day changes.

위젯 리소스(Widget resource): A resource created from some packaging format that encapsulates the resources of a widget for the purposes of distribution and deployment. On the wire, a widget resource is identified by an arbitrary widget media type.

미디어 타입(Media type): An media type that formally associates a widget resource with some proprietary widget user agent. For example, Joost's widget engines requires that widgets be served over HTTP with a application/vnd.joost.joda-archive media type.

패키징 포맷(Packaging format): The physical data format used to create a widget resource. For example, the flat-file format described in the Konfabulator Reference or the Zip file format supported by Opera Widgets and Microsoft's Vista Sidebar.

리소스(Resource): Any file or directory used by an instantiated widget that resides either inside a widget resource or is accessible over HTTP. In a widget resource, resources may be organized in directories and may have versions of those directories tailored for localization purposes. Examples of resources include images, text, markup, style sheets, executable scripts, and sounds.

시작 화일(Start file): A resource either inside the widget resource or on the Web that when instantiated represents the widget. If an instantiated widget contains a configuration document, the widget user agent may configure the start file through that configuration document.

환경설정 문서(Configuration document): A distinguished resource where authors can declare metadata and/or configuration parameters for a widget. A widget user agent uses a configuration document to configure a widget upon instantiation. The configuration document may also define the relationship between resources in the widget resource. The configuration document usually takes the form of an XML file; for example, the config.xml resource bundled with an Opera widget.

메타데이타(Metadata): Data declared in the configuration document about a widget that relates to authorship or classification, but does not affect the behavior of the widget at runtime (eg. the author's name and email).

환경설정 파라미터(Configuration parameter): Any declaration in the configuration document that affords the widget with functionality beyond its default behavior (eg. declaring that the widget will require network access).

부트스트랩(Bootstrap): A mechanism that either declaratively or automatically finds the start file in an instantiated widget. 위젯 API(Widget API): A set of programming interfaces that provide functionality specific to and instantiated widget. Current APIs range extensively in the level of functionality they provide an author; see for example Microsoft's API for accessing the operating system in the Sidebar Reference.

1.2 위젯과 위젯 사용자 에이전트

Since around 2003, a relatively new kind of application has seen significant proliferation onto desktop computers and, more recently, web-enabled portable devices like mobile phones. This kind of application is generally referred to by developers as a widget engine: a piece of software that is able to run other smaller applications known as widgets or gadgets. On the user's desktop, widgets have gradually taken the place of some traditional single-purpose applications. Typical examples of widgets range from simple clocks, CPU gauges, post-it notes, games, battery-life indicators, to more sophisticated web-enabled widgets like weather forecasters, news readers, email checkers, photo albums and currency converters.

There are literally thousands of unique widgets available for download on the web, which users generally collect to create personal widget inventories. These widget inventories provide users with access to online services that they commonly use. This means that, in a lot of instances, users don't need to open up a web browser to get the information that they want (eg. to check the weather). This is an aspect of widgets that makes them particularly attractive on mobile devices, where the monetary cost of downloading web pages is currently an issue for many users.

For developers, some widgets differ from traditional binary applications in that they are created using the same open technologies used to create web pages. Widget engines mimic, in many ways, the behavior of web browsers: an increasing number are actually built directly on top of web browsers so they are able to render web pages, while others incorporate web browser components such as ECMAScript interpreters. To developers and vendors, this means that most widgets are significantly easier to create than applications developed with lower-level programming languages such as Java and C#.

Amidst the popular rise of widgets and widget engines lay a number of issues for users, developers, current vendors and new vendors wanting to enter the market. By surveying various aspects that pertain to widget user agents, this document discusses these issues so they may be resolved through the W3C standardization process.

As shown in figure 1, a widget is instantiated on a widget user agent and can make use of a number of technologies that serve a different role (eg. distribution and deployment, etc). However, some of those technologies have not yet been formally standardized (items marked with an asterisk), which has contributed to fragmentation across the widget space.

Widget technology stack

Figure 1. A typical widget technology stack and aspects that have require standardization. Please note that this technology stack is intended as a guide, and does not represent the technology stack of any particular user agent.

1.3 모바일 위젯

모바일 위젯에 대한 기술 개요 기술

모바일 위젯에 대한 기술 개요 및 차별성 정리가 필요할 것 같습니다 -Jonathan Jeon 08. 8. 23. 오후 8:15

2. 적합성

이 문서의 규범적 부분내에서 사용하는 키워드 "해야 한다(MUST)", "해서는 안된다(MUST NOT)", "필수(REQUIRED)", "해야 한다(SHALL)", "해서는 안된다(SHALL NOT)", "하도록(SHOULD)", "하지 않도록(SHOULD NOT)", "권장(RECOMMENDED)", "할수 있다(MAY)" 및 "선택적(OPTIONAL)"은 [RFC2119]에서 설명한 바와 같이 해석되어야 한다.

이 문서의 위젯 요구사항은 다음과 같은 W3C의 위젯 표준 및 문서들과 연관을 맺고 있다.

이 밖에도 OMTP의 Bondi Activity 의 문서들과의 연관성도 갖고 있다.

규격 일치화(conforming specification)는 이 문서내에 기술된 하나 또는 다수의 요구사항들을 따르는 것이다. 규격 일치를 위해 그렇게 할 수 없는 기술적으로 합당한 이유가 있는 경우를 제외하고 "할 수 있다(may)" 또는 "하도록 한다(should)" 키워드와 함께 표현된 요구사항들을 따르기 위한 시도를 하도록(SHOULD) 한다.

요구사항을 따르기 어려운 기술적 이유가 있는 경우, 그 내용의 적절함에 대해서는 포럼 WG 멤버들과 함께 논의를 통해 검토할 것이며, W3C 및 국내외 업계, 그리고 외부 멤버들의 공개적인 검토를 받아 진행할 것이다.

3. 설계 목표

이 장은 비규범적이다.

이 장에서는 모바일 위젯 표준화의 주요한 설계 목표들에 대해 기술한다. 뒤에서 도출할 요구사항들은 직접적으로 이러한 설계 목표에 기반하고 있다.

접근성(Accessibility): 규격 일치를 위해 적절한 접근성 가이드라인([WCAG 2.0])을 지원하는 것이 필요하다.

다른 표준과의 호환성(Compatibility with other standards): 규격 일치를 위해 다른 가능한 표준의 직접적인 이용 또는 표준들과의 상호호환성 유지가 필요하다.

실제 개발 사례 또는 업계 모범사례(Current development practice or industry best-practices): 규격 일치를 위해 위젯 개발자들이 현재 이용하고 있는 개발 모범 사례를 고려하거나, 적절한 업계의 모범 사례 (예를 들어 MWBP 와 MWABP 같은)들을 장려하는 것이 필요하다.

장치독립성(Device independence): 규격 일치를 위해 적절한 장치 독립성 가이드라인을 지원하는 것이 필요하다

사용 편의성(Ease of use): 규격 일치를 위해 특별하게 요구되는 소프트웨어 없이 만듦으로 제작자에게 편리하고, 획득과 설치/실행이 최종사용자에게 편리하도록 할 수 있는 위젯 리소스와 같이, 편리한 이용과 불필요한 복잡도를 피하는 해법을 정의하는 것이 필요하다

국제화와 지역화(Internationalization and localization): 규격 일치를 위해 i18n-XML과 같이 위젯 개발 커뮤니티에서 이용되고 있는 현재의 실제적인 국제화 솔루션들을 고려하여, 적절한 국제화와 지역화 가이드라인을 구현하는 것이 필요하다.

상호호환성(Interoperability): 규격 일치를 위해 현재 시장을 선도하는 위젯 사용자 에이전트들이 가능한 호환될 수 있도록 하는 것이 필요하다.

수명 연장(Longevity): 규격 일치를 위해 위젯 리소스가 미래(예를 들어 W3C Process 에서 권장 현황에 따르면 규격이 만들어진 날로부터 100년)에도 처리될 수 있도록 보장하는 방안을 정의하는 것이 필요하다.

보안성(Security): 규격 일치를 위해 적절한 보안 정책들과 프로그래밍 행태를 추천함으로써 디바이스 제조사와 위젯 배포사, 제작자, 최종 사용자들의 보안 걱정을 해소하는 것이 필요하다. 규격 일치를 위해 배포와 설치시 보안 요구사항에 대해서도 고려해야만 한다.

웹과 오프라인 배포(Web and offline distribution): 규격 일치를 위해 최종 사용자가 위젯 리소스를 HTTP를 통해 획득하거나, 로컬 화일 시스템, 블루투스 또는 메시징 시스템과 같이 HTTP 기반이 아닌 (오프라인) 방법들을 통해 획득하는 경우에 대해 다루는 것이 필요가 있다. 추가적으로, 규격 일치를 위해 새롭거나 또는 다른 버전의 위젯이 가능해졌을 때 위젯을 업데이트할 수 있도록 하는 방법을 제공하는 것이 필요하다. 온라인 또는 오프라인 소스에 상관없이 업데이트하는 것이 가능해야 한다.

4. 요구사항

이 절은 규범적이다.

이 절에서는 규격 일치를 위하는 위젯 표준화에 따라 필요한 요구사항들을 열거한다. 이들 요구사항들은 설계 목표에 직접적으로 기반하고 있으며, 여러번의 업계 의견 수렴과 시장을 선도하고 있는 위젯 사용자 에이전트들에 대한 조사들을 통해 나온 결과에 기초하고 있다.

4.1 패키징

이 절에서는 규격 일치를 위해 위젯의 패키징 포맷의 표준화에 따라 요구되는 요구사항들을 열거한다. 이 절의 목적은 규격 일치를 위한 일반적 패키징 포맷을 살핀다.

모바일과 데스크탑 상에서 이미 시장을 선도하고 있는 위젯 사용자 에이전트 상의 사실 표준
다중언어 컨텍스트내에서 이용하는 것이 가능한
모바일 디바이스에 적절한
디지틀 서명 지원이 가능한

R1.패키징 포맷(Packaging Format)

규격 일치를 위해 저작권 없고, 공개되고, 시장을 선도하는 위젯 사용자 에이전트를 포함해 폭넓게 구현되고 있으며, 모바일 단말과 호환되는 패키징 포맷을 반드시 권고해야한다(MUST). 부가적으로 규격 일치를 위해 위젯 사용자 에이전트의 일치화가 지원될 수 있도록 반드시 패키징 포맷의 형태를 정확하게 명세해야 한다.

동기(Motivation): 다른 표준과의 호환성(Compatibility with other standards), 웹과 오프라인 배포(Web and offline distribution), 장치독립성(device independence), 사용 편의성(ease of use), 실제 개발 사례 또는 업계 모범사례(current development practice or industry best-practices), 국제화와 지역화(internationalization and localization), 수명 연장(longevity). 근본적 이유(Rationale): 벤더들의 구현 편의성, 제작자의 플랫폼 사용 및 액세스 편의성과 관련하여 상호호환 가능하며 널리 활용가능한 패키징 포맷을 정의하는 것임

R2. 화일 확장자(File Extension)

규격 일치를 위해 굳이 HTTP 위로 전송하는 경우가 아니더라도 위젯 리소스를 위한 화일 확장자를 정해야 한다. 추가로, 규격 일치를 위해 심지어 HTTP로 전송을 시작한 때라도, 위젯 리소스는 늘 화일 확장자를 포함하는 것을 권장하도록 한다.

동기(Motivation): 장치독립성(device independence), 사용 편의성(ease of use), 웹과 오프라인 배포(Web and offline distribution). 근본적 이유(Rationale): When a MIME Type is not present, as is the case when a widget is instantiated locally from an end-user's storage device, the operating system will sometimes use the file extension to associate the widget resource with the appropriate widget user agent. However, when the widget is distributed over HTTP and a MIME type is present, a file extension may not be required. Note also that, in some cases, Web servers may also rely on a file extension to correctly set a widget resource's MIME type in the HTTP headers.

R3. 내부 추상 구조(Internal Abstract Structure)

R4. 예약 리소스와 디렉토리명(Reserved Resources and Directory Names)

R5. 어드레싱 체계(Addressing Scheme)

R6. 다중언어 리소스명(Multilingual Resource Names)

R7. 국제화 가이드라인(Internationalization Guidelines)

R8. 자동 지역화(Automatic Localization)

R9. 장치독립성(Device Independence)

R10. 데이타 압축(Data Compression)

R11. 디지털 서명(Digital Signature)

R12. MIME 타입(MIME Type)

4.2 환경설정 문서(Configuration Document)

R13. 위젯 메타데이타(Widget Metadata)

R14. 원작자 명시와 위젯 메타데이타(Authorship and Widget Metadata)

R16. 비주얼 렌더링 차원(Visual Rendering Dimensions)

R17. 선언적 부트스트랩(Declarative Bootstrap)

R18. 자동화된 부트스트랩(Automated Bootstrap)

R19. 아이콘화 표현(Iconic Representations)

R20. 환경설정 파라미터(Configuration Parameters)

R21. 보안 선언(Security Declarations)

R22. XML, 마이크로 구문과 스키마(XML, Micro-Syntaxes and Schema)

R23. 환경설정 문서 독립성(Configuration Document Independence)

4.3 스크립팅 인터페이스(Scripting Interfaces)

R24. 인스턴스 위젯 API (Instantiated Widget API)

R25. 런타임 속성 설정하기(Configuring Runtime Properties)

R26. 선호도 얻기와 설정하기(Getting and Setting Preferences)

R27. 위젯 상태 변경 이벤트(Widget State Change Events)

R28. 네트워크 상태 변경 이벤트(Network State Change Events)

R29. 모달 우선순위(Modal Priority)

R30. 디바이스 지정 API와 서비스(Device Specific APIs and Services)

R31. ECMAScript 호환성(ECMAScript Compatibility)

R32. XHR(XMLHttpRequest)

R33. 교차 위젯 통신(Cross-Widget Communication)

R34. 아이콘 API(Icon API)

R35. 환경설정 문서 데이타(Configuration Document Data)

R36. 개방형 기본 시스템 웹 브라우저(Open Default System Web Browser)

4.4 사용자 인터페이스 언어(User Interface Language)

R37. 언어 접근성(Language Accessibility)

4.5 사용자 에이전트(User Agents)

R38. 부가 디지털 인증서(Additional Digital Certificates)

R39. 최종 사용자 정의 프락시(End-user Declared Proxy)

R40. 자동 업데이트(Automatic Updates)

R41. 선호도 보관 저장소(Persistent Storage of Preferences)

R42. 다중 위젯 인스턴스(Multiple Widget Instances)

4.6 보안(Security)

R43. 기본 보안 정책(Default Security Policy)

R44. 런타임 보안 예외(Runtime Security Exceptions)

참고

Normative References

Informative References

Ajax Ajax: A New Approach to Web Applications. J. J. Garrett. February 18, 2005. Adaptive Path. Available at http://www.adaptivepath.com/publications/essays/archives/000385.php Atom Auto-Discovery Atom Autodiscovery, M. Pilgrim, P. Ringnalda. ATOMPUB Working Group (Draft), May 2005-. Available at http://philringnalda.com/rfc/draft-ietf-atompub-autodiscovery-01.html Bluetooth Bluetooth Core Specification 2.1. Available at http://www.Bluetooth.com/NR/rdonlyres/F8E8276A-3898-4EC6-B7DA-E5535258B056/6545/Core_V21__EDR.zip CSS Cascading Style Sheets, level 2, revision 1, B. Bos, T. Çelik, I. Hickson, and H. Wium Li.e., W3C Candidate Recommendation 19 July 2007. Available at http://www.w3.org/TR/CSS21 Dashboard Reference Dashboard Reference, Apple Computer, Inc, May 2006. Available at http://developer.apple.com/documentation/AppleApplications/Reference/Dashboard_Ref/index.html Google Gadgets Google Desktop Sidebar Scripting API, Google Inc., 2006. Available at http://desktop.google.com/script.html MWBP Mobile Web Best Practices 1.0. J. Rabin, C. McCathieNevile, W3C Recommendation, July 2008. Available at http://www.w3.org/TR/mobile-bp/ MWABP Mobile Web Application Best Practices. B. Sullivan. A. Connors, W3C Working Draft (Recommendation), July 2008. Available at http://www.w3.org/TR/mwabp/ Sidebar Reference Windows Sidebar Reference, Microsoft Corporation, 2006. Available at http://msdn2.microsoft.com/en-us/library/aa965853.aspx Widget Landscape Widgets 1.0: The Widget Landscape. M. Caceres. W3C Working Draft (Working Group Note). Available at http://www.w3.org/TR/widgets-land/ W3C Process World Wide Web Consortium Process Document. I. Jacobs, W3C. 14 October 2005. Available at http://www.w3.org/2005/10/Process-20051014/ Widgets 1.0: Packaging and Configuration Widgets 1.0: Packaging and Configuration. M. Caceres. W3C Working Draft. Latest Editor's Draft available at http://dev.w3.org/2006/waf/widgets/ Widgets 1.0: Automatic Updates Widgets 1.0: Automatic Update. M. Caceres. Forthcoming W3C Working Draft. Latest Editor's Draft available at http://dev.w3.org/2006/waf/widgets-updates/ Widgets 1.0: APIs and Events Widgets 1.0: APIs and Events. M. Caceres. Forthcoming W3C Working Draft. Latest Editor's Draft available at http://dev.w3.org/2006/waf/widgets-api/ Widgets 1.0: Digital Signatures Widgets 1.0: Digital Signatures. M. Caceres. W3C Working Draft. Latest Editor's Draft available at http://dev.w3.org/2006/waf/widgets-digsig/ Widgets 1.0: Security Widgets 1.0: Security. Forthcoming W3C Working Draft. No draft publicly available.