ABNT NBR 15606-1 - Universidad de Buenos Aires

BRAZILIAN
STANDARD
ABNT NBR
15606-1
First edition
2007.11.30
Valid from
2007.12.01
Digital terrestrial television — Data coding
and transmission specification for digital
broadcasting
Part 1: Data coding specification
Descriptors: Digital terrestrial television. Digital broadcasting. Data coding.
ICS 33.160.01
ISBN 978-85-07-00614-5
Reference number
ABNT NBR 15606-1:2007
24 pages
© ABNT 2007
ABNT NBR 15606-1:2007
ABNT office
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any
means, electronic or mechanical, including photocopying and microfilm, without permission in writing from either ABNT.
ABNT office
Av.Treze de Maio, 13 - 28º andar
20031-901 - Rio de Janeiro - RJ
Tel.: + 55 21 3974-2300
Fax: + 55 21 2220-1762
abnt@abnt.org.br
www.abnt.org.br
Published in Brazil
ii
© ABNT 2007 – All rights reserved
ABNT NBR 15606-1:2007
Contents
Pages
Foreword......................................................................................................................................................................v
1
Scope ..............................................................................................................................................................1
2
Normative references ....................................................................................................................................1
3
Terms and definitions ...................................................................................................................................2
4
Abbreviations.................................................................................................................................................3
5
5.1
5.1.1
5.1.2
5.2
5.2.1
5.2.2
Basic architecture..........................................................................................................................................3
System architecture ......................................................................................................................................3
Reference model............................................................................................................................................3
Interface specification...................................................................................................................................4
Middleware architecture................................................................................................................................5
Application environment structure..............................................................................................................5
Application environment description ..........................................................................................................5
6
6.1
6.2
Protocol ..........................................................................................................................................................6
Protocol stack ................................................................................................................................................6
Data transmission modes.............................................................................................................................6
7
7.1
7.2
7.2.1
7.2.2
7.3
7.4
7.5
Receiver ..........................................................................................................................................................7
Reference model for receiver .......................................................................................................................7
Receiving and storing function ...................................................................................................................7
Data storage ...................................................................................................................................................7
Data and video storage .................................................................................................................................7
Presentation function....................................................................................................................................7
Decoding process and display.....................................................................................................................7
Plug-in.............................................................................................................................................................8
8
8.1
8.1.1
8.1.2
8.2
8.3
Presentation process ....................................................................................................................................9
Logical coordinate.........................................................................................................................................9
Logical coordinate and display coordinate in square pixel format..........................................................9
Logical coordinate and display coordinate in non-square pixel format..................................................9
Colorimetry.....................................................................................................................................................9
Composition between planes.......................................................................................................................9
9
Profiles specification...................................................................................................................................10
10
10.1
10.2
Requirements for data broadcasting and available services..................................................................14
Requirements of data broadcasting for digital broadcasting system ...................................................14
Data service for digital broadcasting ........................................................................................................17
11
11.1
11.1.1
11.1.2
11.1.3
11.1.4
11.2
11.2.1
11.2.2
11.2.3
11.2.4
11.2.5
11.2.6
11.2.7
11.2.8
Monomedia...................................................................................................................................................19
Video coding ................................................................................................................................................19
MPEG-1 video...............................................................................................................................................19
MPEG-2 video...............................................................................................................................................19
MPEG-4 video...............................................................................................................................................19
H.264|MPEG-4 AVC......................................................................................................................................19
Still pictures and graphics coding.............................................................................................................19
I-frames .........................................................................................................................................................19
JPEG .............................................................................................................................................................20
PNG ...............................................................................................................................................................20
MNG...............................................................................................................................................................20
MPEG-2 video “drips” .................................................................................................................................20
GIF .................................................................................................................................................................20
MPEG-4 video clips .....................................................................................................................................20
H.264|MPEG-4 AVC clips.............................................................................................................................20
© ABNT 2007 – All rights reserved
iii
ABNT NBR 15606-1:2007
11.3
11.3.1
11.3.2
11.3.3
11.3.4
11.3.5
11.3.6
11.3.7
11.4
11.4.1
11.4.2
11.4.3
11.4.4
11.5
11.6
iv
Audio coding................................................................................................................................................20
MPEG-2 audio ..............................................................................................................................................20
PCM (AIFF) ...................................................................................................................................................20
MPEG-4 audio ..............................................................................................................................................20
Coding of synthesized sound ....................................................................................................................21
Monomedia format for audio clips (GEM) .................................................................................................21
MPEG-1 audio layer 3 (MP3) .......................................................................................................................21
Audio AC3 ....................................................................................................................................................21
Character coding .........................................................................................................................................21
8 bits character coding ...............................................................................................................................21
Universal multi-octet coded character set (UCS).....................................................................................23
Shift-JIS coding ...........................................................................................................................................24
EUC-JP..........................................................................................................................................................24
Geometric description of commands coding ...........................................................................................24
Subtitles and superimposed characters ...................................................................................................24
© ABNT 2007 – All rights reserved
ABNT NBR 15606-1:2007
Foreword
Associação Brasileira de Normas Técnicas (ABNT) is the Brazilian Standardization Forum. Brazilian Standards,
which content is responsability of the Brazilian Committees (Comitês Brasileiros – ABNT/CB), Sectorial
Standardization Bodies (Organismos de Normalização Setorial – ABNT/ONS) and Special Studies Committees
(Comissões de Estudo Especiais – ABNT/CEE), are prepared by Study Committees (Comissões de Estudo – CE),
made up of representants from the sectors involved including: producers, consumers and neutral entities
(universities, laboratories and others).
Brazilian Standards are drafted in accordance with the rules given in the ABNT Directives (Diretivas), Part 2.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights.
ABNT shall not be held responsible for identifying any or all such patent rights.
ABNT NBR 15606-1 was prepared within the purview of the Special Studies Committees of Digital Television
(ABNT/CEE-00:001.85). The Draft Standard was circulated for National Consultation in accordance with
ABNT Notice (Edital) nº 09, from September 06, 2007 to November 05, 2007, with the number Draft 00:001.85-006/1.
Should any doubts arise regarding the interpretation of the English version, the provisions in the original text
in Portuguese shall prevail at all time.
This standard is based on the work of the Brazilian Digital Television Forum as established by the Presidential
Decree number 5.820 of June, 29th 2006.
ABNT NBR 15606 consists of the following parts, under the general title “Digital terrestrial television —
Data coding and transmission specifications for digital broadcasting”:
⎯ Part 1: Data coding specification;
⎯ Part 2: Ginga-NCL for fixed and mobile receivers – XML application language for application coding;
⎯ Part 3: Data transmission specification;
⎯ Part 4: Ginga-J – The environment for the execution of procedural applications;
⎯ Part 5: Ginga-NCL for portable receivers – XML application language for application coding.
This Standard is the English version of the corrected version dated 2008.04.07 of ABNT NBR 15606-1:2007.
© ABNT 2007 – All rights reserved
v
BRAZILIAN STANDARD
ABNT NBR 15606-1:2007
Digital terrestrial television — Data coding and transmission specification
for digital broadcasting
Part 1: Data coding specification
1
Scope
This part of ABNT NBR 15606 specifies the reference model enabling data broadcasting, which is part of the digital
broadcasting system specified as Brazilian system digital television (SBTVD), besides the monomedia supported
by the data broadcasting system and code of caption e superimpose characters.
2
Normative references
The following referenced documents are indispensable for the application of this document. For dated references,
only the edition cited applies. For undated references, the latest edition of the referenced document (including any
amendments) applies.
ABNT NBR 15602-1:2007, Digital terrestrial television – Video coding, audio coding and multiplexing –
Part 1: Video coding
ABNT NBR 15602-2, Digital terrestrial television – Video coding, audio coding and multiplexing – Part 2: Audio
coding
ABNT NBR 15606-2, Digital terrestrial television – Data coding and transmission specification for digital
broadcasting — Part 2: Ginga-NCL for fixed and mobile receivers – XML application language for application
coding
ABNT NBR 15606-3, Digital terrestrial television – Data coding and transmission specification for digital
broadcasting — Part 3: Data transmission specification
ISO/IEC 8859-15, Information technology – 8-bit single-byte coded graphic character sets – Part 15: Latin alphabet
No. 9
ISO/IEC 10646-1, Universal multiple-octet coded character set (UCS) – Part 1: Architecture and basic multilingual
plane (BMP)
ISO/IEC 10918-1, Information technology – Digital compression and coding of continuous – Tone still images:
Requirements and guidelines
ISO/IEC 11172-2, Information technology – Coding of moving pictures and associated audio for digital storage
media at up to about 1,5 Mbit/s - Part 2: Video
ISO/IEC 11172-3, Information technology – Coding of moving pictures and associated audio for digital storage
media at up to about 1,5 Mbit/s – Part 3: Audio
ISO/IEC 13818-1, Information technology – Generic coding of moving pictures and associated audio information:
Systems
ISO/IEC 13818-2, Information technology – Generic coding of moving pictures and associated audio information –
Part 2: Video
© ABNT 2007 – All rights reserved
1
ABNT NBR 15606-1:2007
ISO/IEC 13818-3, Information technology – Generic coding of moving pictures and associated audio information –
Part 3: Audio
ISO/IEC 13818-7, Information technology – Generic coding of moving pictures and associated audio information –
Part 7: Advanced Audio Coding (AAC)
ISO/IEC 14496-2, Information technology – Coding of audio-visual objects – Part 2: Visual
ISO/IEC 14496-3, Information technology – Coding of audio-visual objects - Part 3: Audio
ISO/IEC 14496-10, Information technology – Coding of audio-visual objects – Part 10: Advanced video coding
ITU Recommendation BT.470-7, Conventional television systems
ITU Recommendation BT.709, Parameter values for the HDTV standards for production and internacional
programmer exchange
ITU Recommendation J.200:2001, Worldwide common core – Application environment for digital interactive
television services
ITU Recommendation H.222.0, Information technology – Generic coding of moving pictures and associated audio
information: Systems
ITU Recommendation H.262, Information technology – Generic coding of moving pictures and associated audio
information: Systems
ITU Recommendation H.264, Advanced video coding for generic audiovisual services
ARIB STD-B24:2007, Data coding and transmission specifications for digital broadcasting
ARIB STD-B23:2004, Application execution engine platform for digital broadcasting
ARIB STD-B5, Standard television data multiplex broadcasting by transmission method using vertical blanking
interval
ATSC A52B, Digital audio compression standard
MHP 1.0:2003, Multimedia home platform – MHP specification 1.03
GEM 1.0:2005, Globally executable MHP
W3C Recommendation PNG:2003, Portable network graphics specification
W3C Recommendation GIF89a, Graphics interchance format (sm)
3
Terms and definitions
For the purposes of this part of ABNT NBR 15606, the following terms and definitions apply.
3.1
monomedia
individual media font to presentation
EXAMPLE
2
Video, audio, text, image, etc.
© ABNT 2007 – All rights reserved
ABNT NBR 15606-1:2007
3.2
stream
type of continuous communications that values time factor
3.3
transport stream
TS
communication protocol for audio, video and data broadcasting
4
Abbreviations
For the purposes of this part of ABNT NBR 15606, the following abbreviations apply.
AAC
Advanced Audio Coding
AIFF
Audio Interchange File Format
CATV
Cable Television
DSM-CC
Digital Storage Media – Command and Control
EPG
Eletronic Program Guide
GEM
Globally Executable MHP
GIF
Graphics Interchange Format
HDTV
High Definition Television
JPEG
Joint Picture coding Experts Group
MHP
Multimedia Home Platform
MNG
Multiple-image Network Graphics
MPEG
Moving Picture Expert Group
PCM
Pulse Code Modulation
PES
Packetized Elementary Stream
PNG
Portable Network Graphics
SBTVD
Brazilian system digital television
UCS
Universal multi-octet coded Character Set
5
Basic architecture
5.1
5.1.1
System architecture
Reference model
In order to the viewer receive and present such services properly, some receivers' characteristics specification
is also necessary.
NOTE
This Standard shows the reference model for the data broadcasting system, which extend the model defined by
ARIB STD-B24:2007, volume 1, part 1, clause 4, including applications coding and objects carrousel. The suitable presentation
of a data service refers to the service presentation as planned by the diffusion service operator.
The system that implements data broadcasting service in digital broadcasting shall be according to Figure 1.
© ABNT 2007 – All rights reserved
3
ABNT NBR 15606-1:2007
Figure 1 — System structure
5.1.2
Interface specification
Detailed specification shall be according to each interface:
⎯ monomedia coding: coding system for character string, bit map etc., that shall be used in multimedia coding
according to 11.1,11.2 e 11.3;
⎯ coding of subtitle and superimpose: coding system of subtitle and superimpose on bitmap according to 11.6;
⎯ multimedia coding: coding system of XML adopted as multimedia coding system and its profile according to
ABNT NBR 15606-2;
⎯ content transmission format: content transmission format of objects and data carousel transmission method
according to ABNT NBR 15606-3;
⎯ subtitle and superimpose transmission format: independent PES transmission format to transmit subtitles and
superimpose according to 11.6;
⎯ applications coding: coding system of Java adopted as applications coding system and its profile, in
accordance with the procedural environment.
4
© ABNT 2007 – All rights reserved
ABNT NBR 15606-1:2007
5.2
5.2.1
Middleware architecture
Application environment structure
Middleware architecture for interactive television of SBTVD shall be according to ITU Recommendation J.200:2001,
subclause 4.1, and it can be basically represented by two important components: execution engine and
presentation engine. Such components can not be independent being necessary to establish proper bridges
between the engines. Additionally to these basic components, native applications, or other specific and content
software may exist.
The applications environment structure shall be according to Figure 2.
Figure 2 — Application environment structure
5.2.2
Application environment description
Applications environment shall be composed by the following architectural elements:
⎯ presentation and execution engine according to ABNT NBR 15606-2 and procedural environment respectively;
⎯ bridge: applications mechanism which allows bidirectional mapping among the API Java and DOM,
ECMAScript and LUAScript objects and methods according to ABNT NBR 15606-2 and procedural
environment;
⎯ application life cycle monitor: application or resource of the operating system for control of the state of the
software. Its function includes management of the entire application life cycle, including initialization, end and
control. Applications life cycle monitor shall be according to procedural environment;
⎯ applications: may be written for presentation engine, execution engine, or both;
© ABNT 2007 – All rights reserved
5
ABNT NBR 15606-1:2007
⎯ other media: include media streams like audio and data or mono-media as still pictures and characters string
(see 11.1, 11.2 and 11.3);
⎯ native software: includes legacy software or written software using additional API with functionalities.
NOTE
6
Legacy software or software written using API with additional functionality are not specified in the standard.
Protocol
6.1
Protocol stack
In the digital broadcasting system, video, audio as well as all the data services shall be multiplexed in the TS
specified by MPEG2 (see ITU Recommendation H.222.0 and ISO/IEC 13818-1) system, which shall be transmitted
over a radio wave. Interaction channel shall be provided through independent network of this protocol stack.
The protocol stack used in digital broadcasting is in accordance with ARIB STD-B24:2007, volume 1, clause 5.
The system stack protocol stack shall be according to Figure 3.
Figure 3 — System protocol stack
6.2
Data transmission modes
The data transmission supported by the data diffusion system shall be one of the following modes:
⎯ data transmission system through PES packet stream: this system shall be used for real time services. It shall
be used with information that need time control, such as video, audio, subtitles and data synchronised with
other streams, like the main video. This system shall be specified as data stream;
⎯ data transmission system using section: this system shall be used for stored services. The data shall be
transmitted repeatedly until it is completed your download at the receiver side. This system shall be specified
as data carousel (DC) and as object carousel (OC).
NOTE
6
The system of data transmission using the transport stream packages is specified in ABNT NBR 15606-3.
© ABNT 2007 – All rights reserved
ABNT NBR 15606-1:2007
7
Receiver
7.1 Reference model for receiverReference model for the receiver shall be in accordance with ARIB STDB24:2007, volume 1, part 1, clause 6.
Some basic functions are specified to enable several multimedia services offer. The receivers shall have functions
to receive, display, store and communicate with the data broadcasting service, in addition to keeping basic
functions to view normal television programs.
7.2
7.2.1
Receiving and storing function
Data storage
The data storage consists in the reception and storing of data received by the data broadcasting system.
This function shall be available in all the receivers.
7.2.2
Data and video storage
Both the video and data received by the receiver can be stored. The storage of video can be held in secondary
devices such as disk or tape. And the data storage will be made in flash memory.
Video storage can also be made available by primary storage device such as flash memory, when some restriction
is set to data broadcasting volume. During normal view, receiving and storing functions shall be performed in
background mode. Video storing shall be optional in the receivers.
7.3
Presentation function
Presentation function shall ensure the multimedia services are reproduced according to the content producer’s
specification, in all the receivers. The presentation function shall be designed based on the logical structure of
television screen, which is composed of five planes: video plane, still picture plane, selection plane switching
video/still picture, text and graphic plane and subtitle plane. This logical planes structure is in accordance with sub
ARIB STD-B24:2007, volume 1, part 1, subclause 6.2. The planes structure for services presentation shall be in
accordance with Figure 4.
Figure 4 — Planes structure for services presentation
7.4
Decoding process and display
The model structure of decoding function in receiver is indicated in Figure 5, showing how data is processed.
© ABNT 2007 – All rights reserved
7
ABNT NBR 15606-1:2007
Figure 5 — Model decoder in receiver showed with data processing flow
The decoding process in receiver can be divided in the following steps:
a)
data broadcasting decoding process: mono-media such as character figure, still pictures, videos, audio, are
transmitted in data stream or object and data carousel. These data are decoded and divided so that they are
individually processed as coded mono-media;
b)
mono-media decoding process: coded mono-media data is decoded by an appropriate decoder. Generally,
video and audio are decoded by exclusive hardware decoder, but it may be optionally made by software for
interactive applications use such as still picture, mpeg2-I frame;
c)
execution and presentation process: mono-media shall be presented in video, still pictures, text and graphic
and subtitles planes. In multimedia service control and transmitted applications is made as the specified in
multimedia coding and application coding, respectively; and the subtitle and superimpose service control is
made as specified in 11.6.
7.5
Plug-in
A plug-in is a functionality which may be added to a generic platform intended to extend the execution capacities of
mono-media and multimedia application and format decoding which can not be required in the terminals for access.
8
© ABNT 2007 – All rights reserved
ABNT NBR 15606-1:2007
8
Presentation process
8.1
Logical coordinate
8.1.1
Logical coordinate and display coordinate in square pixel format
8.1.1.1
Logical coordinate of video plane and still picture plane
The logical coordinate of video plane and still image plane shall be according to ARIB STD-B24:2007, volume 1,
part 1, subclause 7.1.1.1.
8.1.1.2
Text and graphic plane
The text and graphic plane shall be in accordance with ARIB STD-B24:2007, volume 1, part 1, subclause 7.1.1.2.
8.1.1.3
Subtitle plane
The subtitle plane shall be in accordance with ARIB STD-B24 :2007, volume 1, part 1, subclause 7.1.1.3.
8.1.1.4
Video and still picture switching plane
The video and still picture plane shall be in accordance with ARIB STD-B24:2007, volume 1, part 1,
subclause 7.1.1.4.
8.1.2
Logical coordinate and display coordinate in non-square pixel format
The logical coordinate and display coordinate in non-square pixel format shall be in accordance with
ARIB STD-B24:2007, volume 1, part 1, subclause 7.1.2.
8.2
Colorimetry
The colorimetry shall be in accordance with ITU Recommendation BT.470-7, ITU Recommendation BT.709
and ABNT NBR 15602-1:2007, subclause 6.1.11.
8.3
Composition between planes
The composition between planes shall be in accordance with ARIB STD-B24:2007, volume 1, part 1, subclause 7.3.
The composition between planes function shall be according to Table 1.
Table 1 — Composition control function between planes
Planes
Specification range
Between video and still picture plane and
another plane
Switching in 2-pixel unit
Between text and graphic plane and other plane
α-blending in pixel unit 1/256 steps
Between subtitle plane and other plane
α-blending in pixel unit 1/256 steps
© ABNT 2007 – All rights reserved
9
ABNT NBR 15606-1:2007
9
Profiles specification
Products in accordance with profiles shall provide all the marked resources as mandatory in the corresponding
column of Table 2. In some cases this implies that further hardware shall be added to the device.
Table 2 — Profiles especification
Parameters for full-seg and one-seg receivers
Type of receptor
Features specified
Area
Coments
Full-seg
One-seg
PNG with restrictions
Required
Required
PNG unrestricted
Optional
Optional
GIF
Optional
Optional
MPEG-2 "I - Frame"
Optional
Optional
MPEG-4 "I – VOP"
Optional
Optional
H.264 / MPEG-4 AVC "I - Picture"
Required
Required
JPEG with restrictions
Required
Required
JPEG unrestricted
Optional
Optional
MNG with restrictions
Required
Optional
MNG unrestricted
Optional
Optional
MPEG-2 audio AAC LC/BC
Optional
Optional
Optional
Not
applicable
MPEG-4 audio AAC-LC
Required
Required
Encoding of synthesized sounds
Optional
Optional
Áudio monomedia format-clips MPEG-1 áudio
(Layers 1 e 2)
Required
Required
MPEG-1 audio layer 3 (MP3)
Optional
Optional
Not
applicable
Not
applicable
MPEG-2 video drips
Optional
Optional
MPEG-4 video clips
Optional
Optional
H.264 / MPEG-4 AVC clips
Required
Optional
Codes character of 8 bits
Required
Optional
Required
Optional
Codes character Shift-JIS
Not
applicable
Not
applicable
Monomedia - format for text
Required
Required
Required
Required
Bitmap pictures
Static Format (monomedias)
PCM (AIFF-C)
Audio
Audio AC-3
Text Codinbg
Vídeo
clips
Universal multi-octect
coded character set
Color
Minimum number of colors
10
65 536 colors
© ABNT 2007 – All rights reserved
ABNT NBR 15606-1:2007
Table 2 (continuation)
Parameters for full-seg and one-seg receivers
Type of receptor
Features specified
Area
Coments
Full-seg
One-seg
Main program video
Required
Required
Audio
Main program audio
Required
Required
Optional
Optional
Optional
Optional
Hide language
Optional
Optional
Brazilian Signs language
Locked events
Required
Required
Indicated rating
Required
Required
Resident
Tirésias
Required
Optional
Verdana
Optional
Required
Downloadable
Required
Optional
PFR (Portable Fonts Resource)
Optional
Optional
Open types
Optional
Optional
Subtitle
Video
Downloadable
Media Streaming Format
Subtitles and caracteres
Superimposed
Closed-
Caracteres
caption
superimposed
LIBRAS
Signs language
rating
Parental
Parental Rating
Source
© ABNT 2007 – All rights reserved
11
ABNT NBR 15606-1:2007
Table 2 (continuation)
Parameters for full-seg and one-seg receivers
Type of receptor
Area
Features specified
Full-seg
One-seg
MPEG-2 section
Required
Required
Object carousel – DSM-CC
Required
Required
Data carousel– DSM-CC
Optional
Optional
Comments
IP Multicast
Broadcast Channel Protocol
o
Receiver software update
Optional
Optional
o
Broadcast parameter update
Optional
Optional
Optional
Optional
Not
applicable
Not
applicable
Optional
Required
(RX Full seg) – Required, only
with return channel
Optional
Required
(RX Full seg) – Required, only
with return channel
Optional
Required
(RX Full seg) – Required, only
with return channel
Optional
Required
(RX Full seg) – Required, only
with return channel
Optional
Required
(RX Full seg) – Required, only
with return channel
Optional
Required
(RX Full seg) – Required, only
with return channel
User Datagram Protocol (UDP)
Optional
Required
(RX Full seg) – Required, only
with return channel
UNO-RPC
Optional
Optional
UNO-CDR
Optional
Optional
DCM-CC User to User
Optional
Optional
Optional
Required
Not
applicable
Not
applicable
Optional
Required
Pilha IP multicast:
o
Protocolo IP multicast via broadcast
channel
o
Encapsulated multiprotocol DVB
o
Internet Protocol “IP”
o
User Datagram Protocol (UDP)
o
IP signalling
Interactive Channel Protocol
TCP
/ IP
UDP
U-U RPC
DSM-CC
/ IP
Transmission Control Protocol (TCP)
Internet Protocol (IP)
Internet Protocol (IP)
HTTP 1.1
HTTP
MHP profile de HTTP 1.0
DNS
12
DNS
(RX Full seg) – Required, only
with return channel
(RX Full seg) – Required, only
with return channel
© ABNT 2007 – All rights reserved
ABNT NBR 15606-1:2007
Table 2 (continuation)
Parameters for full-seg and one-seg receivers
Type of receptor
Features specified
Comments
One-seg
HTTPS
Optional
Optional
File system implemented only via the
interaction channel
Optional
Optional
Hybrid between broadcast stream and
interaction channel
Optional
Optional
Interactivity security channel
Optional
Optional
External devices autentication
Optional
Optional
Conditional access
Not
applicable
Not
applicable
DRM
Not
applicable
Not
applicable
Module common interface
Not
applicable
Not
applicable
Autentication for applications
Required
Required
Security politics for applications
Required
Required
Certificate management
Required
Required
IPv4 e IPv6
Optional
Optional
Port ethernet
Optional
Not
applicable
Port USB
Optional
Not
applicable
External devices management
Optional
Not
applicable
Autentication management
Optional
Not
applicable
Modem configuration
Optional
Not
applicable
Modem selection
Optional
Not
applicable
Modem
Security
HTTPS
Interaction
Channel file
system
Full-seg
DSM-CC /
HTTP
Hybrid
Area
© ABNT 2007 – All rights reserved
Required, only with external device
return channel
Required, only with return channel
in external device
Mandatory for receivers with
interactivity channel and external
devices connection
13
ABNT NBR 15606-1:2007
Table 2 (continuation)
Parameters for full-seg and one-seg receivers
Type of receptor
Area
Features specified
Comments
Full-seg
One-seg
NCL
Required
Required
Java
Required
Optional
Full-seg receivers - Ginga-J is
mandatory
LUA
Required
Optional
One-seg receivers is mandatory if
there is Java implemented.
ECMAScript
Optional
Optional
Java virtual machine
Required
Optional
LUA
Required
Required
Software adaptation
Optional
Optional
Complex graphics elements
Optional
Optional
Aplication development
Optional
Optional
Messages pré-programed
Optional
Optional
Residential media center control and
distribution.
Optional
Optional
Middleware dinamic reconfiguration
Optional
Not
applicable
Device control and audio import
Optional
Not
applicable
Resident aplication remote instalation
Optional
Not
applicable
Multi device
Optional
Not
applicable
Multi user
Optional
Not
applicable
Program Language
Ginga
Bridge linkage between languages
Bridge
Execution Machine
Engine
Red APIs
Yellow APIs
Exclusive Ginga APIs
10 Requirements for data broadcasting and available services
NOTE
About available services, it is possible to assume that the multimedia services include: subtitles, interactive
applications, etc. It is possible to consider multimedia services as the interactive presentation of multiple integrated mono-media
through digital features.
10.1 Requirements of data broadcasting for digital broadcasting system
The digital broadcasting system shall be according to Tables 3 to 6.
14
© ABNT 2007 – All rights reserved
ABNT NBR 15606-1:2007
Table 3 — System overview
- Enable to display subtitles and superimpose overlapped on HDTV
and SDTV
- Enable to view HDTV, SDTV and audio services or independent
multimedia information a
Service contents
- It shall be possibilities of service not only other broadcast service,
but also combination with various services such as communication,
traditional package services, etc.
- It shall be considered interactive services utilizing public
communication services such as telephone, networks, etc.
- It shall be considered services corresponding to various viewers
such as elderly or handicapped people
Service
- EPG, functions for automatic indexing and recording etc. shall be
made available to facilitate the selection of programmes.
Accessibility
Extensibility
- It shall be considered time range for smooth program switching not
to be annoying to viewer’s actual operations. (avoid expectancy
break)
- It shall be considered extensibilities of service styles, coding
specification, conditional access system and receivers
- It shall be considered possibilities to correspond the new services
in the future
- Enable receiving, even in the ordinary receivers, similar services to
existing HDTV or SDTV broadcasting
Inter-operability
- Broadcasting media such as broadcasting station satellite,
terrestrial or cable, shall be as most similar as possible
- Common receiver shall be able to use the various specified media
types
- Consider flexible system control by using transmission capacity
effectively, by transmission control of HDTV, SDTV and audio in the
digital broadcasting
Control ability of system
- Consider control function for appropriate copyright protection
- Consider automatic reception control function such as emergency
broadcasting
Display timing
- In services related to HDTV, SDTV and audio services, timing
errors when displaying subtitles, superimpose and multimedia
information should be operated within the range so that viewers
would not feel uncomfortable or notice that the system has problems
a
Multimedia information means information that enables the integrated interactive view of multiple media such as text,
still pictures, video and audio etc.
© ABNT 2007 – All rights reserved
15
ABNT NBR 15606-1:2007
Table 4 — Broadcasting service quality
Presentation (display)
- Display quality of data services shall be able to reproduce programs with
good quality of picture and sound of HDTV, SDTV and audio services
- Quality balance of picture, sound and data shall be considered because
transmission trouble, such as ray attenuation etc.
Transmission characteristics
- In case of temporary disconnection, it shall be considered
countermeasures in order to not display error information, as far as
possible, like keeping the last picture
- In case of transmission trouble, it shall be considered time to reestablish
signal as short as possible
Table 5 — Technical specification
- It shall be considered existing data coding formats
Data coding
- It shall be considered future extensions
- It shall be considered possibility of software downloading
(update) and data interface for secure extendibility
- It shall be considered multiplexing for various and flexible
services
General technical
specification
Data multiplexing
specification
- It shall be considered multiplexing service by multiple service
providers
- It shall be considered transmission features and efficient
multiplexing
- It shall be enabled conditional access system for flexible
operation of content service
Data conditional access
system
- It shall be enabled suitable security and safety services for
service contents
- It shall be considered secure and independent operations for
multiple service providers
- It shall be enabled the program production, according to the
intention of the program producer
Subtitle and superimpose coding
- Standardized multimedia type service of digital broadcasting
should be maintained as far as possible to coordinate with
existing broadcast service
- International standardization
whenever possible
should
be
considered
- Enable realizing program production, according to the
intention of the program producer
Multimedia coding service
- On the condition of displaying the multimedia information
such as HDTV, SDTV, audio services, or independent
multimedia information, it should enable to realize multimediadisplaying function such as displaying or linking presentation
object for the specific duration on the specified position
(media timing)
- Consider the development of various services such as
storage-based and interactive type services
- Consider the standardization among digital broadcasting of
other media such as communication and packages
- International standardization should be considered
16
© ABNT 2007 – All rights reserved
ABNT NBR 15606-1:2007
Table 6 — Receiver (set-top box)
- Operation method of basic function shall be unique and easy to learn
Operability
- Settings which release advanced operations should only be enabled according to the
users or service providers’ request
- Selection of service should be considered so that it can be made by one operation
- Operation settings appropriate for elderly or handicapped people shall be also
considered
- It shall be made possible the implementation of a adapters to receive new services
by connecting to existing broadcasting receiver
Interoperability
- Consider the inter-operability between medias of other broadcasting systems such
as satellite broadcasting, terrestrial broadcasting and CATV
- Coordination with communication systems and media package should be considered
as far as possible
Implementation
Extendibility
- Consumers shall have access to a cheap receiver, which has functions and
characteristics appropriate for service contents to be implemented
- Implementation of several terminals (monofunction, advanced function, etc.) should
be considered
- It shall be considered the extension corresponding to new services in the future
- It shall be considered the possibility to connect the receiver to multiple devices
10.2 Data service for digital broadcasting
Table 7 shows examples about advanced data broadcasting services added to some technical demands.
© ABNT 2007 – All rights reserved
17
ABNT NBR 15606-1:2007
Index
Program title,
Category of each item
Program selection, item
selection
X
Subtitle
For hearing handicapped
person For foreigner
Subtitle, multilingual display
X
Audio with
commentary
For visually handicapped
person
Audio with comments
Participation
program
Independent
information
Additional information of the
Cast, program, product
information, news from the program, detailed information
of the program
station, etc.
Multiview television
Shopping, questionnaires,
etc.
News, weather forecast,
traffic information, market
information, disaster,
election, etc.
Display and control of
program using plural camera
angle
Access from the viewers to
the program
X
X
Time synchronous
X
Program
synchronous
X
Asynchronous
Program selection, program
scheduling, category search
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
Information service
selectable
X
X
X
X
X
X
Users inquiry
Inquiries
Corresponding to Access
from the viewer
Software
distribution
PC software, data, game
software and general
software downloading
Application distribution
Automatic
reception
Emergency information
Automatic power on,
automatic reception
Mail function
Individual mail, sending
information for all the
users
Individual information
Download
IRD (Integrated Receiver
Decoder), error correction,
version upgrade
Decoding software
downloading
Data
distribution
Several data
Data download
Up-line need
Program guide,
program content
Metadata
Still picture
EPG
Presentation
timing
Video
Audio
Function
Text and graphics
Related
Example of contents
Multiview
television
Function service
18
Example of
service
Addtional
program
information
Independent
Broadcasting service
Classification
Necessary
media
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
Study of coding
Table 7 — Examples of advanced data broadcasting service
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
X
© ABNT 2007 – All rights reserved
ABNT NBR 15606-1:2007
When the services showed in Table 7 are received, data shall be stored in the receiver memory and displayed
interactively according to the viewer’s operation.
In order to program television by using functions such as automatic recording, scheduled recording, digest
playback etc. of television program by use of storage function of video and audio. Furthermore, resources for
program recording in different channels and advanced data acquisition by use of multiple tuner units (decoders)
can be made available.
11 Monomedia
11.1 Video coding
11.1.1 MPEG-1 video
MPEG-1 video coding shall be in accordance with ISO/IEC 11172-2 and shall be according to the method
described in ARIB STD-B24:2007, volume 1, part 2, subclause 4.1.
11.1.2 MPEG-2 video
MPEG-2 video coding shall be in accordance with ISO/IEC 13818-2 and ITU Recommendation H.262 and shall be
according to the method described in ARIB STD-B24:2007, volume 1, part 2, subclause 4.2.
11.1.3 MPEG-4 video
MPEG-4 video coding shall be in accordance with ISO/IEC 14496-2 and shall be according to the method
described in ARIB STD-B24:2007, volume 1, part 2, subclause 4.3.
11.1.4 H.264|MPEG-4 AVC
H.264|MPEG-4 AVC video coding shall be in accordance with ITU Recommendation H.264 and ISO/IEC 14496-10
and with the methods described in ABNT NBR 15602-1 and ARIB STD-B24:2007, volume 1, part 2, subclause 4.4.
11.2 Still pictures and graphics coding
11.2.1 I-frames
11.2.1.1
MPEG-2 I-frames
MPEG-2 I-Frame coding shall be in accordance with ISO/IEC 13818-2 and ITU Recommendation H.262 and with
the method described in GEM 1.0:2005, subclause 7.1.2.
11.2.1.2
MPEG-4 I-VOP
MPEG-4 I-VOP coding shall be in accordance with ISO/IEC 14496-2.
The payload of a file containing a MPEG-4 I-VOP frame shall have one coded picture as frame I between
visual_object_sequence_start_code and visual_object_sequence_end_code.
11.2.1.3
H.264|MPEG-4 AVC I-picture
H.264|MPEG-4 AVC I-picture coding shall be in accordance with ITU Recommendation H.264 and ISO/IEC 14496-10.
© ABNT 2007 – All rights reserved
19
ABNT NBR 15606-1:2007
11.2.2 JPEG
JPEG coding shall be in accordance with ISO/IEC 10918-1.
11.2.3 PNG
PNG coding shall be in accordance with W3C Recommended PNG and methods described in ARIB STD-24:2007,
volume 1, part 2, subclause 5.3 in GEM 1.0:2005, clause 15. The PNG constraints shall be in accordance with
ARIB STD-B24:2007, volume 1, part 2, subclause 5.3 and in GEM 1.0:2005, clause 15.
11.2.4 MNG
MNG (multiple-image network graphics) coding shall be in accordance with MNG and with the methods described
in ARIB STD-B24:2007, volume 1, part 2, subclause 5.4.
The MNG constraints shall be in accordance with ARIB STD-B24:2007, volume 1, part 2, subclause 5.3.
11.2.5 MPEG-2 video “drips”
MPEG-2 video “drips” is a graphic animation format which uses I-frames and P-frames of MPEG-2 coding.
MPEG-2 video “drips” graphic animation format shall be in accordance with GEM 1.0:2005, clause 15.
11.2.6 GIF
GIF is a coding format for bit maps specified in W3C Recommendation GIF 89a.
Bits maping coding by GIF shall be in accordance with the method described in GEM 1.0:2005, clause 15.
11.2.7 MPEG-4 video clips
Video clips coding in MPEG-4 format used in the graphic layer shall be in accordance with ISO/IEC 14496-2.
11.2.8 H.264|MPEG-4 AVC clips
Video clips coding in H.264 | MPEG-4 format used in the graphic layer shall be in accordance with
ITU Recommendation H.264 and ISO/IEC 14496-10.
11.3 Audio coding
11.3.1 MPEG-2 audio
MPEG-2 audio coding shall be in accordance with the AAC method LC and BC profile specified in ISO/IEC 13818-7
and shall be according to the method described in ARIB STD-B24:2007, volume 1, part 2, subclause 6.1.
11.3.2 PCM (AIFF)
PCM (AIFF) audio coding shall be in accordance with the method described in ARIB STD-B24:2007, volume 1, part 2,
subclause 6.2.
11.3.3 MPEG-4 audio
MPEG-4 audio coding shall be in accordance with the method described in ISO/IEC 14496-3 and
ABNT NBR 15602-2.
20
© ABNT 2007 – All rights reserved
ABNT NBR 15606-1:2007
11.3.4 Coding of synthesized sound
For coding of synthesized sound, a method specified in transmission standard related to television data multiplex
broadcasting (ARIB STD-B5) shall be used.
The coding of synthesized sound shall be in accordance with ARIB STD-B24:2007, volume 1, subclause 6.4.
11.3.5 Monomedia format for audio clips (GEM)
Monomedia formats for audio clips using MPEG-1 (layers 1 and 2) defined in ISO/11172-3 shall be in accordance
with of MHP 1.0:2003, subclause 15.
11.3.6 MPEG-1 audio layer 3 (MP3)
MPEG-1 Layer 3 audio coding shall be in accordance with the method described in ISO/IEC 11172-3 and
ISO/IEC 13818-3.
11.3.7 Audio AC3
AC3 audio coding shall be in accordance with the method described in ATSC A52B.
11.4 Character coding
11.4.1 8 bits character coding
8 bits characters coding shall be in accordance with ARIB STD-B5 and shall be meet the method described in ARIB
STD-B24:2007, volume 1, part 2, subclause 7.1, with the adaptations related to the Latin characters inclusion,
shown below.
Coding structure used specified in SBTVD shall be in accordance with the method described in ARIB STDB24:2007, volume 1, part 2, subclause 7.1.1.1 with the following changes:
a)
inclusion of “latin extension” characters set to the Gp characters code. The Table 8 shows “latin extension"
codes, and inclusion of special characters set Table 9 to the Gp characters code;
b)
GL page initial state change to “alphanumeric” and GR page initial state change to “latin extension”, as shown
in Figure 6; They can not be used the methods of invocation and heading in the Brazilian system of
dissemination;
c)
classification of code set and final byte in accordance with Table 10;
d)
inclusion of the entire graph of Latin characters (latin extension) and special characters in accordance with the
Table 10.
NOTE 1
Table 8 was adapted from the ISO / IEC 8859-15:1999.
NOTE 2
A Table 10 presents the words changed in Table 7-3 of the ARIB STD-B24: 2007 to SBTVD.
© ABNT 2007 – All rights reserved
21
ABNT NBR 15606-1:2007
Table 8 — Latin characters set (latin extension)
x0
x1
x2
x3
x4
x5
x6
x7
x8
x9
xA
xB
xC
xD
xE
xF
0x
NUL
1x
2x
SP
!
"
#
$
%
PAPF &
BEL
'
APB CAN
(
APF SS2
)
3x
0
1
2
3
4
5
6
7
8
9
4x
@
A
B
C
D
E
F
G
H
I
5x
P
Q
R
S
T
U
V
W
X
Y
6x
`
a
b
c
d
e
f
g
h
i
＊
:
;
<
=
>
?
J
K
L
M
N
O
Z
[
\
]
^
j
k
l
m
n
o
APD
APU ESC
CS APS
APR SS3
LS1 RS
LSO US
+
,
.
/
7x
p
q
r
s
t
u
v
w
x
y
8x
9x
Ax Bx
BKF
COL
10/0 °
RDF
FLC
¡
±
GRF
CDC
¢
²
YLF
POL
£
³
BLF WMM
€
Ž
MGF MACRO ¥
μ
CNF
Š
¶
WHF
HLC
§
·
SSZ
RPC
š
ž
MSZ
SPL
©
¹
z
NSZ
{
SZX
|
}
~
DEL
STL
CSI
TIME
ª
«
¬
ÿ
®
¯
º
»
Œ
œ
Ÿ
¿
Cx
À
Á
Â
Ã
Ä
Å
Æ
Ç
È
É
Dx
Ð
Ñ
Ò
Ó
Ô
Õ
Ö
×
Ø
Ù
Ex
à
á
â
ã
ä
å
æ
ç
è
é
Fx
õ
ñ
ò
ó
ô
õ
ö
÷
ø
ù
Ê
Ë
Ì
Í
Î
Ï
Ú
Û
Ü
Ý
Þ
ß
ê
ë
ì
í
î
ï
ú
û
ü
ý
þ
15/15
Table 9 — Special Characters set as G3
0x
2x
3x
4x
♪
¤
¦
…
█
¨
‘
x3
´
’
x4
¸
“
x5
¼
”
x6
½
•
x7
x8
x9
xA
xB
xC
xD
xE
xF
¾
™
⅛
⅜
⅝
⅞
x0
x1
x2
22
1x
5x
6x
7x
© ABNT 2007 – All rights reserved
ABNT NBR 15606-1:2007
b3
0
0
0
0
1
1
1
1
0
0
0
0
1
1
1
1
b2
0
0
1
1
0
0
1
1
0
0
1
1
0
0
1
1
b1
0
0
0
0
0
1
0
1
0
1
0
1
0
1
0
1
x0
x1
x2
x3
x4
x5
x6
x7
x8
x9
xA
xB
xC
xD
xE
xF
0
0
0
0
0
0
1
0
0
0
1
0
0
1
0
0
0
1
0
1
0
1
1
0
0
1
1
1
1
0
0
0
0x 1x 2x
SP
3x
4x
5x
6x
7x
8x 9x
GL area
(Standard
Alphanumeric
Gp.)
1
0
0
1
C1 Area
b3
0
0
0
0
0
0
0
0
1
1
1
1
1
1
1
1
0
0
0
0
C0 Area
b8
b7
b6
b5
1
0
1
0
1
0
1
1
1
1
0
0
1
1
0
1
1
1
1
0
1
1
1
1
Ax
10/0
Bx
Cx
Dx
Ex
Fx
GR area
(Default
latin extension
Gp.)
DEL
15/15
Figure 6 — 8-bit code structure
Table 10 — Classification of code set and final byte
Classification
Graphic set
Kanji
c
Alphanumeric
G set
a
Latin extension
b
Special character
b
Final byte (F)
Remarks
04/02
2-byte code
04/10
1-byte code
04/11
1-byte code
04/12
1-byte code
Hiragana
c
03/0
1-byte code
Katakana
c
03/1
1-byte code
a
Set in use by the system.
b
Set added and in use by the system.
c
Sets not used by the system.
11.4.2 Universal multi-octet coded character set (UCS)
11.4.2.1
Character coding UCS
Character coding using the Universal multi-octet coded character set (UCS) shall be in accordance with
ISO/IEC 10646-1, ISO 8859-15, GEM 1.0:2005, subclause 7.1.5, MHP1.0:2003, subclause 11.2.11 and ARIB
STD-B23:2007, part 1, subclause 5.2.
© ABNT 2007 – All rights reserved
23
ABNT NBR 15606-1:2007
11.4.2.2
Resident fonts
The resident fonts shall include the font selection described in MHP1.0:2003, subclause 7.3.
11.4.2.3
Downloadable fonts
Shal be used the method described in MHP1.0:2003, subclause 7.4.
11.4.3 Shift-JIS coding
Shift-JIS characters coding shall be in accordance with the method described in ARIB STD-B24:2007, volume 1,
part 2, subclause 7.3.
11.4.4 EUC-JP
EUC-JP characters coding shall be in accordance with the method described in ARIB-B24:2007, volume 2,
subclause 4.1.
11.5 Geometric description of commands coding
Description of geometric commands for graphic coding shall be in accordance with ARIB STD-B5 and with the
method described in ARIB STD-B24:2007, volume 1, subclause 8.1.
11.6 Subtitles and superimposed characters
Subtitles and superimposed characters coding shall be in accordance with the method described in
ARIB STD-B24:2007, volume 1, part 3, with the following change:
⎯ changing of the system’s initial state (shown in Table 8-2, part 3, volume 1 of ARIB STD-B24:2007) according
to values shown in Table 11;
⎯ usage of G0 and G2 is as initial state;
⎯ G3 is used by means of SS3 (0x1D). SS3 means to invoke one G3 code following to it in the GL area
temporary.
Table 11 — Initial State
Item
Initial state
Designation
G0 Alphanumeric set
G1 Alphanumeric set
Invocation and
designation of
code
G2 Latin Extension set
Character
coding
G3 Special character set
Invocation
GL LS0 (G0)
GR LS2R (G2)
State
24
Character
coding
Character size
½ x 1 (middle size) (= MSZ)
© ABNT 2007 – All rights reserved
NORMA
BRASILEÑA
ABNT NBR
15606-2
Primera edición
30.11.2007
Válida a partir de
01.12.2007
Versión Corregida
19.11.2009
Televisión digital terrestre — Codificación de
datos y especificaciones de transmisión para
radiodifusión digital
Parte 2: Ginga-NCL para receptores fijos y
móviles – Lenguaje de aplicación XML para
codificación de aplicacione
Palabras clave: Televisión digital terrestre. Middleware. Ginga. NCL. Receptores
móviles y fijos. Perfil full-seg.
ICS 33.160.01
ISBN 978-85-07-00916-0
Número de referencia
ABNT NBR 15606-2:2007
294 páginas
© ABNT 2007
ABNT NBR 15606-2:2007
© ABNT 2007
Todos los derechos reservados. A menos que se especifique de otro modo, ninguna parte de esta publicación puede ser
reproducida o utilizada por cualquier medio, electrónico o mecánico, incluyendo fotocopia y microfilm, sin permiso por escrito de
la ABNT.
ABNT
Av.Treze de Maio, 13 - 28º andar
20031-901 - Rio de Janeiro - RJ
Tel.: + 55 21 3974-2300
Fax: + 55 21 2220-1762
abnt@abnt.org.br
www.abnt.org.br
Impreso en Brasil
ii
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
Índice
Página
Prefacio......................................................................................................................................................................vii
Introducción .............................................................................................................................................................viii
1
Alcance ...........................................................................................................................................................1
2
Referencias normativas ................................................................................................................................1
3
Términos y definiciones................................................................................................................................2
4
Abreviaturas...................................................................................................................................................8
5
5.1
5.2
Arquitectura Ginga ........................................................................................................................................8
Ginga main modules .....................................................................................................................................8
Interacción con el ambiente nativo..............................................................................................................9
6
6.1
6.2
6.3
6.3.1
6.3.2
6.3.3
6.3.4
Interoperabilidad con ambientes declarativos definidos en otros sistemas de televisión digital Objetos XHTML incorporados en presentaciones NCL...........................................................................10
NCL como lenguaje cola .............................................................................................................................10
Formato de contenido XHTML ...................................................................................................................11
Armonización del formato de contenido XHTML .....................................................................................12
Marcaciones XML ........................................................................................................................................12
Hojas de estilo .............................................................................................................................................17
ECMAScript ..................................................................................................................................................22
API DOM .......................................................................................................................................................26
7
7.1
7.1.1
7.1.2
7.1.3
7.2
7.2.1
7.2.2
7.2.3
7.2.4
7.2.5
7.2.6
7.2.7
7.2.8
7.2.9
7.2.10
7.2.11
7.2.12
7.2.13
7.2.14
7.2.15
7.3
7.3.1
7.3.2
7.3.3
7.3.4
7.3.5
NCL - Lenguaje declarativo XML para especificación de presentaciones multimedia interactivas ...28
Lenguajes modulares y perfiles de lenguajes..........................................................................................28
Módulos NCL................................................................................................................................................28
Identificadores para módulos y perfiles de lenguaje de la NCL 3.0.......................................................30
Informaciones sobre versiones de la NCL................................................................................................32
Módulos NCL................................................................................................................................................32
Observaciones generales ...........................................................................................................................32
Área funcional Structure.............................................................................................................................33
Área funcional Layout .................................................................................................................................33
Área funcional Components.......................................................................................................................35
Área funcional Interfaces............................................................................................................................42
Área funcional Presentation Specification ...............................................................................................45
Área funcional Linking ................................................................................................................................47
Area funcional Connectors.........................................................................................................................48
Área funcional Presentation Control .........................................................................................................55
Área funcional Timing .................................................................................................................................57
Área funcional Reuse ..................................................................................................................................57
Área funcional Navigational Key................................................................................................................60
Área funcional Animation ...........................................................................................................................61
Área funcional SMIL Transition Effects.....................................................................................................61
Área funcional Metainformation.................................................................................................................64
Perfiles del lenguaje NCL para el SBTVD..................................................................................................64
Módulos de perfiles .....................................................................................................................................64
Esquema del perfil NCL 3.0 DTV avanzado...............................................................................................65
Esquema del perfil NCL 3.0 CausalConnector .........................................................................................74
Atributos y elementos del perfil NCL 3.0 DTV básico..............................................................................76
Esquema del perfil NCL 3.0 DTV Básico ...................................................................................................81
8
8.1
8.2
8.2.1
Objetos de media en presentaciones NCL................................................................................................89
Implementación modular de Ginga-NCL ...................................................................................................89
Comportamiento esperado de los exhibidores de media .......................................................................90
Instrucción start para eventos de presentación ......................................................................................90
© ABNT 2007 - Todos los derechos reservados
iii
ABNT NBR 15606-2:2007
8.2.2
8.2.3
8.2.4
8.2.5
8.2.6
8.2.7
8.2.8
8.2.9
8.3
8.5
Instrucción stop...........................................................................................................................................91
Instrucción abort .........................................................................................................................................92
Instrucción pause ........................................................................................................................................92
Instrucción resume......................................................................................................................................92
Instrucción start para eventos de atribución ...........................................................................................93
Instrucción addEvent ..................................................................................................................................93
Instrucción removeEvent............................................................................................................................93
Finalización natural de una presentación .................................................................................................93
Comportamiento esperado de los exhibidores de media después de instrucciones aplicadas a los
objetos de composición..............................................................................................................................94
Eslabones refiriendo nudos de composición...........................................................................................94
Empezando la presentación de un contexto ............................................................................................94
Parando la presentación de un contexto ..................................................................................................94
Abortando la presentación de un contexto ..............................................................................................94
Pausando la presentación de un contexto ...............................................................................................94
Retomando la presentación de un contexto.............................................................................................95
Relación entre las máquinas de estado de eventos de presentación de un nudo y la máquina de
estado del evento de presentación de su nudo de composición padre................................................95
Comportamiento esperado de los exhibidores procedurales en aplicaciones NCL ............................95
9
9.1
9.2
Transmisión de contenido y eventos NCL................................................................................................97
Bases privadas ............................................................................................................................................97
Esquema XML de los parámetros de comando......................................................................................104
10
10.1
10.2
10.3
10.3.1
10.3.2
10.3.3
10.3.4
10.3.5
10.4
10.4.1
10.4.2
10.4.3
10.4.4
10.4.5
10.4.6
10.4.7
Objetos procedurales Lua en presentaciones NCL ...............................................................................114
Lenguaje Lua - Funciones retiradas de la biblioteca de Lua ................................................................114
Modelo de ejecución .................................................................................................................................115
Módulos adicionales .................................................................................................................................115
Módulos obligatorios ................................................................................................................................115
Módulo canvas...........................................................................................................................................115
Módulo event..............................................................................................................................................126
Módulo settings .........................................................................................................................................139
Módulo persistent......................................................................................................................................139
Lua-API para Ginga-J ................................................................................................................................140
Mapeo..........................................................................................................................................................140
Paquetes.....................................................................................................................................................140
Tipos básicos.............................................................................................................................................140
Clases .........................................................................................................................................................141
Objetos........................................................................................................................................................141
Objetos de callback (observadores)........................................................................................................141
Excepciones...............................................................................................................................................141
11
11.1
11.2
11.3
Puente .........................................................................................................................................................141
Revisión ......................................................................................................................................................141
Puente a través de los elementos NCL <link> y <media> .....................................................................142
Puente a través de las funciones Lua y métodos del Ginga-J .............................................................142
12
12.1
12.2
Requisitos de codificación de media y métodos de transmisión referidos en documentos NCL....143
Uso del canal de interactividad................................................................................................................143
Métodos de codificación y transmisión de video – Datos de video referidos en elementos <media>
.....................................................................................................................................................................143
Transmisión de video MPEG-1.................................................................................................................143
Transmisión de video MPEG-2.................................................................................................................143
Transmisión de video MPEG-4 y H.264|MPEG-4 AVC............................................................................144
Métodos de codificación y transmisión de audio – datos de audio referidos en elementos <media>
.....................................................................................................................................................................144
Transmisión de audio MPEG-1.................................................................................................................144
Transmisión de audio MPEG-2.................................................................................................................144
Transmisión de audio MPEG-4.................................................................................................................145
Transmisión de audio AC3 .......................................................................................................................145
Transmisión de audio PCM (AIFF-C) .......................................................................................................145
Formato TS para transmisión de video/audio MPEG – Especificación de la codificación de datos 146
Transmisión de video y audio multiplexados.........................................................................................146
8.3.1
8.3.2
8.3.3
8.3.4
8.3.5
8.3.6
8.4
12.2.1
12.2.2
12.2.3
12.3
12.3.1
12.3.2
12.3.3
12.3.4
12.3.5
12.4
12.4.1
iv
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
12.4.2
12.4.3
12.4.4
12.5
12.7.2
12.7.3
PSI requerido .............................................................................................................................................146
Transmisión en secciones MPEG-2.........................................................................................................146
Restricciones en la reproducción............................................................................................................146
Esquema de codificación y transmisión de imágenes estáticas y gráficos de bitmap referidos por
elementos <media> ...................................................................................................................................146
Transmisión de MPEG-2 I-frame, MPEG-4 I-VOP y H.264|MPEG-4 AVC I-picture ...............................146
Transmisión de imagen estática JPEG ...................................................................................................147
Esquema de codificación y transmisión del bitmap PNG .....................................................................147
Esquema de codificación y transmisión de la animación MNG ...........................................................147
Esquema de codificación y transmisión de datos y animación de gráficos GIF................................147
Codificación y transmisión de caracteres - archivos de texto externos referidos por elementos
<media> ......................................................................................................................................................147
Transmisión de documentos XML ...........................................................................................................148
Transmisión de documentos NCL y otros documentos XML que se utilizan en los comandos de
edición ........................................................................................................................................................148
Transmisión en Secciones MPEG-2 ........................................................................................................148
Transmisión de documentos XML externos ...........................................................................................156
13
Seguridad ...................................................................................................................................................156
12.5.1
12.5.2
12.5.3
12.5.4
12.5.5
12.6
12.7
12.7.1
Anexo A (normativo) Esquemas de los módulos NCL 3.0 que se utilizan en los perfiles TVD Básico y TVD
Avanzado....................................................................................................................................................157
A.1
Módulo Structure: NCL30Structure.xsd..................................................................................................157
A.2
Módulo Layout: NCL30Layout.xsd ..........................................................................................................158
A.3
Módulo Media: NCL30Media.xsd..............................................................................................................159
A.4
Módulo Context: NCL30Context.xsd .......................................................................................................160
A.5
Módulo MediaContentAnchor: NCL30MediaContentAnchor.xsd .........................................................161
A.6
Módulo CompositeNodeInterface: NC30CompositeNodeInterface.xsd...............................................162
A.7
Módulo PropertyAnchor: NCL30PropertyAnchor.xsd ...........................................................................163
A.8
Módulo SwitchInterface: NCL30SwitchInterface.xsd.............................................................................164
A.9
Módulo Descriptor: NCL30Descriptor.xsd ..............................................................................................165
A.10 Módulo Linking: NCL30Linking.xsd ........................................................................................................166
A.11 Módulo ConnectorCommonPart: NCL30ConnectorCommonPart.xsd ................................................167
A.12 Módulo ConnectorAssessmentExpression: ...........................................................................................168
NCL30ConnectorAssessmentExpression.xsd ....................................................................................................168
A.13 Módulo ConnectorCausalExpression: NCL30ConnectorCausalExpression.xsd ...............................170
A.14 Módulo CausalConnector: NCL30CausalConnector.xsd ......................................................................172
A.15 Módulo ConnectorBase: NCL30ConnectorBase.xsd.............................................................................173
A.16 NCL30CausalConnectorFunctionality.xsd..............................................................................................174
A.17 Módulo TestRule: NCL30TestRule.xsd....................................................................................................176
A.18 Módulo TestRuleUse: NCL30TestRuleUse.xsd ......................................................................................177
A.19 Módulo ContentControl: NCL30ContentControl.xsd .............................................................................178
A.20 Módulo DescriptorControl: NCL30DescriptorControl.xsd ....................................................................179
A.21 Módulo Timing: NCL30Timing.xsd ..........................................................................................................180
A.22 Módulo Import: NCL30Import.xsd............................................................................................................181
A.23 Módulo EntityReuse: NCL30EntityReuse.xsd ........................................................................................182
A.24 Módulo ExtendedEntityReuse: NCL30ExtendedEntityReuse.xsd........................................................183
A.25 Módulo KeyNavigation: NCL30KeyNavigation.xsd................................................................................184
A.26 Módulo TransitionBase: NCL30TransitionBase.xsd..............................................................................185
A.27 Módulo Animation: NCL30Animation.xsd...............................................................................................186
A.28 Transition module: NCL30Transition.xsd....................................................................................................186
A.29 Metainformation module: NCL30Metainformation.xsd ..............................................................................190
Anexo B (informativo) Manual de referencia de Lua 5.1 .....................................................................................192
B.1
Introducción ...............................................................................................................................................192
B.2
El Lenguaje.................................................................................................................................................192
B.2.1 Notación utilizada ......................................................................................................................................192
B.2.2 Convenciones léxicas ...............................................................................................................................192
B.2.3 Valores y tipos ...........................................................................................................................................194
B.2.4 Variables.....................................................................................................................................................195
B.2.5 Comandos ..................................................................................................................................................196
© ABNT 2007 - Todos los derechos reservados
v
ABNT NBR 15606-2:2007
B.2.6
B.2.7
B.2.8
B.2.9
B.2.10
B.2.11
B.2.12
B.3
B.3.1
B.3.2
B.3.3
B.3.4
B.3.5
B.3.6
B.3.7
B.3.8
B.3.9
B.4
B.4.1
B.4.2
B.5
B.5.1
B.5.2
B.5.3
B.5.4
B.5.5
B.5.6
B.5.7
B.5.8
B.5.9
B.5.10
B.5.11
B.6
B.7
B.7.1
B.7.2
B.7.3
B.8
Expresiones ...............................................................................................................................................200
Reglas de visibilidad .................................................................................................................................207
Tratamiento de errores..............................................................................................................................207
Metatablas ..................................................................................................................................................207
Ambientes ..................................................................................................................................................213
Recolecta de basura..................................................................................................................................213
Co-rutinas...................................................................................................................................................214
Interfaz de programación de la aplicación (API) ....................................................................................216
Conceptos básicos....................................................................................................................................216
Pila...............................................................................................................................................................216
Tamaño de la pila.......................................................................................................................................216
Pseudo-índices ..........................................................................................................................................217
Cierres C.....................................................................................................................................................217
Registro ......................................................................................................................................................217
Tratamiento de errores en C.....................................................................................................................217
Funciones y tipos ......................................................................................................................................218
Interfaz de depuración ..............................................................................................................................236
Biblioteca auxiliar ......................................................................................................................................240
Conceptos básicos....................................................................................................................................240
Funciones y tipos ......................................................................................................................................240
Bibliotecas estándar..................................................................................................................................250
Visión general ............................................................................................................................................250
Funciones básicas.....................................................................................................................................251
Manipulación de co-rutinas ......................................................................................................................256
Módulos ......................................................................................................................................................256
Manejo de cadenas de caracteres ...........................................................................................................259
Estándares .................................................................................................................................................262
Manejo de tablas........................................................................................................................................264
Funciones matemáticas ............................................................................................................................265
Facilidades de entrada y salida................................................................................................................267
Facilidades del sistema operativo ...........................................................................................................271
Biblioteca de depuración ..........................................................................................................................273
El interpretador Lua autónomo ................................................................................................................275
Incompatibilidades con la versión 5.0.....................................................................................................277
Cambios en el lenguaje.............................................................................................................................277
Cambios en las bibliotecas ......................................................................................................................277
Cambios en la API .....................................................................................................................................278
Sintaxis completa de Lua..........................................................................................................................278
Anexo C (informativo) Base de conectores ..........................................................................................................280
Bibliografía ..............................................................................................................................................................294
vi
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
Prefacio
La Associação Brasileira de Normas Técnicas (ABNT) es el Fórum Nacional de Normalización. Las Normas
Brasileñas, cuyo contenido es responsabilidad de los Comités Brasileños (ABNT/CB), de los Organismos de
Normalización Sectorial (ABNT/ONS) y de las Comisiones de Estudios Especiales (ABNT/CEE), son elaboradas
por Comisiones de Estudio (CE), formadas por representantes de sus sectores implicados de los que forman
parte: productores, consumidores y neutrales (universidades, laboratorios y otros).
Los Documentos Técnicos ABNT se elaboran de acuerdo con las reglas de Directivas ABNT, Parte 2.
La Associação Brasileira de Normas Técnicas (ABNT) llama la atención sobre la posibilidad de que algunos de los
elementos de este documento pueden ser objeto de derechos de patente. La ABNT no debe ser considerada
responsable por la identificación de cualesquiera derechos de patente.
La ABNT NBR 15606-2 fue elaborada por la Comisión de Estudio Especial de Televisión Digital
(ABNT/CEE-00:001.85). El Proyecto circuló en Consulta Nacional según Edicto nº 09, de 06.09.2007 a 05.11.2007,
con el número de Proyecto 00:001.85-006/2.
En caso que surja cualquier duda con relación a la interpretación de la versión en español siempre deben
prevalecer las prescripciones de la versión en portugués
Esta Norma está basada en los trabajos del Fórum del Sistema Brasileiro de Televisão Digital Terrestre, según
establece el Decreto Presidencial nº 5.820, de 29/06/2006.
La ABNT NBR 15606, bajo el título general “Televisión digital terrestre – Codificación de datos y especificaciones
de transmisión para radiodifusión digital”, está previsto que contenga las siguientes partes:
 Parte 1: Codificación de datos;
 Parte 2: Ginga-NCL para receptores fijos y móviles – Lenguaje de aplicación XML para codificación de
aplicaciones;
 Parte 3: Especificación de transmisión de datos;
 Parte 4: Ginga-J – Ambiente para la ejecución de aplicaciones procedurales;
 Parte 5: Ginga-NCL para receptores portátiles – Lenguaje de aplicación XML para codificación de aplicaciones
Esta versión en español es equivalente a la versión corregida 3 de la ABNT NBR 15606-2:2007, de 17.04.2009.
Esta versión corregida de la ABNT NBR 15606-2:2007 incorpora la Errata 1 de 19.11.2009.
© ABNT 2007 - Todos los derechos reservados
vii
ABNT NBR 15606-2:2007
Introducción
La Associação Brasileira de Normas Técnicas (ABNT) llama la atención sobre el hecho de que la exigencia de
conformidad con este documento ABNT puede involucrar el uso de una patente relativa a NCL, conforme se
menciona en 5.1.
La ABNT no se posiciona respecto a evidencias, validez y alcance de ese derecho de patente.
El propietario de este derecho de patente aseguró a la ABNT que él está preparado para negociar licencias sobre
términos y condiciones razonables y no discriminatorias con los solicitantes. Sobre esto, hay una declaración del
propietario de esta patente registrada con la ABNT. Informaciones pueden obtenerse con:
Pontifícia Universidade Católica do Rio de Janeiro, Departamento de Transferência de Tecnologia
Rua Marquês de São Vicente, 225 – Gávea, 22451-900 - Rio de Janeiro - RJ - Brasil.
La ABNT quiere resaltar la posibilidad de que algunos de los elementos de este documento ABNT pueden ser
objeto de otros derechos de patente además de los identificados arriba. La ABNT no debe ser considerada
responsable por la identificación de cualesquiera derechos de patente.
Esta Norma estandariza un lenguaje de aplicación XML que permite a los autores escribir presentaciones
multimedia interactivas. Este componente de la ABNT NBR 15606 forma parte de las especificaciones de
codificación de datos para el Sistema Brasileño de Televisión Digital Terrestre (SBTVD) y comprende la
especificación del lenguaje utilizado por la máquina de presentación Ginga-NCL del middleware SBTVD, llamado
Ginga.
A través de este lenguaje, denominado NCL (Nested Context Language – Lenguaje de Contextos Anidados), un
autor puede describir el comportamiento temporal de una presentación multimedia, asociar hyperlinks (interacción
del usuario) a objetos de media, definir alternativas para presentación (adaptación) y describir el formato de la
presentación en múltiples dispositivos.
Esta Norma está primordialmente destinada a las entidades que están especificando terminales y/o estándares
basados en el Ginga. También está destinada a los desarrolladores de aplicaciones que usan las funcionalidades
del Ginga y de sus API. El middleware Ginga tiene como objetivo garantizar la interoperabilidad de las aplicaciones
en diferentes implementaciones de plataformas que lo soportan.
Las aplicaciones Ginga están clasificadas en dos categorías, dependiendo de si la aplicación inicialmente
procesada tiene contenido de naturaleza declarativa o imperativa. Estas categorías de aplicaciones son llamadas
aplicaciones declarativas y aplicaciones procedurales, respectivamente. Los ambientes de aplicación son
igualmente clasificados en dos categorías, dependiendo de si procesan aplicaciones declarativas o procedurales,
siendo entonces llamados Ginga-NCL y Ginga-J, respectivamente.
Es importante observar que a una implementación únicamente Ginga-NCL o únicamente Ginga-J, ya sea en
receptores fijos o móviles, les está prohibida la reivindicación de cualquier tipo de conformidad con el SBTVD.
Esto garantiza que el Ginga ofrezca perfiles siempre compatibles con versiones anteriores.
Esta Norma no especifica la forma cómo los ambientes de aplicación deben implementarse en un receptor en
conformidad. Un fabricante de receptores puede implementar los dos ambientes como un único subsistema;
alternativamente, los ambientes pueden implementarse como subsistemas distintos, con interfaces internos bien
definidos entre los ambientes.
viii
© ABNT 2007 - Todos los derechos reservados
NORMA BRASILEÑA
ABNT NBR 15606-2:2007
Televisión digital terrestre — Codificación de datos y especificaciones de
transmisión para radiodifusión digital
Parte 2: Ginga-NCL para receptores fijos y móviles – Lenguaje de aplicación
XML para codificación de aplicaciones
1
Alcance
Esta parte de la ABNT NBR 15606 especifica un lenguaje de aplicación XML denominada NCL (Nested Context
Language), el lenguaje declarativo del middleware Ginga, la codificación y la transmisión de datos para
radiodifusión digital.
2
Referencias normativas
Los documentos indicados a continuación son indispensables para la aplicación de este documento. Para las
referencias fechadas, se aplican solamente las ediciones citadas. Para las referencias sin fecha, se aplican las
ediciones más recientes del documento citado (incluyendo enmiendas).
ABNT NBR 15601, Televisión digital terrestre – Estándar de transmisión
ABNT NBR 15603-2:2007, Televisión digital terrestre – Multiplexación y servicios de información (SI) – Parte 2:
Estructura de datos y definiciones de la información básica de SI
ABNT NBR 15606-1, Televisión digital terrestre – Codificación de datos y especificaciones de transmisión para
radiodifusión digital – Parte 1: Codificación de datos
ABNT NBR 15606-3, Televisión digital terrestre – Codificación de datos y especificaciones de transmisión para
radiodifusión digital – Parte 3: Especificación de transmisión de datos
ISO 639-1, Codes for the representation of names of languages - Part 1: Alpha-2 code
ISO 8859-1, Information technology – 8-bit single-byte coded graphic character sets – Part 1: Latin alphabet N° 1
ISO/IEC 11172-1, Coding of moving pictures and associated audio for digital storage mediaat up to about
1,5 Mbit/s Part 1 - Systems
ISO/IEC 11172-2, Coding of moving pictures and associated audio for digital storage mediaat up to about
1,5 Mbit/s – Part 2: Video
ISO/IEC 11172-3, Coding of moving pictures and associated audio for digital storage mediaat up to about
1,5 Mbit/s – Part 3: Audio
ISO/IEC 13818-1, Information technology – Generic coding of moving pictures and associated audio information –
Part 1: Systems
ISO/IEC 13818-2, Information technology – Generic coding of moving pictures and associated audio information –
Part 2: Video
ISO/IEC 13818-3, Information technology – Generic coding of moving pictures and associated audio information –
Part 3: Audio
© ABNT 2007 - Todos los derechos reservados
1
ABNT NBR 15606-2:2007
ISO/IEC 13818-6, Information technology – Generic coding of moving pictures and associated audio information –
Part 6: Extensions for DSM-CC
ISO/IEC 13818-7, Information technology – Generic coding of moving pictures and associated audio information –
Part 7: Advanced Audio Coding (AAC)
ISO/IEC 14496-3, Information technology – Coding of audio-visual objects – Part 3: Audio
ECMA 262, ECMAScript language specification
3
Términos y definiciones
Para los efectos de esta parte de la ABNT NBR 15606, se aplican los siguientes términos y definiciones.
3.1
ambiente de aplicación
contexto o ambiente de software en el cual se procesa una aplicación
3.2
ambiente de aplicación declarativa
ambiente que soporta el procesamiento de aplicaciones declarativas
NOTA
Un formateador (user agent) NCL es un ejemplo de ambiente de aplicación declarativa.
3.3
ambiente de aplicación procedural
ambiente que soporta el procesamiento de aplicaciones procedurales
3.4
API DON
API que define la estructura lógica de un documento XML y la forma de acceder, o manejar, un documento XML
NOTA
Esta API es una interfaz independiente de plataformas y lenguajes y sigue el Modelo DOM (Document Object Model).
3.5
aplicación
información que expresa un conjunto específico de comportamientos observables
3.6
aplicación declarativa
aplicación que utiliza principalmente, y como punto de partida, información declarativa para expresar su
comportamiento
NOTA
Una instancia de documento NCL es un ejemplo de aplicación declarativa.
3.7
aplicación híbrida
aplicación híbrida declarativa o aplicación híbrida procedural
3.8
aplicación híbrida declarativa
aplicación declarativa que contiene contenido de objeto activo
NOTA
2
Un documento NCL con un Java Xlet embutido es un ejemplo de aplicación híbrida declarativa.
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
3.9
aplicación híbrida procedural
aplicación procedural con contenido declarativo
NOTA
Un Java Xlet que crea y causa la exhibición de una instancia de documento NCL es un ejemplo de aplicación híbrida
procedural.
3.10
aplicación nativa
función intrínseca implementada por una plataforma receptora
NOTA
Una exhibición en closed caption es un ejemplo de aplicación nativa.
3.11
aplicación procedural
aplicación que utiliza principalmente, y como punto de partida, informaciones procedurales para expresar su
comportamiento
NOTA
Un programa en Java es un ejemplo de una aplicación procedural.
3.12
almacenamiento persistente
memoria disponible que puede ser leída o grabada por una aplicación y puede ser mantenida por más tiempo que
el tiempo de vida de la misma aplicación
NOTA
El almacenamiento persistente puede ser volátil o no volátil.
3.13
atributo
parámetro para representar la naturaleza de una propiedad
3.14
atributo de un elemento
propiedad de un elemento XML
3.15
autor
persona que escribe documentos NCL
3.16
canal de interactividad
canal de retorno
mecanismo de comunicación que suministra conexión entre el receptor y un servidor remoto
3.17
carácter
"letra" específica u otro símbolo identificable
EJEMPLO
“A”
3.18
carrusel de datos
método que envía cualquier conjunto de datos en forma cíclica, para que esos datos se puedan obtener, vía
radiodifusión, en un intervalo de tiempo tan largo como sea necesario
[ISO/IEC 13818-6:2001]
3.19
codificación de caracteres
mapeo entre un valor de entrada entero y el carácter textual, representado por ese mapeo
© ABNT 2007 - Todos los derechos reservados
3
ABNT NBR 15606-2:2007
3.20
contenido de objeto activo
tipo de contenido que toma la forma de un programa ejecutable
NOTA
Un Xlet Java compilado es un ejemplo de contenido de objeto activo.
3.21
contenido NCL
conjunto de informaciones que consiste en un documento NCL y en un grupo de datos, incluyendo objetos
(de media o de ejecución), que acompañan el documento NCL
3.22
digital storage media command and control
DSM-CC
método de control que suministra acceso a un archivo o flujo en servicios digitales interactivos
[ISO/IEC 13818-6:2001]
3.23
document type definition
DTD
declaración que describe un tipo de documento XML
3.24
ECMAScript
lenguaje de programación definido en la ECMA 262
3.25
elemento
unidad de estructuración del documento delimitada por tags
NOTA
Un elemento es usualmente delimitado por una tag inicial y una tag final, excepto un elemento vacío que es
delimitado por una tag de elemento vacío.
3.26
elemento property
elemento NCL que define un nombre de propiedad y su valor asociado
3.27
entidad de la aplicación
unidad de información que expresa alguna parte de una aplicación
3.28
evento
ocurrencia en el tiempo que puede ser instantánea o tener duración mensurable
3.29
exhibidor de media
media player
componente identificable de un ambiente de aplicación que descodifica o ejecuta un tipo específico de contenido
3.30
eXtensible HTML
XHTML
versión extendida del HTML como aplicación XML
NOTA
4
En la especificación XHTML, un documento HTML es reconocido como aplicación XML.
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
3.31
herramienta de autoría
herramienta para ayudar a los autores a crear documentos NCL
3.32
fuente
mecanismo que permite la renderización específica de un carácter
EJEMPLO
NOTA
Tiresias, 12 puntos.
En la práctica, un formato de fuente incorpora aspectos de la codificación de un carácter.
3.33
formateador NCL
componente de software responsable por recibir la especificación de un documento NCL y controlar su
presentación, intentando garantizar que las relaciones entre los objetos de media, especificados por el autor, sean
respetados
NOTA
Renderizador (renderer) de documentos, agente del usuario (user agent ) y exhibidor son otros nombres que se
utilizan con el mismo significado del formateador de documentos.
3.34
flujo de transporte
se refiere a la sintaxis del flujo de transporte MPEG-2 para empaquetado y multiplexación de video, audio y
señales de datos en sistemas de radiodifusión digital
3.35
flujo elemental
elementary stream
ES
flujo básico que contiene datos de video, audio, o datos privados
NOTA
Un único flujo elemental se transporta en una secuencia de paquetes PES con un y sólo un identificador (stream_id).
3.36
gestor de aplicaciones
entidad responsable por la administración del ciclo de vida de las aplicaciones y que administra las aplicaciones,
funcionando tanto en la máquina de presentación como en la máquina de ejecución
3.37
identificador de paquete
PID
valor entero único utilizado para asociar los flujos elementales de un programa, tanto en un flujo de transporte
único como en multiprograma
3.38
información de servicio SI
datos que describen programas y servicios
3.39
informaciones específicas del programa
program specific information
PSI
datos normativos necesarios para demultiplexar los flujos de transporte y regenerar los programas
3.40
interfaz de programación de la aplicación
API
bibliotecas de software que ofrecen acceso uniforme a los servicios del sistema
© ABNT 2007 - Todos los derechos reservados
5
ABNT NBR 15606-2:2007
3.41
lenguaje de marcación
formalismo que describe una clase de documentos que emplean marcación para delinear la estructura, apariencia
u otros aspectos del documento
3.42
lenguaje de script
lenguaje utilizado para describir un contenido de objeto activo incorporado en documentos NCL y en documentos
HTML
3.43
localizador
identificador que suministra una referencia a una aplicación o recurso
3.44
máquina de presentación
subsistema en un receptor que analiza y presenta aplicaciones declarativas, con contenidos como audio, video,
gráficos y texto, con base en reglas definidas en la máquina de presentación
NOTA
Una máquina de presentación es responsable por el control del comportamiento de la presentación y por iniciar
otros procesos en respuesta a entradas del usuario y otros eventos.
EJEMPLO
Navegador HTML y formateador NCL.
3.45
máquina de ejecución
subsistema en un receptor que evalúa y ejecuta aplicaciones procedurales, compuestas por instrucciones en
lenguaje de computadora, contenido de medias asociadas y otros datos
NOTA
Una máquina de ejecución se puede implementar con un sistema operativo, compiladores de lenguaje de
computadora, interpretadores e interfaces de programación de aplicaciones (API), que una aplicación procedural puede utilizar
para presentar contenido audiovisual, interactuar con el usuario o ejecutar otras tareas que no sean evidentes al usuario.
EJEMPLO
Ambiente de software JavaTV, utilizando lenguaje de programación Java e interpretador bytecode, API
JavaTV y máquina virtual Java para ejecución del programa.
3.46
método
función asociada a un objeto autorizado para manejar los datos del objeto
3.47
nudo NCL
elemento <media>, <context>, <body> o <switch> de NCL
3.48
normal play time
NPT
coordenada temporal absoluta que representa la posición en un flujo
3.49
objeto de media
colección de pedazos de datos identificados por nombre que puede representar un contenido de media o un
programa escrito en lenguaje específico
3.50
perfil
especificación de una clase de capacidades, ofreciendo diferentes niveles de funcionalidades en un receptor
6
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
3.51
perfil one-seg
caracteriza el servicio que puede ser recibido por un sintonizador de banda estrecha (430 KHz) y por lo tanto con
ahorro en el consumo de batería
NOTA
El perfil one-seg también es conocido como perfil portátil.
3.52
perfil full-seg
caracteriza el servicio que necesita necesariamente un demodulador de banda ancha (5,7 MHz) para ser recibido
NOTA
Dependiendo de las configuraciones de transmisión y de funcionalidad específicas del receptor, puede ser recibido
en movimiento o apenas por receptores fijos, aunque sin el beneficio del ahorro de energía. La resolución del video transmitido
puede ser o no de alta definición.
3.53
plug-in
conjunto de funcionalidades que se puede agregar a una plataforma genérica para suministrar funcionalidad
adicional
3.54
plataforma receptora
plataforma
hardware, sistema operativo y bibliotecas de software nativas del receptor, elegidos por el fabricante
3.55
recurso
objeto de datos o un servicio de la red que es identificado unívocamente
3.56
sistema de archivos local
sistema de archivos suministrado por la plataforma receptora local
3.57
tiempo de vida de una aplicación
período de tiempo entre el momento en que una aplicación se carga y el momento en que se destruye
3.58
uniform resource identifier
URI
método de encaminamiento que permite el acceso a objetos en una red
3.59
user agent
cualquier programa que interpreta un documento NCL
NOTA
Un user agent puede exhibir un documento, intentando garantizar que las relaciones especificadas por el autor
entre objetos de media sean respetadas, pronunciarlo en audio sintetizado, convertirlo en otro formato etc.
3.60
usuario
persona que interactúa con un formateador para visualizar, oír o utilizar de otra forma un documento NCL
3.61
usuario final
individuo que opera o interactúa con un receptor
© ABNT 2007 - Todos los derechos reservados
7
ABNT NBR 15606-2:2007
4
Abreviaturas
Para los efectos de esta parte de la ABNT NBR 15606, se aplican las siguientes abreviaturas.
API
BML
CLUT
CSS
DOM
DSM-CC
DTD
DTV
DVB
GIF
HTML
HTTP
JPEG
MIME
MNG
MPEG
NCL
NCM
NPT
OS
PAT
PES
PID
PMT
PNG
PSI
SBTVD
SMIL
TS
UCS
URI
URL
XHTM
L XML
W3C
5
Application Programming Interface
Broadcast Markup Language
Color Look-up Table
Cascading Style Sheets
Document Object Model
Digital Storage Media Command and Control
Document Type Definition
Digital Television
Digital Video Broadcasting
Graphics Interchange Format
Hypertext Markup Language
Hypertext Transfer Protocol
Joint Photographic Expert Group
Multipurpose Internet Mail Extensions
Multiple Network Graphics
Moving Picture Expert Group
Nested Context Language
Nested Context Model
Normal Play Time
Operating System
Program Association Table
Packetized Elementary Stream
Packet Identifier
Program Map Table
Portable Network Graphics
Program Specific Information
Sistema Brasileño de Televisión Digital Terrestre
Synchronized Multimedia Integration Language
Transport Stream
Universal (Coded) Character Set
Universal Resource Identifier
Universal Resource Locator
eXtensible HTML
Extensible Markup Language
World-Wide Web Consortium
Arquitectura Ginga
5.1 Ginga main modules
El universo de las aplicaciones Ginga se puede dividir en un conjunto de aplicaciones declarativas y un conjunto
de aplicaciones procedurales. Una aplicación declarativa es aquella donde el tipo del contenido de la entidad
inicial es declarativo. Por otro lado, una aplicación procedural es aquella cuyo tipo de contenido de la entidad
inicial es procedural. Una aplicación declarativa pura es aquella en la cual el contenido de todas las entidades es
del tipo declarativo. Una aplicación procedural pura es aquella en la cual el contenido de todas las entidades es
del tipo procedural. Una aplicación híbrida es aquella cuyo conjunto de entidades posee tanto contenido del tipo
declarativo como procedural. Una aplicación Ginga no necesita ser puramente declarativa o procedural.
8
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
En particular, las aplicaciones declarativas frecuentemente utilizan scripts, cuyo contenido es de modalidad
procedural. Además, una aplicación declarativa puede hacer referencia a un código Java TV Xlet incorporado.
Del mismo modo, una aplicación procedural puede hacer referencia a una aplicación declarativa, conteniendo,
por ejemplo, contenido gráfico, o puede construir e iniciar la presentación de aplicaciones con contenido
declarativo. Por lo tanto, ambos tipos de aplicación Ginga pueden utilizar las facilidades de los ambientes de
aplicación declarativo y procedural.
Ginga-NCL es un subsistema lógico del sistema Ginga responsable por el procesamiento de documentos NCL1).
Un componente clave del Ginga-NCL es la máquina de interpretación del contenido declarativo (formateador NCL).
Otros módulos importantes son el exhibidor (user agent) XHTML, que incluye interpretadores CSS y ECMAScript,
y la máquina de presentación Lua, que es responsable por la interpretación de los scripts Lua (ver Anexo B).
Ginga-J es un subsistema lógico del sistema Ginga responsable por el procesamiento de contenidos activos.
Un componente clave del ambiente de aplicación procedural es la máquina de ejecución del contenido procedural,
compuesta por una máquina virtual Java.
Decodificadores de contenidos comunes sirven tanto para las aplicaciones procedurales con respecto a las
declarativas que necesitan decodificar y presentar tipos comunes de contenido como PNG, JPEG, MPEG y otros
formatos. El núcleo común Ginga (Ginga Common Core) está compuesto por los decodificadores de contenido
comunes y por procedimientos para lograr contenidos transportados en flujos de transporte (transport streams)
MPEG-2 y a través del canal de interactividad. El núcleo común Ginga también debe soportar obligatoriamente el
modelo conceptual de exhibición, tal como se describe en la ABNT NBR 15606-1.
La arquitectura (ver Figura 1) y facilidades Ginga fueron proyectadas para ser aplicadas a sistemas de
radiodifusión y receptores terrestres de radiodifusión. Adicionalmente, la misma arquitectura y facilidades se
pueden aplicar a sistemas que utilizan otros mecanismos de transporte de datos (como sistemas de televisión vía
satélite o por cable).
Figura 1 — Arquitectura Ginga
5.2 Interacción con el ambiente nativo
Por lo general, el Ginga es ajeno a cualesquiera aplicaciones nativas que pueden también optar por utilizar el
plano gráfico. Eso incluye, pero no se limita a aplicaciones como: closed caption, mensajes del sistema de acceso
condicional (CA), menús del receptor y guías de programación nativos.
Las aplicaciones nativas pueden tener prioridad sobre las aplicaciones Ginga. El closed caption y los mensajes de
emergencia deben tener obligatoriamente prioridad sobre el sistema Ginga.
Algunas aplicaciones nativas, como el closed caption, representan un caso especial en el cual la aplicación nativa
puede estar activa por largos períodos en conjunto con las aplicaciones Ginga.
1)
NCL es marca registrada y su especificación es propiedad intelectual de la PUC-Rio (INPI Departamento de Transferencia
Tecnológica - No. 0007162-5; 20/12/2005).
© ABNT 2007 - Todos los derechos reservados
9
ABNT NBR 15606-2:2007
6
Interoperabilidad con ambientes declarativos definidos en otros sistemas de
televisión digital - Objetos XHTML incorporados en presentaciones NCL
6.1 NCL como lenguaje cola
Todas las máquinas de presentación de los tres principales sistemas de televisión digital utilizan un lenguaje
basado en XHTML.
XHTML es un lenguaje declarativo basado en media, lo que significa que su estructura es definida por las
relaciones entre objetos XHTML (documentos XHTML u objetos insertos en documentos XHTML) que están
incorporados en el contenido de la media del documento. XHTML puede, entonces, ser clasificada como lenguaje
de marcación: un formalismo que describe una clase de documentos que emplean marcación para delinear la
estructura, apariencia y otros aspectos de los documentos.
Las relaciones de referencia definidos por los enlaces XHTML son el foco de ese lenguaje declarativo. Otros tipos
de relaciones, como relaciones de sincronización espacio-temporal y relaciones alternativas (adaptación de la
media), son comúnmente definidos a través de un lenguaje imperativo (por ejemplo, ECMAScript).
Diferentemente de XHTML o HTML, NCL define una separación bien delimitada entre el contenido y la estructura
de un documento (o aplicativo), probando un control no intrusivo del enlace entre el contenido y su presentación y
layout.
El foco del lenguaje declarativo NCL es más amplio que el ofrecido por la XHTML. La sincronización espaciotemporal, definida genéricamente por los enlaces NCL; adaptabilidad, definida por los elementos switch y
descriptor switch de la NCL; y soporte a múltiples dispositivos de exhibición, definidos por regiones NCL, es el foco
de ese lenguaje declarativo. La interacción del usuario se trata sólo como un caso particular de sincronización
temporal.
Como la NCL tiene una separación más exacta entre el contenido y la estructura, la misma no define ninguna
media en sí. Al contrario, define la cola que pega la media en presentaciones multimedia.
Un documento NCL sólo define cómo los objetos de media son estructurados y relacionados en el tiempo y
espacio. Como un lenguaje de cola, la misma no restringe o prescribe los tipos de contenido de los objetos de
media. En ese sentido, se pueden tener objetos de imagen (GIF, JPEG etc.), de video (MPEG, MOV etc.), de
audio (MP3, WMA etc.), de texto (TXT, PDF etc.), de ejecución (Xlet, Lua etc.), entre otros, como objetos de
media NCL. Qué objetos de media son soportados depende de los exhibidores de media que están acoplados al
formateador NCL (exhibidor NCL). Uno de esos exhibidores es el decodificador/exhibidor MPEG-4, normalmente
implementado en hardware en el receptor de televisión digital. De esa forma, el video y el audio MPEG-4 principal
se tratan como todos los demás objetos de media que pueden estar relacionados utilizando NCL.
Otro objeto de media NCL que debe ser obligatoriamente soportado es el objeto de media basado en XHTML.
La NCL no reemplaza, sino incorpora documentos (u objetos) basados en XHTML. Como ocurre con otros objetos
de media, qué lenguaje basado en XHTML tiene soporte en un formateador NCL es una elección de
implementación y, por lo tanto, depende de qué navegador XHTML, incorporado en el formateador NCL, actúa
como exhibidor de esa media.
Como consecuencia, es posible tener navegadores BML, DVB-HTML y ACAP-X individualmente incorporados
en un exhibidor de documento NCL. Es posible, además, tenerlos todos. Es igualmente posible recibir el código
de un programa navegador a través de la difusión de datos e instalarlo como plug-in (normalmente un plug-in
Java).
También es posible tener un navegador genérico implementado y, en caso de ser necesario, recibir la parte
complementar (específica) como un plug-in, para convertir el exhibidor XHTML genérico en un exhibidor
específico de uno de los diversos estándares de navegador DTV.
10
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
En último caso, un documento NCL puede ser reducido para contener un sólo objeto de media XHTML. En ese
caso, el exhibidor del documento NCL actúa casi como un navegador XHTML, es decir, como cualquier otro
navegador de los estándares mencionados.
No importa el caso, la implementación del navegador XHTML debe ser una consecuencia de las siguientes
exigencias:
 interoperabilidad;
 robustez;
 conformidad con las normas del W3C;
 rechazo de contenido no conforme;
 compatibilidad con el modelo de seguridad Ginga;
 minimización de la redundancia con la tecnología Ginga-J existente;
 minimización de la redundancia con las facilidades NCL existentes;
 mecanismos necesarios de control del layout del contenido;
 soporte a diferentes razones de aspecto de las unidades de exhibición (pixels).
Para brindar soporte a las facilidades del navegador XHTML definidas por otros estándares DTV, se recomienda
que todas las especificaciones SBTVD relacionadas con la difusión de datos soporten también las facilidades
definidas para tales navegadores, como el transporte de eventos de flujos (stream events), por ejemplo.
Aunque un navegador XHTML deba ser obligatoriamente soportado, se recomienda que la utilización de
elementos XHTML para definir relaciones (incluso links XHTML) sea evitada en la autoría de documentos NCL.
Se recomienda que la autoría con base en la estructura sea priorizada por razones conocidas y ampliamente
divulgadas en la literatura.
Durante la exhibición del contenido de objetos de media se generan varios eventos (ver 7.2.8). Algunos ejemplos
son la presentación de parte del contenido de un objeto de media, la selección de parte del contenido de un
objeto etc. Los eventos pueden generar acciones sobre otros objetos de media, como iniciar o terminar sus
presentaciones. Por lo tanto, los eventos deben ser obligatoriamente relatados por los exhibidores de media al
formateador NCL que, a su vez, puede generar acciones a ser aplicadas a ésos u otros exhibidores. Ginga-NCL
define la API (ver Sección 8) de un adaptador con el alcance de estandarizar la interfaz entre el formateador
Ginga-NCL y cada exhibidor específico.
Para que cualquier exhibidor de media, en particular un navegador XHTML, sea acoplado al formateador GingaNCL, debe soportar obligatoriamente la API de los adaptadores. Así, para algunos exhibidores de media, incluso
navegadores XHTML, un módulo adaptador puede ser necesario para alcanzar la integración.
Para edición en vivo, el Ginga-NCL también define eventos de flujo NCL para ofrecer soporte a los eventos
generados en vivo sobre flujos de media, en particular sobre el flujo de video del programa principal. Esos eventos
son una generalización del mismo concepto encontrado en otras normas, como, por ejemplo, los bevents de BML.
Aunque un navegador XHTML deba ser obligatoriamente soportado, se recomienda evitar la utilización
de elementos XHTML para definir relaciones (incluso eventos de flujo) durante la creación de documentos NCL
por la misma razón, es decir, se recomienda que la autoría con base en la estructura sea priorizada por razones
conocidas y ampliamente divulgadas en la literatura.
6.2 Formato de contenido XHTML
Formatos comunes de contenido deben ser obligatoriamente adoptados para la producción e intercambio de
contenido multimedia, como definido en la ABNT NBR 15606-1. Además, en el ambiente de aplicación declarativa
también se exige la especificación de formatos comunes de contenidos XHTML para las aplicaciones de televisión
interactiva.
© ABNT 2007 - Todos los derechos reservados
11
ABNT NBR 15606-2:2007
NOTA
Esta Norma sigue la ITU Recommendation J.201 para identificar las funcionalidades comunes entre los ambientes
de aplicación declarativa para aplicaciones de televisión interactiva especificadas por DVB-HTML, ACAP-X y BML.
Conviene que se especifiquen los elementos comunes y API en el nivel sintáctico de objetos de media XHTML
incorporados en aplicaciones NCL para ayudar a los autores en la creación de contenido XHTML.
Cualquier implementación de objeto de media XHTML de acuerdo con esta Norma debe obligatoriamente dar
soporte a, por lo menos, todas las marcaciones XML y propiedades de hojas de estilo comunes a los servicios
básicos BML ("perfil terminal fijo"), ACAP-X y DVB-HTML, como definido en 6.3. Se recomienda que facilidades
de objetos nativos ECMAScript y API DOM, comunes a los servicios básicos BML ("perfil terminal fijo"), ACAP-X y
DVB-HTML, también tengan soporte.
6.3 Armonización del formato de contenido XHTML
6.3.1
Marcaciones XML
NOTA
Objetos de media NCL basados en XHTML siguen la recomendación W3C “Modularization of XHTML” y sus
marcaciones XML se definen en la ITU Recommendation J.201.
Los módulos comunes a marcaciones XML pueden ser:
 structure;
 text;
 hypertext;
 list;
 presentation;
 bidirectional text;
 forms;
 image;
 client-side image map;
 object;
 frames;
 target;
 meta information;
 scripting;
 stylesheet;
 style attribute;
 link;
 base.
12
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
Las colecciones de atributo XHTML se definen de acuerdo con la Tabla 1. Las marcaciones XML comunes a los
estándares servicios básicos BML (“perfil de terminal fijo”), ACAP-X y DVB-HTML, que deben ser obligatoriamente
soportadas por cualquier implementación, se listan en la Tabla 2, en conjunto con las extensiones
Ginga obligatorias.
Tabla 1 — Colecciones de atributos
Nombre de la
colección
Core
Atributos en la colección
class (NMTOKENS)
Id (ID),
title (CDATA)
I18N
Condición del
atributo
Requerido
Requerido
–
xml:lang (CDATA)
Requerido
onclick (Script)
Requerido
ondblclick (Script)
–
onmousedown (Script)
–
onmouseup (Script)
–
onmouseover (Script)
–
onmousemove (Script)
–
onmouseout (Script)
–
onkeypress (Script)
–
onkeydown (Script)
Requerido
onkeyup (Script)
Requerido
Style
style (CDATA)
Requerido
Common
Core + Events + I18N + Style
Events
© ABNT 2007 - Todos los derechos reservados
13
ABNT NBR 15606-2:2007
Tabla 2 — Elementos de marcación XML en común
Módulo
Elemento
Condición del
elemento
body
Requerido
head
Requerido
html
title
abbr
acronym
address
blockquote
br
cite
code
dfn
div
em
h1
h2
h3
h4
h5
h6
kbd
p
pre
q
samp
span
strong
var
Requerido
Requerido
–
–
–
–
Requerido
–
–
–
Requerido
–
Requerido
Requerido
Requerido
Requerido
Requerido
Requerido
–
Requerido
–
–
–
Requerido
–
–
Structure
Text
Core
14
Hypertext
a
Requerido
List
dl
dt
dd
ol
ul
li
–
–
–
–
–
–
Atributo
Condición del
atributo
%Common.attrib
%Core.attrib
%I18n.attrib
%Events.attrib
%I18n.attrib
profile
Requerido
Requerido
–
Requerido
–
%I18n.attrib
Requerido
%Core.attrib
Requerido
%Common.attrib
Requerido
%Common.attrib
%Common.attrib
%Common.attrib
%Common.attrib
%Common.attrib
%Common.attrib
Requerido
Requerido
Requerido
Requerido
Requerido
Requerido
%Common.attrib
Requerido
%Common .attrib
Requerido
%Common.attrib
accesskey
charset
href
hreflang
rel
rev
tabindex
type
Requerido
Requerido
Requerido
Requerido
–
–
–
–
–
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
Tabla 2 (continuación)
Módulo
Elemento
Applet
applet
param
b
big
hr
i
small
sub
sup
tt
del
ins
Condición del
elemento
–
–
–
–
–
–
–
–
–
–
–
–
bdo
–
form
input
label
select
option
textarea
–
–
–
–
–
–
Presentation
Text extension
Edit
Bi-directional
text
Basic forms
form
Requerido
input
Requerido
select
option
textarea
button
fieldset
label
legend
optgroup
–
–
–
–
–
–
–
–
Forms
Forms
© ABNT 2007 - Todos los derechos reservados
Atributo
Condición del
atributo
%Common.attrib
action
method
enctype
accept-charset
accept
name
%Common.attrib
accesskey
checked
disabled
readonly
maxlength
alt
name
size
src
tabindex
accept
type
value
Requerido
Requerido
Requerido
Requerido
Requerido
Requerido
Requerido
Requerido
Requerido
–
Requerido
Requerido
Requerido
–
–
Requerido
–
–
–
Requerido
Requerido
15
ABNT NBR 15606-2:2007
Tabla 2 (continuación)
Módulo
Elemento
Basic tables
Table
Tables
Image
Client side map
Server side image map
Object
Frames
Target
IFrame
16
caption
table
td
th
tr
caption
table
td
th
tr
col
colgroup
tbody
thead
tfoot
img
a&
area
img&
input&
map
object&
img&
Input&
Condición del
elemento
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
object
Requerido
param
frameset
frame
noframe
a&
area&
base&
link&
form&
iframe
–
–
–
–
–
–
–
–
–
–
Atributo
Condición del
atributo
%Common.attrib
archive
classid
codebase
codetype
data
declare
height
name
standby
tabindex
type
width
Requerido
–
–
–
–
Requerido
–
Requerido
–
–
–
Requerido
Requerido
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
Tabla 2 (continuación)
Módulo
Elemento
Intrinsic events
a&
area&
frameset&
form&
body&
label&
input&
select&
textarea&
button&
Metainformation
meta
Condición del
elemento
Requerido
–
–
–
–
–
–
–
–
–
Requerido
Atributo
Condición del
atributo
%I18n.attrib
http-equiv
name
content
scheme
–
–
Requerido
Requerido
–
charset
type
src
defer
%I1 8n.attrib
id
type
media
title
Requerido
Requerido
–
–
Requerido
–
Requerido
Requerido
–
noscript
Scripting
6.3.2
script
Requerido
Stylesheet
style
Requerido
Style attribute
Link
Base
link
base
Requerido
Requerido
–
Hojas de estilo
Las propiedades de hojas de estilo (CSS) se listan en la Tabla 3.
© ABNT 2007 - Todos los derechos reservados
17
ABNT NBR 15606-2:2007
Tabla 3 — Propiedades de hojas de estilo en común
background
clear
outline-color
background-attachment
clip
outline-style
background-color
color
outline-width
background-image
content
overflow
background-position
counter-increment
padding
background-repeat
counter-reset
padding-bottom
border
display
padding-left
border-bottom
float
padding-right
border-bottom-color
font
padding-top
border-bottom-style
font-family
position
border-bottom-width
font-size
right
border-color
font-style
text-align
border-left
font-variant
text-decoration
border-left-color
font-weight
text-indent
border-left-style
height
text-transform
border-left-width
left
top
border-right
letter-spacing
vertical-align
border-right-color
line-height
visibility
border-right-style
list-style
white-space
border-right-width
list-style-image
width
border-style
list-style-position
word-spacing
border-top
list-style-type
z-index
border-top-color
margin
nav-down
border-top-style
margin-bottom
nav-index
border-top-width
margin-left
nav-left
border-width
margin-right
nav-right
bottom
margin-top
nav-up
caption-side
outline
----
Las propiedades de hojas de estilo comunes a los estándares servicios básicos BML, ACAP-X y DVB-HTML, que
deben ser obligatoriamente soportadas por cualquier implementación, se listan en la Tabla 4.
18
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
Tabla 4 — Propiedades de hojas de estilo CSS 2 en común
Propiedad
Value assignment/Inheritance
@import
!important
Media type
@media
box model
margin-top
margin-right
margin-bottom
margin-left
margin
padding-top
padding-right
padding-bottom
padding-left
padding
border-top-width
border-right-width
border-bottom-width
border-left-width
border-width
border-top-color
border-right-color
border-bottom-color
border-left-color
border-color
border-top-style
border-right-style
border-bottom-style
border-left-style
border-style
border-top
border-right
border-bottom
border-left
border
Visual formatting model
position
left
top
width
height
z-index
line-height
vertical-align
display
bottom
right
float
clear
direction
© ABNT 2007 - Todos los derechos reservados
Condición de la propiedad
–
–
Requerido
–
–
–
–
Requerido
Requerido
Requerido
Requerido
Requerido
Requerido
–
–
–
–
Requerido
–
–
–
–
Requerido
–
–
–
–
Requerido
–
–
–
–
Requerido
Requerido
Requerido
Requerido
Requerido
Requerido
Requerido
Requerido
–
Requerido
–
–
–
–
–
19
ABNT NBR 15606-2:2007
Tabla 4 (continuación)
Propiedad
Condición de la propiedad
unicode-bidi
–
min-width
–
max-width
–
min-height
–
max-height
–
Other visual effects
visibility
Requerido
overflow
Requerido
clip
–
Generated content/Auto numbering/List
content
–
quotes
–
counter-reset
–
counter-increment
–
marker-offset
–
list-style-type
–
list-style-image
–
list-style-position
–
list-style
–
Page media
"@page"
–
size
–
marks
–
page-break-before
–
page-break-after
–
page-break-inside
–
page
–
orphans
–
widows
–
Background
background
–
background-color
–
background-image
Requerido
background-repeat
Requerido
background-position
–
background-attachment
–
Font
color
Requerido
font-family
Requerido
font-style
Requerido
font-size
Requerido
font-variant
Requerido
font-weight
Requerido
font
Requerido
font-stretch
–
font-adjust
–
Text
text-indent
–
text-align
Requerido
text-decoration
–
20
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
Tabla 4 (continuación)
Propiedad
text-shadow
letter-spacing
word-spacing
text-transform
white-space
Pseudo class/ Pseudo element
:link
:visited
:active
:hover
:focus
:lang
:first-child
:first-line
:first-letter
:before
:after
Table
caption-side
border-collapse
border-spacing
table-layout
empty-cells
speak-header
User interface
outline-color
outline-width
outline-style
outline
cursor
Voice style sheet
volume
speak
pause-before
pause-after
pause
cue-before
cue-after
cue
play-during
azimuth
elevation
speech-rate
voice-family
pitch
pitch-range
stress
richness
speak-punctuation
peak-numeral
© ABNT 2007 - Todos los derechos reservados
Condición de la propiedad
–
Requerido
–
–
Requerido
–
–
Requerido
–
Requerido
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
21
ABNT NBR 15606-2:2007
Tabla 4 (continuación)
Propiedad
Extended property
clut
color-index
background-color-index
border-color-index
border-top-color-index
border-right-color-index
border-bottom-color-index
border-left-color-index
outline-color-index
resolution
display-aspect-ratio
grayscale-color-index
nav-index
nav-up
nav-down
nav-left
nav-right
used-key-list
Condición de la propiedad
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
Las siguientes restricciones se deberán aplicar obligatoriamente a las propiedades de exhibición:
 solamente elementos de bloque se pueden aplicar para <p>, <div>, <body>, <input> y <object>;
 solamente valores definidos en el mismo elemento HTML se pueden aplicar para <br>, <a> y <span>.
Además, las siguientes restricciones se deberán aplicar obligatoriamente a las propiedades de posición:

solamente valores absolutos se pueden aplicar para <p>, <div>, <input> y <object>;

solamente valores estáticos se pueden aplicar para <br>, <span> y <a>.
Los selectores CSS comunes a los estándares servicios básicos BML, ACAP-X y DVB-HTML, que deben ser
obligatoriamente soportados por cualquier implementación, son los siguientes:
 universal;
 type;
 class;
 id;
 dynamic (active and :focus).
6.3.3
ECMAScript
Una vez implementada, es altamente recomendable que la máquina ECMAScript dé soporte a los objetos nativos
en común de los estándares de servicios básicos BML, ACAP-X y DVB-HTML, listados en la Tabla 5. Como
restricción, los tipos numéricos sólo soportan operaciones enteras.
22
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
Tabla 5 — Objetos nativos en común
Object
(global)
Method, properties
NaN
Infinity
eval(x)
parseInt(string, radix)
parseFloat(string)
escape(string)
unescape(string)
isNaN(number) O
isFinite(number)
Object
prototype
Object([value])
new Object([value])
Object.prototype
constructor
toString()
valueOf()
Operation condition
Requerido
–
–
Requerido
–
–
–
Requerido
–
Todos requeridos
Requerido
Requerido
Requerido
Todos requeridos
Requerido
Requerido
Requerido
Function
prototype
Length
Function(p1, p2, . . . , pn, body)
new Function(p1, p2, . . . , pn, body)
Function.prototype
constructor
toString()
Array
prototype
Length
Array(item0, item 1, . . .)
new Array(item0, item 1, . . .)
new Array([len])
Array.prototype
constructor
toString()
join([separator])
reverse()
sort([comparefn])
constructor
String
prototype
Length
String([value])
new String([value])
String.fromCharCode(char0[, char1, . . .])
© ABNT 2007 - Todos los derechos reservados
Requerido
Requerido
–
–
Todos requeridos
Requerido
Requerido
Todos requeridos
Requerido
Requerido
Requerido
Requerido
Requerido
Todos requeridos
Requerido
Requerido
Requerido
Requerido
Requerido
Requerido
Todos requeridos
Requerido
Requerido
Requerido
Requerido
Requerido
23
ABNT NBR 15606-2:2007
Tabla 5 (continuación)
Object
Method, properties
String.prototype
constructor
toString()
valueOf()
charAt(pos)
charCodeAt(pos)
indexOf(searchString, position)
lastIndexOf(searchString, position)
split(separator)
substring(start [,end])
toLowerCase()
toUpperCase()
Boolean
prototype
Boolean([value])
new Boolean([value])
Boolean.prototype
constructor
toString()
valueOf()
Number
prototype
MAX_VALUE
MIN_VALUE
NaN
NEGATIVE_INFINITY
POSITIVE_INFINITY
Number([value])
new Number([value])
Number.prototype
constructor
toString([radix])
valueOf()
Math
E
LN10
LN2
LOG2E
LOG10E
PI
SQRT1_2
SQRT2
abs(x)
acos(x)
asin(x)
atan(x)
atan2(y, x)
cos(x)
24
Operation condition
Todos requeridos
Requerido
Requerido
Requerido
Requerido
Requerido
Requerido
Requerido
Requerido
Requerido
Requerido
Requerido
Todos requeridos
Requerido
Requerido
Requerido
Todos requeridos
Requerido
Requerido
Requerido
Requerido
Requerido
Requerido
Requerido
–
–
Requerido
Requerido
Todos requeridos
Requerido
Requerido
Requerido
–
–
–
–
–
–
–
–
–
–
–
–
–
–
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
Tabla 5 (continuación)
Object
Math
Method, properties
exp(x)
floor(x)
log(x)
max(x, y)
min(x, y)
pow(x, y)
random()
round(x)
sin(x)
sqrt(x)
tan(x)
Operation condition
–
–
–
–
–
–
–
–
–
–
–
Date
prototype
Date([year, month [, date [, hours [,
Requerido
Requerido
new Date([year, month [, date [, hours [,
Requerido
Date(value)
new Date(value)
Date.parse(string)
Date.UTC([year [, month [, date [, hours
–
–
–
–
Date.prototype
constructor
toString()
valueOf()
getTime()
getYear())
getFullYear()
getUTCFullYear()
getMonth()
getUTCMonth()
getDate()
getUTCDate()
getDay()
getUTCDay()
getHours()
getUTCHours()
getMinutes()
getUTCMinutes()
getSeconds()
getUTCSeconds()
getMilliseconds()
getUTCMilliseconds()
getTimezoneOffset()
setTime(time)
setMilliseconds(ms)
setUTCMilliseconds(ms)
© ABNT 2007 - Todos los derechos reservados
Requerido
Requerido
–
–
–
Requerido
Requerido
Requerido
Requerido
Requerido
Requerido
Requerido
Requerido
Requerido
Requerido
Requerido
Requerido
Requerido
Requerido
Requerido
Requerido
Requerido
–
Requerido
Requerido
25
ABNT NBR 15606-2:2007
Tabla 5 (continuación)
Object
Date.prototype
Method, properties
setSeconds(sec [, ms ] )
setUTCSeconds(sec [, ms ] )
setMinutes(min [, sec [, ms ] ] )
setUTCMinutes(min [, sec [, ms ] ] )
setHours(hour [, min [, sec [, ms ] ] ] )
setUTCHours(hour [, min [, sec [, ms ] ] ] )
setDate(date)
setMonth(mon [, date ] )
setUTCMonth(mon [, date ])
setFullYear(year [, mon [, date ] ] )
setUTCFullYear(year [, mon [, date ] ] )
setYear(year)
toLocaleString()
toUTCString()
toGMTString()
Operation condition
Requerido
Requerido
Requerido
Requerido
Requerido
Requerido
Requerido
Requerido
Requerido
Requerido
Requerido
–
Requerido
Requerido
–
Dependiendo de la implementación del middleware, es posible tener funciones ECMAScript mapeadas para las
API suministradas por el Ginga-J, logrando acceso a algunos recursos de la plataforma receptora y facilidades
Ginga. En ese caso, se recomienda que la API suministrada en el ECMAScript siga la misma especificación
presentada para el ambiente procedural del Ginga-J.
6.3.4
API DOM
Las API DOM nivel 1 son las siguientes:
 DOM Exception;
 DOMImplementation;
 DocumentFragment;
 Document;
 Node;
 NodeList;
 NamedNodeMap;
 CharacterData;
 Attr;
 Element;
 Text;
 Comment.
Las API DOM nivel 1, cuando son implementadas, es altamente recomendable que sigan las API comunes del
DOM nivel 1 para para servicios básicos BML, ACAP-X y DVB-HTML, listadas en la Tabla 6.
26
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
Tabla 6 — API DOM nivel 1 en común
Interfaz
DOMImplementation
Atributo/Método
Condición de la operación
hasFeature()
Requerido
doctype
implementation
documentElement
createElement()
createDocumentFragment()
createTextNode()
createComment()
createCDATASection()
createProcessingInstruction()
createAttribute()
createEntityReference()
getElementsByTagName()
–
Requerido
Requerido
–
–
–
–
–
–
–
–
–
nodeName
nodeValue
nodeType
parentNode
childNodes
firstChild
lastChild
previousSibling
nextSibling
Attributes
ownerDocument
insertBefore()
replaceChild()
removeChild()
appendChild()
hasChildNodes()
cloneNode()
–
–
–
Requerido
–
Requerido
Requerido
Requerido
Requerido
–
–
–
–
–
–
–
–
data
length
substringData()
appendData()
insertData()
deleteData()
replaceData()
Requerido
Requerido
–
–
–
–
–
tagName
getAttribute()
setAttribute()
removeAttribute()
getAttributeNode()
setAttributeNode()
removeAttributeNode()
getElementsByTagName()
normalize()
Requerido
–
–
–
–
–
–
–
–
Document
Node
CharacterData
Element
Text
splitText
© ABNT 2007 - Todos los derechos reservados
–
27
ABNT NBR 15606-2:2007
7
NCL - Lenguaje declarativo XML para especificación de presentaciones multimedia
interactivas
7.1 Lenguajes modulares y perfiles de lenguajes
7.1.1
Módulos NCL
El abordaje modular ha sido utilizado en varios lenguajes recomendados por el W3C.
Módulos son colecciones de elementos, atributos y valores de atributos XML semánticamente relacionados que
representan una unidad funcional. Los módulos se definen en conjuntos coherentes. Esa coherencia se expresa
por medio de la asociación de un mismo namespace a los elementos de esos módulos.
NOTA
Namespaces se discuten en Namespaces in XML:1999.
Un perfil de lenguaje es una combinación de módulos. Los módulos son atómicos, es decir, no se pueden
subdividir cuando son incluidos en un perfil de lenguaje. Además, la especificación de un módulo puede incluir un
conjunto de requisitos para integración, con el cual los perfiles de lenguaje, que incluyen el módulo, deben ser
compatibles obligatoriamente.
NCL fue especificada de forma modular, permitiendo la combinación de sus módulos en perfiles de lenguaje.
Cada perfil puede agrupar un subconjunto de módulos NCL, permitiendo la creación de lenguajes orientados
hacia las necesidades específicas de los usuarios. Además, los módulos y perfiles NCL se pueden combinar con
módulos definidos en otros lenguajes, permitiendo la incorporación de características de la NCL en esos
lenguajes y viceversa.
Normalmente, hay un perfil de lenguaje que incorpora casi todos los módulos asociados a un único namespace.
Ése es el caso del perfil Lenguaje NCL.
Otros perfiles de lenguaje se pueden especificar como subconjuntos de un perfil mayor o incorporar una
combinación de módulos asociados a diferentes namespaces. Ejemplos del primer caso son los perfiles TVD
Básico (perfil BDTV) y TVD Avanzado (perfil EDTV) de la NCL.
Subconjuntos de los módulos del perfil Lenguaje NCL utilizados en la definición de los perfiles TVD Básico y TVD
Avanzado se definen para ajustar el lenguaje a las características del ambiente de radiodifusión de televisión, con
sus varios dispositivos de presentación: Aparato de televisión, dispositivos móviles etc.
NOTA
Un abordaje análogo también se encuentra en otros lenguajes (SMIL 2.1 Specification:2005 y XHTML 1.0:2002).
El principal alcance de la conformidad con perfiles de lenguaje es aumentar la interoperabilidad. Los módulos
obligatorios se definen de tal forma que cualquier documento, especificado de conformidad con un perfil de
lenguaje, da como resultado una presentación razonable cuando se presenta en un perfil distinto de aquél para el
cual fue especificado. El formateador de documentos, soportando el conjunto de módulos obligatorios, ignoraría
todos los otros elementos y atributos desconocidos.
NOTA
Renderizador de documentos, agente del usuario y exhibidor son otros nombres atribuidos al formateador de
documentos.
28
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
La versión NCL 3.0 revisa las funcionalidades contenidas en la NCL 2.3 (NCL Main 13 Profile:2005) y se divide en
15 áreas funcionales, que se dividen nuevamente en módulos. A partir de las 15 áreas funcionales, 14 se utilizan
para definir los perfiles TVD Avanzado y TVD Básico. Dos áreas funcionales tienen módulos con la misma
semántica definida por SMIL 2.0. Las 14 áreas funcionales utilizadas y sus módulos correspondientes son:
1)
Structure
Módulo Structure
2)
Layout
Módulo Layout
3)
Components
Módulo Media
Módulo Context
4)
Interfaces
Módulo MediaContentAnchor
Módulo CompositeNodeInterface
Módulo PropertyAnchor
Módulo SwitchInterface
5)
Presentation Specification
Módulo Descriptor
6)
Linking
Módulo Linking
7)
Connectors
Módulo ConnectorCommonPart
Módulo ConnectorAssessmentExpression
Módulo ConnectorCausalExpression
Módulo CausalConnector
Módulo CausalConnectorFunctionality
Módulo ConnectorBase
8)
Presentation Control
Módulo TestRule
Módulo TestRuleUse
Módulo ContentControl
Módulo DescriptorControl
9)
Timing
Módulo Timing
10)
Reuse
Módulo Import
© ABNT 2007 - Todos los derechos reservados
29
ABNT NBR 15606-2:2007
Módulo EntityReuse
Módulo ExtendedEntityReuse
11) Navigational Key
Módulo KeyNavigation
12) Animation
Módulo Animation
13)
Trasition Effects
Módulo TransitionBase
Módulo Trasition
14) Meta-Information
7.1.2
Identificadores para módulos y perfiles de lenguaje de la NCL 3.0
Se recomienda que cada perfil NCL declare explícitamente el URI del namespace que será usado para
identificarlo.
Documentos creados en perfiles de lenguaje que incluyen el módulo Structure de NCL pueden ser asociados con
el tipo MIME “application/x-ncl+xml”. Los documentos que utilizan el tipo MIME “application/x-ncl+xml” deben
obligatoriamente estar de conformidad con el lenguaje hospedero.
Los identificadores de namespace XML para el conjunto completo de módulos, elementos y atributos NCL 3.0
están contenidos en el siguiente namespace: http://www.ncl.org.br/NCL3.0/.
Cada módulo NCL posee un identificador único a él asociado. Los identificadores de los módulos NCL 3.0 deben
estar de acuerdo obligatoriamente con la Tabla 7.
Módulos también pueden ser identificados colectivamente. Las siguientes colecciones de módulos se definen:
 módulos utilizados por el perfil Lenguaje NCL 3.0: http://www.ncl.org.br/NCL3.0/LanguageProfile;
 módulos usados por perfil Conector Causal NCL 3.0: http://www.ncl.org.br/NCL3.0/CausalConnectorProfile;
 módulos utilizados por el perfil DTV Avanzado NCL 3.0: http://www.ncl.org.br/NCL3.0/EDTVProfile;
 módulos utilizados por el perfil DTV Básico NCL 3.0: http://www.ncl.org.br/NCL3.0/BDTVProfile.
30
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
Tabla 7 — Identificadores de los módulos de NCL 3.0
Módulos
Identificadores
Animation
http://www.ncl.org.br/NCL3.0/Animation
CompositeNodeInterface
http://www.ncl.org.br/NCL3.0/CompositeNodeInterface
CausalConnector
http://www.ncl.org.br/NCL3.0/CausalConnector
CausalConnectorFunctionality
ConnectorCausalExpression
http://www.ncl.org.br/NCL3.0/CausalConnectorFunctionality
http://www.ncl.org.br/NCL3.0/ConnectorCausal Expression
ConnectorAssessmentExpression
http://www.ncl.org.br/NCL3.0/ConnectorAssessmentExpression
ConnectorBase
http://www.ncl.org.br/NCL3.0/ConnectorBase
ConnectorCommonPart
http://www.ncl.org.br/NCL3.0/ConnectorCommonPart
ContentControl
http://www.ncl.org.br/NCL3.0/ContentControl
Context
http://www.ncl.org.br/NCL3.0/Context
Descriptor
http://www.ncl.org.br/NCL3.0/Descriptor
DescriptorControl
http://www.ncl.org.br/NCL3.0/DescriptorControl
EntityReuse
http://www.ncl.org.br/NCL3.0/EntityReuse
ExtendedEntityReuse
http://www.ncl.org.br/NCL3.0/ExtendedEntityReuse
Import
http://www.ncl.org.br/NCL3.0/Import
Layout
http://www.ncl.org.br/NCL3.0/Layout
Linking
http://www.ncl.org.br/NCL3.0/Linking
Media
http://www.ncl.org.br/NCL3.0/Media
MediaContentAnchor
http://www.ncl.org.br/NCL3.0/MediaContentAnchor
KeyNavigation
http://www.ncl.org.br/NCL3.0/KeyNavigation
PropertyAnchor
http://www.ncl.org.br/NCL3.0/PropertyAnchor
Structure
http://www.ncl.org.br/NCL3.0/Structure
SwitchInterface
http://www.ncl.org.br/NCL3.0/SwitchInterface
TestRule
http://www.ncl.org.br/NCL3.0/TestRule
TestRuleUse
http://www.ncl.org.br/NCL3.0/TestRuleUse
Timing
http://www.ncl.org.br/NCL3.0/Timing
TransitionBase
http://www.ncl.org.br/NCL3.0/TransitionBase
Transition
http://www.ncl.org.br/NCL3.0/Transition
Metainformation
http://www.ncl.org.br/NCL3.0/MetaInformation
Tres módulos SMIL [SMIL 2.1 Specification, 2005] se usaron como base para la definición de los módulos NCL
Transition y Metainformation. Los identificadores de estos módulos SMIL 2.0 se presentan en la Tabla 8.
Tabla 8 — Identificadores de los módulos de SMIL 2.0
Módulos
BasicTransitions
TransitionModifiers
Metainformation
© ABNT 2007 - Todos los derechos reservados
Identificadores
http://www.w3.org/2001/SMIL20/BasicTransitions
http://www.w3.org/2001/SMIL20/TransitionModifiers
http://www.w3.org/2001/SM I L20/Metainformation
31
ABNT NBR 15606-2:2007
7.1.3
Informaciones sobre versiones de la NCL
Las siguientes instrucciones de procesamiento se deben incluir obligatoriamente en un documento NCL. Éstas
identifican documentos NCL que contengan sólo los elementos definidos en esta Norma, y la versión NCL con la
cual el documento está de acuerdo.
<?xml version="1.0" encoding="ISO-8859-1 "?>
<ncl id="qualquer string" xmlns="http://www.ncl.org.br/NCL3.0/profileName">
El atributo id del elemento <ncl> puede recibir cualquier cadena de caracteres como valor.
El número de versión de una especificación NCL consiste en un número principal y otro secundario, separados
por un punto. Los números son representados como una cadena de caracteres formada por números decimales,
en la cual los ceros a la izquierda se suprimen. El número de versión inicial del estándar es 3.0.
Nuevas versiones de la NCL deben ser obligatoriamente publicadas de acuerdo con la siguiente política de
versión:
 si los receptores compatibles con versiones más antiguas aún pueden recibir un documento con base en la
especificación revisada, con relación a correcciones de error o por motivos operativos, la nueva versión de la
NCL debe ser obligatoriamente publicada con el número secundario actualizado;
 si los receptores compatibles con versiones más antiguas no pueden recibir un documento basado en las
especificaciones revisadas, el número principal debe ser obligatoriamente actualizado.
Una versión específica está definida bajo el URI http://www.ncl.org.br/NCL3.0/profileName, en que el número de
la versión se escribe inmediatamente después de la sigla “NCL”.
El nombre del perfil (profileName) en el URI debe ser obligatoriamente EDTVProfile (Perfil TVD Avanzado) o
BDTVProfile (Perfil TVD Básico).
7.2 Módulos NCL
7.2.1
Observaciones generales
Las principales definiciones de cada uno de los módulos NCL 3.0 presentes en los perfiles NCL TVD Básico y
TVD Avanzado se proveen en 7.2.2 a 7.2.15.
La definición completa de los módulos NCL 3.0, utilizando XML Schema, se presenta en el Anexo A. Cualquier
ambigüedad encontrada en este texto puede ser aclarada por medio de la consulta a los esquemas XML.
Después de discutir cada módulo, una tabla se presenta para indicar los elementos del módulo y sus atributos.
Para un perfil determinado, los atributos y contenidos (elementos hijos) de los elementos se pueden definir en el
mismo módulo o en el perfil del lenguaje que agrupa los módulos.
Las tablas descritas en 7.2.2 a 7.2.15 muestran los atributos y contenidos que vienen del perfil NCL DTV
Avanzado, además de los definidos en los mismos módulos. Las tablas descritas en 7.3.3 muestran los atributos y
contenidos que vienen del perfil NCL TVD Básico, además de los definidos en los mismos módulos. Los atributos
de elementos que son obligatorios están subrayados. En las tablas, se emplean los siguientes símbolos: (?)
opcional (cero o una ocurrencia), (|) o, (*) cero o más ocurrencias, (+) una o más ocurrencias. El orden de los
elementos hijos no se especifica en las tablas.
32
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
7.2.2
Área funcional Structure
El área funcional Structure tiene un sólo módulo, llamado Structure, que define la estructura básica de un
documento NCL. Este área define el elemento raíz, denominado <ncl>, el elemento <head> y el elemento <body>,
siguiendo la terminología adoptada por otros estándares W3C. El elemento <body> de un documento NCL es
tratado como un nudo de contexto NCM (NCMCore:2005).
En el NCM, el modelo conceptual de datos de la NCL, un nudo puede ser un contexto, un switch o un objeto de
media. Todos los nudos NCM están representados por elementos NCL correspondientes. Los nudos de contexto,
conforme definido en 7.2.4, contienen otros nudos y eslabones NCM.
Los elementos <ncl> y <body> pueden definir un atributo iD. El atributo iD identifica en forma unívoca un
elemento dentro de un documento. Su valor es un identificador XML.
El atributo title de <ncl> ofrece información adicional sobre el elemento. Los valores del atributo title pueden ser
utilizados por agentes de usuarios de varias formas.
El atributo xmlns declara un namespace XML, es decir, declara la colección primaria de construcciones XML
utilizada por el documento. El valor del atributo es el URL (Uniform Resource Locator), que identifica donde el
namespace está oficialmente definido. Tres valores se permiten para el atributo xmlns:
http://www.ncl.org.br/NCL3.0/EDTVProfile y http://www.ncl.org.br/NCL3.0/BDTVProfile, para los perfiles TVD
Avanzado y Básico, respectivamente, y http://www.ncl.org.br/NCL3.0/CausalConnectorProfile, para el perfil
Conector Causal. Un formateador NCL debe obligatoriamente saber que la localización de los esquemas para
tales namespaces es, por default, respectivamente:
http://www.ncl.org.br/NCL3.0/profiles/NCL30EDTV.xsd,
http://www.ncl.org.br/NCL3.0/profiles/NCL30BDTV.xsd, y
http://www.ncl.org.br/NCL3.0/profiles/NCL30CausalConnector.xsd
Los elementos hijos de <head> y <body> se definen en otros módulos NCL. Es altamente recomendable que los
elementos hijos de <head> se declaren en el orden siguiente: importedDocumentBase?, ruleBase?,
transitionBase?, regionBase*, descriptorBase?, connectorBase?, meta*, metadata*.
Los elementos de este módulo, sus elementos hijos y sus atributos deben estar de acuerdo obligatoriamente con
la Tabla 9.
Tabla 9 — Módulo Structure extendido
Elementos
ncl
Atributos
id, title, xmlns
7.2.3
(head?, body?)
(importedDocumentBase?, ruleBase?, transitionBase?,
regionBase*, descriptorBase?, connectorBase?, meta*,
metadata*)
head
body
Contenido
id
(port| property| media| context| switch| link| meta| metadata)*
Área funcional Layout
El área funcional Layout tiene un único módulo, denominado Layout, el cual especifica elementos y atributos que
definen cómo los objetos serán inicialmente presentados dentro de regiones de dispositivos de salida. De hecho,
este módulo define valores iniciales para propiedades NCL homónimas definidas en los elementos <media>,
<body> y <context> (ver 7.2.4).
Un elemento <regionBase>, que se debe declarar obligatoriamente en el elemento <head> del documento NCL,
define un conjunto de elementos <region>, cada cual pudiendo contener otro conjunto de elementos <region>
anidados, y así sucesivamente, en forma reiterativa.
© ABNT 2007 - Todos los derechos reservados
33
ABNT NBR 15606-2:2007
El elemento <regionBase> puede tener un atributo id. Elementos <region> deben tener obligatoriamente un
atributo id. Como esperado, el atributo id identifica en forma unívoca un elemento dentro de un documento.
Cada elemento <regionBase> está asociado a una clase de dispositivos donde ocurrirá la presentación. Para
identificar la asociación, el elemento <regionBase> define el atributo device, que puede tener los valores:
“systemScreen (i)” o “systemAudio(i)”. La clase elegida define las variables globales del ambiente:
SystemScreenSize(i), systemScreenGraphicSize(i) y systemAudioType(i), como definido en la Tabla 12 (ver 7.2.4).
Cuando no se especifica el atributo, la presentación debe hacerse obligatoriamente en el mismo dispositivo que
ejecuta el formateador NCL.
NOTA 1 Existen dos tipos diferentes de clases de dispositivos: activa y pasiva. En una clase activa, un dispositivo es capaz
de ejecutar las funciones de exhibidores de media. De un dispositivo de exhibición que se registra en una clase del tipo
“pasiva” no se exige la capacidad de ejecutar las funciones de exhibidores de media. Éste sólo debe ser capaz de presentar el
mapa de memoria de video que le es pasado y exhibir las muestras de audio pasada por otro dispositivo. En el SBTVD,
systemScreen (1) y systemAudio (1) se reservan para clases del tipo pasiva; systemScreen (2) y systemAudio (2) se reservan
para las clases del tipo activa.
NOTA 2 El elemento <regionBase> que define una clase pasiva también puede tener un atributo region. Este atributo usado
para identificar un elemento <region> en otra <regionBase> asociada a una clase activa donde está registrado el dispositivo
que genera el mapa de memoria de video enviado para los dispositivos de la clase pasiva; en la región especificada, el mapa
de memoria también debe ser exhibido.
Se recomienda que la interpretación del anidado de las regiones dentro de un <regionBase> sea realizada por el
software responsable por la orquestación de la presentación del documento (es decir, el formateador N CL). Para
los efectos de esta Norma, un primer nivel de anidado debe ser interpretado obligatoriamente como si fuese el
área del dispositivo donde ocurrirá la presentación; el segundo nivel como ventanas (por ejemplo, áreas de
presentación en la pantalla) del área-padre; y los otros niveles como regiones dentro de esas ventanas.
Una <region> también puede definir los siguientes atributos: title, left, right, top, bottom, height, width e zIndex.
Todos esos atributos poseen el significado usual W3C.
La posición de una región, conforme es especificada por sus atributos top, bottom, left y right, es siempre relativa
a la geometría-padre, que es definida por el elemento <region> padre o por el área total del dispositivo, en el caso
de las regiones en el primer nivel de anidado. Los valores de los atributos pueden ser valores porcentuales
no negativos, o unidades de pixels. Para valores en pixels, el autor puede omitir el calificador de unidad “px”
(por ejemplo, “100”). Para valores porcentuales, por otro lado, el símbolo “%” debe ser indicado obligatoriamente
(por ejemplo, “50%”). El porcentaje es siempre relativo al ancho del padre, en el caso de las definiciones de
los atributos right, left and width, y a la altura del padre, para las definiciones de los atributos bottom, top y height.
Los atributos top y left son los atributos primarios de posicionamiento de la región. Posicionan el canto superior
izquierdo de la región en la distancia especificada del margen superior izquierdo de la región-padre (o margen
superior izquierdo del dispositivo, en el caso de la región en el primer nivel de anidado). Algunas veces, puede ser
útil ajustar explícitamente los atributos bottom y right. Sus valores establecen la distancia entre el ángulo inferior
derecho de la región y el ángulo inferior derecho de la región-padre (o el margen inferior derecho del dispositivo,
en el caso de la región en el primer nivel de anidado) (ver Figura 2).
left
width
right
top
height
bottom
region
parent region
Figura 2 — Atributos de posicionamiento de la región
34
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
Con relación a los tamaños de la región, cuando se especifican declarando los atributos width y height usando la
anotación "%", el tamaño de la región es relativo al tamaño de la geometría de su padre, como mencionado
anteriormente. Los tamaños declarados como valores absolutos en pixels mantienen tales valores absolutos. El
tamaño intrínseco de una región es igual al tamaño de la geometría lógica del padre. Eso significa que, si una
región anidada no especifica cualquier posicionamiento o valores de tamaño, debe ser obligatoriamente asumido
que tiene la misma posición y valores de tamaño que su región-padre. En particular, cuando una región de primer
nivel no especifica cualquier posicionamiento o valores de tamaño, debe ser obligatoriamente asumida como
teniendo toda el área de presentación del dispositivo.
Cuando el usuario especifica informaciones sobre top, bottom y height para una misma <region>, pueden ocurrir
inconsistencias espaciales. En este caso, los valores de top y height deben obligatoriamente preceder el valor de
bottom. De forma análoga, cuando el usuario especifica valores inconsistentes para los atributos left, right y width
de la <region>, los valores de left y width se deben utilizar obligatoriamente para calcular un nuevo valor de right.
Cuando cualquiera de esos atributos no se especifica y no puede tener su valor calculado desde otros atributos,
ese valor debe ser obligatoriamente heredado del valor correspondiente definido en el padre de esa <region>.
Otra restricción es que las regiones-hijas no pueden quedar fuera del área establecida por sus regiones-padres.
El atributo zIndex especifica la precedencia de superposición de la región. Regiones con mayores valores de
zIndex deben ser obligatoriamente apiladas en la parte superior de regiones con valores de zIndex menores.
Si dos presentaciones generadas por los elementos A y B tienen el mismo nivel de apilado, en el caso que la
exhibición de un elemento B empiece después de la exhibición de un elemento A, la presentación de B debe ser
obligatoriamente apilada en la parte superior de la presentación de A (orden temporal); por otro lado, si la
exhibición de los elementos empieza al mismo tiempo, el orden apilado es elegido arbitrariamente por el
formateador. Cuando omitido, el valor default del zIndex es igual a 0 (cero).
El módulo Layout también define el atributo region, que es utilizado por un elemento <descriptor> (ver 7.2.6) para
referirse a un elemento <region> de Layout.
Los elementos de este módulo, sus elementos-hijos y sus atributos deben estar de acuerdo obligatoriamente con
la Tabla 10.
Tabla 10 — Módulo Layout extendido
Elementos
7.2.4
Atributos
Contenido
regionBase
id, device, region
(importBase|region)+
region
id, title, left, right, top, bottom, height, width, zIndex
(region)*
Área funcional Components
El área funcional Components se divide en dos módulos, denominados Media y Context.
El módulo Medía define los tipos básicos de objetos de media. Para definir objetos de media, este módulo define
el elemento <media>. Cada objeto de media tiene dos atributos principales, además del atributo id: src, que define
un URI del contenido del objeto, y type, que define el tipo de objeto.
Los URI (Uniform Resource Identifier) deben estar de acuerdo obligatoriamente con la Tabla 11.
© ABNT 2007 - Todos los derechos reservados
35
ABNT NBR 15606-2:2007
Tabla 11 — URI permitidos
Esquema
Parte específica del esquema
Uso
file:
///file_path/#fragment_identifier
Para archivos locales
http:
//server_identifier/file_path/#fragment_identifier
Para archivos remotos buscados por
el canal de interactividad usando el
protocolo http
https:
//server_identifier/file_path/#fragment_identifier
Para archivos remotos buscados por
el canal de interactividad usando el
protocolo https
rstp:
//server_identifier/file_path/#fragment_identifier
Para flujos (streams) logrados por el
canal de interactividad usando el
protocolo rstp
rtp:
//server_identifier/file_path/#fragment_identifier
Para flujos (streams) logrados por el
canal de interactividad usando el
protocolo rtp
Ncl-mirror: //media_element_identifier
Para un flujo de contenido idéntico a
uno que esté en presentación por
otro elemento de media
sbtvd-ts:
Para flujos elementales recibidos
por el flujo de transporte (TS)
//program_number.component_tag
Un URI absoluto contiene todas las informaciones necesarias para localizar su recurso. Los URI relativos también
son permitidos. URI relativos son direcciones incompletas que se aplican a una URI base para completar la
localización. Las partes omitidas son el esquema URI, el servidor y, también, en algunos casos, parte del camino
del URI.
El beneficio principal de utilizar URI relativas es la posibilidad de mover o copiar hacia otros locales los
documentos y directorios contenidos en el URI, sin exigir el cambio de los valores de los atributos URI dentro de
los documentos. Eso es especialmente interesante cuando se transportan documentos del servidor (normalmente
radiodifusores) hacia los receptores. Los caminos relativos del URI son típicamente utilizados como un medio
rápido de localización de archivos de media almacenados en el mismo directorio del documento NCL actual, o en
un directorio próximo a él. Frecuentemente consisten sólo en el nombre del archivo (opcionalmente con un
identificador de fragmento dentro del archivo). También pueden tener un camino relativo de directorio antes del
nombre del archivo.
Conviene matizar que las referencias para los recursos de flujos de video o audio, obligatoriamente, no deben
causar la ocurrencia de sintonización (tuning). Lar referencias que implican sintonización para acceder a un
recurso deben obligatoriamente portarse como si el recurso estuviese indisponible.
Los valores permitidos para el atributo type dependen del perfil NCL y deben seguir obligatoriamente el formato
MIME Media Types (o, simplemente, mimetypes). Un mimetype es una cadena de caracteres que define la clase
de media (audio, video, imagen, texto, aplicación) y un tipo de codificación de media (como jpeg, mpeg etc.). Los
mimetypes pueden ser registrados o informales. Los mimetypes registrados son controlados por la IANA (Internet
Assigned Numbers Authority). Los mimetypes informales no son registrados por la IANA, pero se definen
pactadamente; normalmente tienen una “x-“ antes del nombre del tipo de media.
Se definen cinco tipos especiales: application/x-ginga-NCL; application/x-ginga-NCLua, application/x-ginga-NCLet,
application/x-ginga-settings y application/x-ginga-time.
El tipo application/x-ginga-NC debe ser obligatoriamente aplicado a elementos <media> con código NCL (así, una
aplicación NCL puede ser embutida en otra aplicación NCL). El tipo application/x-ginga-NCLua debe ser
obligatoriamente aplicado a elementos <media> con código procedural Lua como contenido (ver Sección 10).
El tipo application/x-ginga-NCLet debe ser obligatoriamente aplicado a elementos <media> con código procedural
Xlet como contenido (ver Sección 11).
36
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
El tipo application/x-ginga-settings debe ser obligatoriamente aplicado a un elemento <media> especial (puede
existir solamente uno en un documento NCL) cuyas propiedades son variables globales definidas por el autor del
documento o variables de ambiente reservadas, que pueden ser manejadas por el procesamiento del documento
NCL. La Tabla 12 establece las variables ya definidas y su semántica.
Tabla 12 — Variables de ambiente
Grupo
system


grupo de variables
mantenidas por el sistema
receptor;
se pueden leer, pero no
pueden tener sus valores
alterados por una
aplicación NCL, un
procedimiento Lua o un
procedimiento Xlet;

programas nativos en el
receptor pueden alterar los
valores de las variables;

persisten durante todo el
tiempo de vida de un
receptor
Variable
Semántica
Valores posibles
system.language
Lenguaje de audio
system.caption
Lenguaje de caption
ISO 639-1 code
ISO 639-1
system.subtitle
Lenguaje de leyenda
ISO 639-1
system.returnBitRate(i)
Tasa de bits del canal de interactividad
real
(i) en Kbps
system.screenSize
Tamaño de la pantalla del dispositivo
de exhibición, en (líneas, pixels/línea),
cuando una clase no es definida
(entero, entero)
system.screenGraphicSize
Resolución configurada para el plano
gráfico de la pantalla del dispositivo de
exhibición, en (líneas, pixels/línea),
cuando una clase no es definida
(entero, entero)
system.audioType
Tipo
de
audio
del
dispositivo
exhibición, cuando una clase no es “mono” | “stereo” | “5.1”
definida
system.screenSize (i)
Tamaño de la pantalla de la clase (i)
de dispositivos de exhibición, en (entero, entero)
(líneas, pixels/línea)
system.screenGraphicSize (i)
Resolución configurada para el plano
gráfico de la pantalla de la clase (i) de
(entero, entero)
dispositivos de exhibición, en (líneas,
pixels/línea)
system.audioType(i)
Tipo de audio de la clase (i) de
“mono” | “stereo” | “5,1”
dispositivos de exhibición
system.devNumber(i)
Número de dispositivos de exhibición
entero
registrados en la clase (i)
system.classType(i)
Tipo de la clase (i)
system.info(i)
Lista de exhibidores de media de la
string
clase (i) de dispositivos de exhibición
system.classNumber
Número de clases de dispositivos de
entero
exhibición definidas
system.CPU
Desempeño de la CPU en MIPS
real
system.memory
Espacio de la memoria en Mbytes
entero
system.operatingSystem
Tipo de sistema operativo
string a ser definida
system.javaConfiguration
Tipo y versión de la configuración
soportada por la JVM del receptor
system.javaProfile
Tipo y versión del perfil soportado por
la JVM del receptor
system.luaVersion
Versión de la máquina Lua del
receptor
system.xxx
Cualquier variable prefijada por
“system” debe ser obligatoriamente
reservada para uso futuro
(“passive” | “ative”)
string
© ABNT 2007 - Todos los derechos reservados
(tipo seguido de la versión,
sin espacio, por ejemplo:
“CLDC1.1”)
string
(tipo seguido de la versión,
“
sin espacio – ej.: MIDP2.0”
string
37
ABNT NBR 15606-2:2007
Tabla 12 (continuación)
Grupo
user

grupo de variables mantenidas por
el sistema receptor;

se pueden leer, pero no pueden
tener sus valores alterados por una
aplicación NCL, un procedimiento
Lua o un procedimiento Xlet;

programas nativos en el receptor
pueden alterar los valores de las
variables;

persisten durante todo el tiempo de
vida de un receptor
Variable
Edad del usuario
entero
user.location
Localización del usuario (CEP)
string
user.genre
Género del usuario
“m”| “f”
user.xxx
Cualquier variable prefijada por
“user” debe ser obligatoriamente
reservada para uso futuro
default.focusBorderColor
Color default aplicado al margen
de un elemento en foco
“white” | “black” | “silver” |
“gray” | “red” | “maroon” |
“fuchsia” | “purple” | “lime”
| “green” | “yellow” | “olive”
|“blue” |“navy” |“aqua”
|“teal”
default.selBorderColor
Color default aplicado al margen
de un elemento en foco cuando es
activado
“White” | “black” | “silver” |
“gray” | “red” | “maroon” |
“fuchsia” | “purple” | “lime”
| “green” | “yellow” | “olive”
| “blue” | “navy” | “aqua”
|“teal”
Ancho default (en pixels) aplicado
al margen de un elemento en foco
entero
Transparencia default aplicada al
borde de un elemento en foco
valor real entre 0 y 1, o
valor real en la banda
[0,100] terminando con el
carácter “%” (por ejemplo,
30 %), con “1”, ó “100 %”
significando máxima
transparencia y “0”, ó
“0 %” significando
ninguna transparencia

grupo de variables mantenidas por
el sistema receptor;

se pueden leer y tener sus valores
alterados por una aplicación NCL o
por un procedimiento Lua o Xlet;
default.focusBorderWidth

programas nativos en el receptor
pueden alterar los valores de las
variables;
persisten durante todo el tiempo de
default.focusBorderTrans
vida de un receptor, sin embargo,
vuelven a su valor inicial al cambiar parency
de canal
default.xxx
Cualquier variable prefijada por
“default” debe obligatoriamente ser
reservada para uso futuro
service.currentFocus
Valor del atributo focusIndex del
elemento <media> en foco
service


grupo de variables mantenidas por
el formateador NCL;
se pueden leer y, en general, tener
sus valores alterados por una
aplicación NCL del mismo servicio;

se pueden leer, pero no pueden
tener sus valores alterados por un
programa Lua o Xlet del mismo
servicio; la escritura debe hacerse a
través de comandos NCL;

persisten, como mínimo, durante
todo el tiempo de duración de un
servicio
38
Valores posibles
user.age
default

Semántica
Identificador (id) del elemento
<media> que detenta el control de
las claves de navegación; si el
service.currentKeyMaster
elemento no está siendo
presentado o no está pausado, el
control es del formateador
service.xxx
entero
string
Cualquier variable prefijada por
“service” debe obligatoriamente
seguir las reglas especificadas
para el grupo
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
Tabla 12 (continuación)
Grupo
Variable
Semántica
Valores posibles
Número de servicios disponibles, en el
país, para el canal sintonizado.
si.numberOfServices
NOTA Es recomendable que el valor de
esta variable se obtenga a partir del
número de tablas PMT encontradas en
la tabla PAT del flujo de transporte
recibido por el canal sintonizado
(conforme norma ISO/IEC 138-181:2007). En el cálculo del valor de esta entero
variable, es recomendable que sólo se
consideren las tablas cuyo campo
country_code, disponible en el
descriptor
country_avaliability_descriptor (Sección
8.3.6 de la norma ABNT NBR 156032:2007) relativo a la tabla, corresponda
al contenido de la variable de ambiente
user.location
Número de servicios disponibles, en el
país, para el canal sintonizado.
si

grupo de variables mantenidas
por el middleware;

se pueden leer pero no pueden
tener sus valores alterados por
una aplicación NCL, un
procedimiento Lua o un
procedimiento Xlet;

si.numberOfPartialServices
persisten, como mínimo,
durante todo el tiempo de
sintonía de un canal
NOTA Es recomendable que el valor de
esta variable se obtenga a partir del
número de tablas PMT encontradas en
la tabla PAT del flujo de transporte
recibido por el canal sintonizado
(conforme norma ISO/IEC 138-181:2007). En el cálculo del valor de esta
variable, es recomendable que sólo se
consideren las tablas PMT cuyo campo entero
country_code, disponible en el
descriptor
country_availability_descriptor (Sección
8.3.6 de la ABNT NBR 15603-2:2007)
corresponda al contenido de la variable
de ambiente user.location y también
cuyos campos program_number de las
tablas correspondan a los campos
service_id de los
partial_reception_descriptor relativos a
las tablas NIT
Número del canal sintonizado.
si.channeNumber
si.xxx
© ABNT 2007 - Todos los derechos reservados
NOTA El valor de esta variable debe
obtenerse obligatoriamente a través del
campo remote_control_key-id del
descriptor ts_information_descriptor
entero
(Sección 8.3.42 de la norma ABNT NBR
15603-2:2007) de la tabla NIT (Sección
7.2.4 de la norma ABNT NBR156032:2007) que describe el servicio
corriente
Cualquier variable prefijada por “si”
debe obligatoriamente seguir las reglas
especificadas para el grupo
39
ABNT NBR 15606-2:2007
Tabla 12 (continuación)
Grupo
channel

grupo de variables mantenidas
por el formateador NCL;

se pueden leer y tener sus
valores alterados por una
aplicación NCL del mismo
canal;


pueden ser leídas pero no
pueden tener sus valores
alterados por una aplicación
NCL del mismo canal;
Variable
Semántica
channel.keyCapture
Requisición de teclas numéricas por
aplicaciones NCL
cannel.virtualKeyboard
Requisición del teclado virtual por
aplicaciones NCL
cannel.keyboardBounds
Región de exhibición del teclado virtual
(left, top, width, height
channel.xxx
Cualquier variable prefijada por
“channel” debe obligatoriamente seguir
las reglas especificadas para el grupo
persisten, por lo menos,
durante todo el tiempo de
sintonía de un canal
Valores posibles
(true | false)
(entero, entero,
entero, entero)
shared
 grupo de variables mantenidas
por el formateador NCL;
 se pueden leer y tener sus
valores alterados por un
programa NCL;
 pueden ser leídas pero no
pueden tener sus valores
alterados por un programa Lua o
Xlet; se debe escribir a través
de comandos NCL;
shared.xxx
Cualquier variable prefijada por
“shared” debe obligatoriamente seguir
las reglas especificadas para el grupo
El tipo application/x-ginga-time debe ser obligatoriamente aplicado a un elemento <media> especial (puede existir
solamente uno en un documento NCL) cuyo contenido es el Universal Time Coordinated (UTC). Cualquier
elemento <media> continuo sin fuente se puede utilizar para definir un reloj, relativo al tiempo de inicio de ese
elemento <media>.
NOTA
El contenido de un elemento <media> del tipo application/x-ginga-time se especifica con la siguiente sintaxis:
Año”:”Mes”:”Día”:”Hora”:”Minutos”:”Segundos”.”Fracción, donde Año es un entero; Mes es un entero en el intervalo [1, 12]; Día
es un entero en el intervalo [1, 31]; Hora es un entero en el intervalo [1, 23]; Minutos es un entero en el intervalo [0, 59];
Segundos es un entero en el intervalo [0, 59]; y Fracción es un entero positivo.
La Tabla 13 muestra algunos valores posibles del atributo type para los perfiles TVD Avanzado y Básico y las
extensiones de archivos asociadas. Los tipos obligatorios se definen en la ABNT NBR 15601. El atributo type es
opcional (excepto para los elementos <media> sin atributo src definido) y se recomienda su uso para guiar la
elección del exhibidor de media (herramienta de presentación) por el formateador. Cuando el atributo type no se
especifica, se recomienda que el formateador use la extensión del contenido especificado en el atributo src para
hacer la elección del exhibidor.
Cuando hay más de un exhibidor para el tipo soportado por el formateador, el elemento <descriptor> puede
especificar cuál será utilizado para la presentación. En caso contrario, el formateador debe utilizar
obligatoriamente un exhibidor default para ese tipo de media.
40
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
Tabla 13 — Tipos de media MIME para formateadores Ginga-NCL
Tipo de media
Extensión de archivo
text/html
htm, html
text/plain
txt
text/css
css
text/xml
xml
image/bmp
bmp
image/png
png
image/gif
gif
image/jpeg
jpg, jpeg
audio/basic
wav
audio/mp3
mp3
audio/mp2
mp2
audio/mpeg
mpeg, mpg
audio/mpeg4
mp4, mpg4
video/mpeg
mpeg, mpg
application/x-ginga-NCL
ncl
application/x-ginga-NCLua
application/x-ginga-NCLet
lua
class, jar
application/x-ginga-settings
no src (source)
application/x-ginga-time
no src (source)
El módulo Context es responsable por la definición de nudos de contexto a través de elementos <context>. Un
nudo de contexto NCM es un tipo particular de nudo de composición NCM y se define conteniendo un conjunto de
nudos y un conjunto de eslabones. Como normalmente ocurre, el atributo id identifica en forma unívoca cada
elemento <context> y <media> dentro de un documento.
Los atributos Instance, refer y descriptor son extensiones definidas en otros módulos y son discutidos en la
definición de tales módulos.
NOTA
Los elementos <media> del tipo application/x-ginga-NCL no pueden tener los atributos instance y refer. Es
recomendable que tampoco tengan elementos hijo.
Los elementos de los dos módulos de la funcionalidad Components, sus elementos-hijos y sus atributos deben
estar de acuerdo obligatoriamente con las Tablas 14 y 15.
Tabla 14 — Módulo Media extendido
Elements
media
Attributes
id, src, refer,
instance, type,
descriptor
Content
(area|property)*
Tabla 15 — Módulo Context extendido
Elements
context
Attributes
id, refer
© ABNT 2007 - Todos los derechos reservados
Content
(port|property|media|context|link|switch|meta|metadata)*
41
ABNT NBR 15606-2:2007
7.2.5
Área funcional Interfaces
El área funcional Interfaces permite la definición de interfaces de nudos (objetos de media o nudos de
composición) que serán utilizadas en relaciones con otras interfaces de nudos. Este área funcional se divide en
cuatro módulos:
 MediaContentAnchor, que permite definiciones de anclas de contenido (o área) para nudos de media
(elementos <media>);
 CompositeNodeInterface, que permite definiciones de puertos para nudos de composición (elementos
<context> y <switch>);
 PropertyAnchor, que permite la definición de propiedades de nudos como interfaces de nudos; y
 SwitchInterface, que permite la definición de interfaces especiales para elementos <switch>.
El módulo MediaContentAnchor define el elemento <area>, que extiende la sintaxis y semántica del elemento
homónimo definido por SMIL y XHTML. Así, permite la definición de anclas de contenido que representan
porciones espaciales, a través de atributo coords (como en XHTML); la definición de anclas de contenido que
representan porciones temporales, a través de los atributos begin y end; y la definición de anclas de contenido
que representan porciones espacio-temporales a través de los atributos coords, begin y end (como en SMIL).
Además de ello, el elemento <area> permite la definición de anclas textuales, a través de los atributos text y
position, que definen una cadena de caracteres y la ocurrencia de esa cadena en el texto, respectivamente.
Adicionalmente, el elemento <area> también puede definir un ancla de contenido con base en el número de
muestras de audio o frames de video, a través de los atributos first y last, que deben obligatoriamente indicar
la muestra/frame inicial y final. Finalmente, el elemento <area> también puede definir un ancla de contenido con
base en el atributo label, que especifica una cadena de caracteres que debe ser utilizada por el exhibidor
de media para identificar una región de contenido.
NOTA
Los atributos first y last se especifican de acuerdo con una de las siguientes sintaxis:
a)
muestras”s”, donde Muestras es un entero positivo;
b)
cuadros”f”, donde Cuadros es un entero positivo;
c)
NPT”npt”, donde NPT es el valor tiempo normal de exhibición (Normal Play Time value).
Si se define el atributo begin, pero no se especifica el atributo end, el final de toda presentación del contenido de
media debe ser obligatoriamente considerado como cierre del ancla. Por otro lado, si el atributo end se define sin
una definición explícita de begin, el inicio de toda la presentación del contenido de media debe ser
obligatoriamente considerado como el inicio del ancla. Un comportamiento semejante se espera con relación a los
atributos first y last. En el caso de un elemento <media> del tipo application/x-ginga-time, los atributos begin y end
deben obligatoriamente ser siempre especificados y corresponden a un tiempo absoluto del Universal Tim
Coordinated (UTC).
NOTA 1 Con excepción del elemento <media> del tipo application/x-ginga-time, los atributos begin y end deben especificarse
obligatoriamente con una de las siguientes sintaxis:
a)
Horas”:”Minutos”:”Segundos”.”Fracción, donde Horas es un entero en el intervalo[0,23]; Minutos es un entero en el
itervalo [0,59]; Segundos es un entero en el intervalo [0,59] y fracción es un entero posivo
b)
Segundos”s”, donde Segundos es un entero positivo.
NOTA 2 Para el elemento <media> del tipo application/x-ginga-time, los atributos begin y end deben especificarse
obligatoriamente con la siguiente sintaxis: Año”:”Mes”:”Día”:”Hora”:”Minutos”:”Segundos”.”Fracción, de acuerdo con la zona del
tiempo del país. El Formateador NCL es responsable de traducir ese valor para un valor correspondiente de UTC.
42
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
Como normalmente ocurre, los elementos <area> deben tener obligatoriamente un atributo id, que identifica en
forma unívoca el elemento dentro de un documento.
El elemento <area> y sus atributos deben estar de acuerdo obligatoriamente con la Tabla 16.
Tabla 16 — Módulo MediaContentAnchor extendido
Elementos
Atributos
id, coords, begin, end, text, position, first, last,
label
area
Contenido
vacío
El módulo CompositeNodeInterface define el elemento <port>, que especifica un puerto de un nudo de
composición con su respectivo mapeo para una interfaz (atributo interfaz) de uno de sus componentes
(especificado por el atributo component).
En el NCM, todo nudo (media o contexto) debe poseer obligatoriamente un ancla con una región que representa
el contenido total del nudo. Ese ancla es denominada ancla de contenido total y se declara por omisión (default)
en NCL. Cada vez que un componente NCL es referido sin especificar una de sus anclas, se debe asumir
obligatoriamente el ancla de contenido total.
El elemento <port> y sus atributos deben estar de acuerdo obligatoriamente con la Tabla 17.
Tabla 17 — Módulo CompositeNodeInterface extendido
Elementos
port
Atributos
id, component, interface
Contenido
vacío
El módulo PropertyAnchor define un elemento denominado <property>, que se puede utilizar para definir una
propiedad o grupo de propiedades de un nudo, como una de sus interfaces (ancla). El elemento <property> define
el atributo name, que indica el nombre de la propiedad o grupo de propiedades, y el atributo value, atributo
opcional que define un valor inicial para la propiedad name. El elemento padre no puede tener elementos
<property> con los mismos valores para el atributo name.
Es posible tener exhibidores de documentos NCL (formateadores) que definen algunas propiedades de nudos e
interfaces de nudos, implícitamente. Sin embargo, por lo general, es de buena práctica definir explícitamente las
interfaces. Así, todas las interfaces deben ser obligatoriamente explícitamente definidas.
Los elementos <body>, <context> y <media> pueden tener varias propiedades embutidas. Ejemplos de esas
propiedades pueden encontrarse entre las que definen el local en que se situará el objeto de media durante una
presentación, la duración de la presentación y otras que definen características adicionales de la presentación:
top, left, bottom, right, width, height,plan, explicitDur, background, transparency, visible, fit, scroll, style,
soundLevel, balanceLevel, trebleLevel, bassLevel, fontColor, fontFamily, font Style, fontSize, fontVariant, font
Weight, reusePlayer, playerLife etc. Tales propiedades asumen como sus valores iniciales los definidos en
atributos homónimos del descriptor y región asociada al nudo (ver 7.2.3 y 7.2.6). Algunas propiedades tienen su
valor definido por el propio sistema, como la propiedad contentId asociada a un objeto de media continua cuyo
contenido se refiere a un flujo elemental, que inicialmente tiene el valor nulo, pero en cuanto el objeto es iniciado
asume el valor del identificador (contenido en el campo también llamado contentId) transportado en el descriptor
de referencia NPT. Otro ejemplo es la propiedad standby que debe obligatoriamente asumir el valor “true”
mientras un objeto de media continua ya iniciado, cuyo contenido se refiere a un flujo elemental, esté con su flujo
temporalmente interrumpido por otro contenido entrelazado en el mismo flujo elemental. Sin embargo, en
cualquier caso, cuando una propiedad incorporada se utiliza en una relación, debe ser obligatoriamente declarada
explícitamente como elemento <property> (interfaz).
© ABNT 2007 - Todos los derechos reservados
43
ABNT NBR 15606-2:2007
NOTA 1
A la propiedad de standby se le puede atribuir el valor “true” cuando el valor del identificador transportado en el
NPT reference descriptor (en el campo contentId) señalizado como “no pausado” sea diferente del valor de la propiedad
contentId del mismo objeto.
NOTA 2
La propiedad visible también puede ser asociada a un elemento <context> y <body>. En esos casos, cuando la
propiedad tiene su valor igual a “true”, vale la especificación de visible de cada nudo hijo. Cuando tiene su valor igual a “false”,
todos los elementos de la composición son exhibidos de forma invisible. Particularmente, cuando un documento tiene su
elemento <body> con la propiedad visible = “false” y su evento de presentación en estado= “paused”, se dice que la aplicación
está en “espera” (stand-by). Cuando una aplicación entra en stand-by, el video principal del servicio vuelve a ocupar el 100%
de la dimensión de la pantalla en la que es exhibido y el audio principal al 100% de su volumen.
Un grupo de propiedades del nudo también puede ser explícitamente declarado como un elemento único
<property> (interfaz), permitiendo que los autores especifiquen el valor de varias propiedades con una propiedad
única. Los siguientes grupos deben ser reconocidos obligatoriamente por un formateador NCL: location, grouping
(left, top), en ese orden; size, grouping (width, height), en ese orden; y bounds, grouping (left, top, width, height),
en ese orden.
Cuando un formateador trata una alteración en un grupo de propiedad, debe obligatoriamente probar sólo la
consistencia del proceso al final. Las palabras top, left, bottom, right, width, height, explicitDur, background,
transparency, visible, fit, scroll, style, soundLevel, balanceLevel, trebleLevel, bassLevel, fontColor, fontFamily,
fontStyle, fontSize, fontVariant, font Weight, reusePlayer, playerLife, location, size y bounds son palabras
reservadas para valores del mismo atributo name del elemento <property>.
El elemento <property> y sus atributos deben estar de acuerdo obligatoriamente con la Tabla 18.
Tabla 18 — Módulo PropertyAnchor extendido
Elementos
property
Atributos
name, value
Contenido
vacío
El módulo SwitchInterface permite la creación de interfaces de elemento <switch> (ver 7.2.4), que se pueden
mapear a un conjunto de interfaces alternativas de nudos internos, permitiendo a un eslabón anclar en el
componente elegido cuando el <switch> es procesado (NCM Core:2005). Ese módulo introduce el elemento
<switchPort>, que contiene un conjunto de elementos de mapeo. Un elemento de mapeo define un camino desde
el <switchPort> para una interfaz (atributo interfaz) de uno de los componentes del <switch> (especificados por su
atributo component).
Es importante mencionar que cada elemento que representa una interfaz de objeto (<area>, <port>, <property> y
<switchPort>) debe tener obligatoriamente un identificador (atributo id).
O elemento <switchPort>, sus elementos-hijos y sus atributos deben estar de acuerdo obligatoriamente con la
Tabla 19.
44
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
Tabla 19 — Módulo SwitchInterface extendido
Elementos
7.2.6
Atributos
Contenido
switchPort
id
mapping+
mapping
component, interface
vacío
Área funcional Presentation Specification
El área funcional Presentation Specification tiene un único módulo denominado Descriptor. El alcance de ese
módulo es especificar informaciones espacio-temporales necesarias para la presentación de cada componente
del documento. Esas informaciones son modeladas por los objetos descriptores.
El módulo Descriptor permite la definición de elementos <descriptor>, que contienen un conjunto de atributos
opcionales, agrupando todas las definiciones espacio-temporales que se deben usar de acuerdo con el tipo de
objeto a ser presentado. La definición de elementos <descriptor> se debe incluir obligatoriamente en el
encabezamiento del documento, dentro del elemento <descriptorBase>, que especifica el conjunto de
descriptores de un documento. El elemento <descriptor> debe tener obligatoriamente el atributo id; y el elemento
<descriptorBase> puede tener el atributo id, que, como normalmente ocurre, identifica en forma unívoca los
elementos dentro de un documento.
Un elemento <descriptor> puede tener atributos temporales: ExplicitDur y freeze, definidos por el módulo Timing
(ver 7.2.10); un atributo denominado player, que identifica la herramienta de presentación a ser utilizada; un
atributo denominado region, que se refiere a la región definida por los elementos del módulo Layout (ver 7.2.3);
atributos para navegación: moveLeft, moveRight, move Up ; moveDown, focusIndex, focusBorderColor; focusBorderWidth;
focusBorderTransparency, focusSrc, selBorderColor, y focusSelSrc, definidos por el módulo KeyNavigation (ver 7.2.12);
y atributos de transición: transIn y transOut (ver 7.2.14).
NOTA
Un elemento <descriptor> de un elemento <media> del tipo application/x-ginga-NCL no puede contener el atributo
player. En ese caso, un exhibidor NCL específico para cada dispositivo de exhibición es definido por el middleware.
Un elemento <descriptor> también puede tener elementos <descriptorParam> como elementos hijo, que se
utilizan para parametrizar el control de la presentación del objeto asociado con el elemento descriptor. Estos
parámetros pueden, por ejemplo, redefinir algunos valores de atributos definidos por los atributos de la región. Los
mismos también pueden definir nuevos atributos, tales como plan, en qué plano de una pantalla estructurada se
colocará un objeto; rgbChromakey, definido por un color RGB que se exhibirá como transparente; background,
especificando el color de fondo utilizado para rellenar el área de una región de exhibición de la media, cuando
toda la región no es rellenada por la media en sí; visible, permitiendo que la presentación del objeto sea
visualizada u ocultada; fit, indicando como un objeto será presentado; scroll, que permite la especificación de
como un autor le gustaría configurar el desplazamiento vertical en una región; transparency, indicando el grado de
transparencia de la presentación de un objeto; style, que se refiere a una hoja de estilo [Cascading Style Sheets,
1998] con informaciones, por ejemplo, para presentación del texto; además de especificar atributos para objetos
de audio, tales como soundLevel, balanceLevel, trebleLevel y bassLevel. Además, los elementos-hijos
<descriptorParam> pueden determinar si un nuevo exhibidor debe ser obligatoriamente solicitado, o si un
exhibidor ya solicitado se debe utilizar obligatoriamente (reusePlayer), y especificar qué pasará a instancias del
exhibidor al final de la presentación (playerLife). Las palabras Top, left, bottom, right, width, height, explicitDur,
location, size, bounds, background, visible, fit, scroll, style, soundLevel, balanceLevel, trebleLevel, bassLevel,
reusePlayer y playerLife son palabras reservadas para valores del atributo name del elemento <descriptorParam>.
Los valores posibles para los nombres reservados de parámetros/atributos deben estar de acuerdo
obligatoriamente con la Tabla 20.
© ABNT 2007 - Todos los derechos reservados
45
ABNT NBR 15606-2:2007
Tabla 20 — Parámetros/atributos reservados y valores posibles
Nombre del
parámetro/atributo
Valor
top, left, bottom,
right, width, height
Número real en la banda [0,100] terminando con el carácter “%” (por ejemplo, 30 %), o un valor entero especificando el atributo en
pixels (en el caso de weight y height, un entero no negativo)
location
Dos números separados por coma, cada uno siguiendo las reglas de valor especificadas para parámetros left y top,
respectivamente
size
Dos valores separados por coma. Cada valor debe seguir obligatoriamente las mismas reglas especificadas para parámetros de
width y height, respectivamente
bounds
Cuatro valores separados por coma. Cada valor debe seguir obligatoriamente las mismas reglas especificadas para parámetros
left, top, width y height, respectivamente
background
Nombres de colores reservados: “white”, “black”, “silver”, “gray”, red”, “maroon”, fuchsia”, “purple”, “lime”, “green”, “yellow”, “olive”,
“blue”, “navy”, “aqua”, o “teal”. Otra opción para especificar el valor del color se especifica en la ABNT NBR 15606-1. El valor del
color de fondo también puede tener valor reservado “transparent”. Eso puede ser útil para presentar imágenes transparentes,
como GIF transparentes, superpuestos sobre otras imágenes o videos.
visible
“true” o “false”. Cuando no se especifica, el atributo asume el valor “true”.
transparency
Un número real en la banda [0,1], o un número real en la banda [0,100] terminando con el carácter “%” (por ejemplo, 30%),
especificando el grado de transparencia de una presentación de objeto (“1” ó “100 %” significa transparencia total y ”0“ ó “0 %”
significa opaco)
fit
“fill”, “hidden”, “meet”, “meetBest”, “slice”.
“fill”: redimensiona el contenido del objeto de media para que toque todos los bordes de la caja definida por los atributos de ancho
y altura del objeto
“hidden”: si la altura/longitud intrínseca del contenido de media es menor que el atributo de altura/longitud, el objeto debe ser
obligatoriamente creado empezando del margen superior/izquierdo y tener la altura/longitud restante rellenada con el color de
fondo; si la altura/longitud intrínseca del contenido de media es mayor que el atributo altura/longitud, el objeto debe ser
obligatoriamente creado empezando por el margen superior/izquierdo hasta que la altura/longitud definida en el atributo sea
alcanzada, y tener la parte del contenido de media abajo/a la derecha de la altura/longitud cortada
“meet”: redimensiona el objeto de media visual mientras preserva su relación de aspecto hasta que su altura o anchura es igual al
valor especificado por los atributos height o width. El ángulo superior izquierdo del contenido de media se sitúa en las
coordenadas superiores izquierdas de la caja, el espacio vacío a la derecha o en la base debe ser obligatoriamente rellenado con
el color del telón
“meetBest”: La semántica es idéntica a la del “meet”, excepto que la imagen no es redimensionada en más de 100 % en cualquier
dimensión
“slice”: redimensiona el contenido de la media visual preservando su relación de aspecto, hasta que su altura o anchura sea igual
al valor especificado en los atributos de altura y anchura, y que la caja de presentación definida esté completamente rellenada.
Algunas partes del contenido pueden ser cortadas. El exceso de anchura es cortado desde la derecha del objeto de media. El
exceso de altura es cortado desde la base del objeto de media
scroll
“
style
Localizador de un archivo de hoja de estilo
soundLevel,
balanceLevel,
trebleLevel,
bassLevel
Un número real en la banda [0, 1], o un número real en la banda [0,100] terminando con el carácter “%” (por ejemplo, 30 %)
zIndex
Un número entero en la banda [0, 255], siendo que regiones con mayor valor de zIndex se sitúan sobre regiones con menor valor
de zIndex
fontFamily
Una lista priorizada de nombres de familia de fuentes y/o nombres genéricos de familias
fontStyle
Estilo de la fuente (“normal”, o “italic”)
fontSize
Tamaño de la fuente
fontVariant
Forma de exhibición del texto: fuente en “small-caps” o “normal”
fontWeight
Peso de la fuente (“normal”, o “bold”)
fontColor
Color de la fuente (“white”, “black”, “silver”, “gray”, red”, “maroon”, fuchsia”, “purple”, “lime”, “green”, “yellow”, “olive”, “blue”, “navy”,
“aqua”, o “teal”)
reusePlayer
Valor booleano: “false”, “true”. Valor default = “false”
playerLife
“
46
none”, “horizontal”, “vertical”, “both”, o “automatic”
keep”, “close”. Valor default = “close”
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
Además de todos los atributos mencionados, el elemento <descriptor> también puede tener atributos definidos en
el área funcional transition effects (ver 7.2.14).
NOTA
Si se especifican varios valores para un mismo atributo, el valor definido en el elemento <property> tiene
precedencia sobre el valor definido en un elemento <descriptorParam>, que, a su vez, tiene preferencia sobre el valor definido
en un atributo del elemento <descriptor> (incluyendo el atributo region).
Además del elemento <descriptor>, el módulo Descriptor define un atributo homónimo, que se refiere a un
elemento del conjunto de descriptores del documento. Cuando un perfil de lenguaje utiliza el módulo Descriptor,
debe obligatoriamente determinar cómo los descriptores estarán asociados con los componentes del documento.
Siguiendo las directrices NCM, esta Norma establece que el atributo descriptor está asociado con cualquier nudo
de media a través de elementos <media> y a través de las extremidades de los eslabones (elementos <bind>)
(ver 8.2.1).
El conjunto de descriptores de un documento puede contener elementos <descriptor> o elementos
<descriptorSwitch>, que permiten especificar descriptores alternativos (ver 7.2.9).
Los elementos del módulo Descriptor, sus elementos-hijos y sus atributos deben estar de acuerdo
obligatoriamente con la Tabla 21.
Tabla 21 — Módulo Descriptor extendido
Elementos
descriptor
Atributos
id, player, explicitDur, region, freeze, moveLeft,
moveRight, move Up, moveDown, focusIndex,
focusBorderColor, focusBorderWidth,
focusBorderTransparency, focusSrc,focusSelSrc,
selBorderColor, transIn, transOut
Contenido
(descriptorParam)*
descriptorParam
name, value
vacío
descriptorBase
id
(importBase|descriptor|descriptorSwitch)+
7.2.7
Área funcional Linking
El área funcional Linking define el módulo Linking, responsable por la definición de los eslabones, que utilizan
conectores. Un elemento <enlace> puede tener un atributo id, que identifica en forma unívoca el elemento dentro
de un documento y debe tener obligatoriamente un atributo xconnector, que se refiere al URI de un conector
hipermedia.
La
referencia
debe
tener
obligatoriamente
el
formato
alias#connector_id,
o
documentURI_value#connector_id, para conectores definidos en un documento externo (ver 7.2.11), o
simplemente connector_id, para conectores definidos en el propio documento.
El elemento <link> contiene elementos-hijos denominados <bind>, que permiten asociar nudos a papeles (roles)
del conector (ver 7.2.8). Para hacer esta asociación, un elemento <bind> tiene cuatro atributos básicos. El primero
se denomina role, que se utiliza para hacer referencia a un papel del conector. El segundo se denomina
component, que se utiliza para identificar el nudo. El tercero es un atributo opcional denominado interfaz,
usado para hacer referencia a una interfaz del nudo. El cuarto es un atributo opcional denominado descriptor,
usado para hacer referencia a un descriptor a ser asociado con el nudo, conforme definido por el módulo
Descriptor (ver 7.2.6).
NOTA
El atributo interfaz puede referirse a cualquier interfaz del nudo, es decir, un ancla, una propiedad o un puerto, si es
un nudo de composición. El atributo interfaz es opcional. Cuando no se especifica, la asociación se realiza con todo el
contenido del nudo (ver 7.2.5).
Si el elemento conector define parámetros (ver 7.2.8), conviene a los elementos <bind> o <link> definir valores
para esos parámetros, a través de sus elementos-hijos denominados <bindParam> y <enlaceParam>,
respectivamente, ambos con atributos name y value. En ese caso, el atributo name debe obligatoriamente hacer
referencia al nombre de un parámetro del conector, mientras que el atributo value debe definir obligatoriamente un
valor a ser atribuido al respectivo parámetro.
© ABNT 2007 - Todos los derechos reservados
47
ABNT NBR 15606-2:2007
Los elementos del módulo Linking, sus atributos y sus elementos-hijos deben estar de acuerdo obligatoriamente
con la Tabla 22.
Tabla 22 — Módulo Linking extendido
Elementos
bind
7.2.8
Atributos
Contenido
bindParam
role, component, interface,
descriptor
name, value
linkParam
name, value
vacío
link
id, xconnector
(linkParam*, bind+)
(bindParam)*
vacío
Area funcional Connectors
El área funcional Connectors de la NCL 3.0 se divide en siete módulos básicos: ConnectorCommonPart,
ConnectorAssessmentExpression,
ConnectorCausalExpression,
CausalConnector,
ConstraintConnector
(no considerado en esta Norma), ConnectorBase y CompositeConnector (tampoco considerado en esta Norma).
Los módulos del área funcional Connectors son totalmente independientes de los demás módulos NCL. Estos
módulos forman el núcleo de un lenguaje nuevo de aplicación XML (de hecho, otros perfiles NCL 3.0) para la
definición de conectores, que se pueden utilizar para especificar relaciones de sincronización espacio-temporales,
tratando relaciones de referencia (de interacción con el usuario) como un caso particular de relaciones de
sincronización temporal.
Además de los módulos básicos, el área funcional Connectors también define módulos que agrupan conjuntos de
módulos básicos, para facilitar la definición del perfil de lenguaje. Ése es el caso del módulo
CausalConnectorFunctionality, utilizado en la definición de los perfiles EDTV, BDTV y CausalConnector.
El módulo CausalConnectorFunctionality agrupa los siguientes módulos: ConnectorCommonPart,
ConnectorAssessmentExpression, ConnectorCausalExpression y CausalConnector.
Un elemento <causalConnector> representa una relación causal que puede ser utilizada por elementos <link> en
documentos. En una relación causal, una condición debe ser obligatoriamente satisfecha para disparar una
acción.
Un <causalConnector> especifica una relación independientemente de las relaciones, es decir, no especifica
cuáles nudos (representados por elementos <media>, <context>, <body> y <switch>) interactúan a través de la
relación. Un elemento <link>, a su vez, representa una relación, del tipo definido por su conector, interconectando
a diferentes nudos. Los eslabones representan el mismo tipo de relación, pero interconectando a diferentes nudos,
pueden reutilizar el mismo conector, reutilizando todas las especificaciones. Un <causalConnector> especifica, a
través de sus elementos-hijos, un conjunto de puntos de la interfaz, denominados papeles. Un elemento <link> se
refiere a un <causalConnector> y define un conjunto de mapeos (elementos <bind> hijos del elemento <link>),
que asocian cada extremidad del eslabón (interfaz de nudo) a un papel del conector utilizado.
Las relaciones en NCL se basan en eventos. Un evento es una ocurrencia en el tiempo que puede ser
instantánea o tener duración mensurable. La NCL 3.0 define los siguientes tipos de eventos:
 evento de presentación, que es definido por la presentación de un subconjunto de las unidades de
información de un objeto de media, especificado en la NCL por el elemento <area>, o por el nudo de media en
sí (presentación de todo el contenido). Los eventos de presentación también se pueden definir sobre nudos de
composición (representados por un elemento <body>, <context> o <switch>, y representan la presentación de
las unidades de información de cualquier nudo dentro del nudo de composición);
 evento de selección, que es definido por la selección de un subconjunto de las unidades de información de un
objeto de media, especificado en la NCL por el elemento <area>, o por el propio nudo de media (presentación
del contenido total);
48
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
 evento de atribución, que es definido por la atribución de un valor a una propiedad de un nudo (representado
por un elemento <media>, <body>, <context> o <switch>), que se debe declarar obligatoriamente en un
elemento <property>, hijo del nudo; y
 evento de composición, que es definido por la presentación de la estructura de un nudo de composición
(representado por un elemento <body>, <context> o <switch>). Los eventos de composición se utilizan para
presentar el mapa de la composición (organización de la composición).
Cada evento define una máquina de estados que se recomienda ser controlada por el formateador NCL, como
demostrado en la Figura 3. Además, todo evento tiene un atributo asociado, denominado occurrences, que cuenta
cuántas veces el evento va del estado ocurriendo (occurring) al estado preparado (sleeping), durante la
presentación de un documento. Eventos como presentación y atribución también tienen un atributo denominado
repetitions, que cuenta cuántas veces el evento debe ser obligatoriamente reiniciado (pasó del estado ocurriendo
para el estado preparado) por el formateador. Ese atributo puede contener el valor “indefinite”, llevando a una
repetición infinita (loop) de las ocurrencias del evento hasta que ocurra alguna interrupción externa.
Los nombres de transición para la máquina de estado de evento deben estar de acuerdo obligatoriamente con la
Tabla 23.
Figura 3 — Máquina de estado de evento
Tabla 23 — Nombres de las transiciones para una máquina de estado de evento
Transición (causada por acción)
sleeping  occurring (start)
occurring  sleeping (stop or natural end)
occurring  sleeping (abort)
occurring  paused (pause)
paused  occurring (resume)
paused  sleeping (stop)
paused  sleeping (abort)
Nombre de la transición
starts
stops
aborts
pauses
resumes
stops
aborts
Un evento de presentación asociado con un nudo de media, representado por un elemento <media>, empieza en
el estado preparado. En el inicio de la exhibición de sus unidades de información, el evento va para el estado
ocurriendo. Si la exhibición se suspende temporalmente, el evento permanece en el estado pausado (paused),
mientras dura esa situación.
Un evento de presentación puede cambiar de ocurriendo para preparado como consecuencia de la finalización
natural de la duración de la presentación, o debido a una acción que termina el evento. En ambos casos, el
atributo occurrences se incrementa, y el atributo repetitions se disminuye en uno. Si, después de disminuido, el
© ABNT 2007 - Todos los derechos reservados
49
ABNT NBR 15606-2:2007
valor del atributo repetitions es mayor que cero, el evento es automáticamente reiniciado (vuelve nuevamente al
estado ocurriendo).
Cuando la presentación de un evento se interrumpe bruscamente, a través de un comando para abortar la
presentación, el evento también va al estado preparado, pero sin incrementar el atributo occurrences y
actualizando el valor del atributo repetitions para cero. La duración de un evento es el tiempo en que permanece
en el estado ocurriendo. Tal duración puede ser intrínseca al objeto de media, explícitamente especificada por un
autor (atributo explicitDur de un elemento <descriptor>), o derivado de una relación.
Un evento de presentación asociado con un nudo de composición representado por un elemento <body> o
<context> permanece en el estado ocurriendo mientras por lo menos un evento de presentación asociado con
cualquiera de los nudos hijos de esa composición está en el estado ocurriendo, o mientras por lo menos un
eslabón-hijo del nudo de composición esté siendo evaluado.
Un evento de presentación asociado con un nudo de composición representado por un elemento <body> o
<context> está en el estado pausado si por lo menos un evento de presentación asociado con cualquiera de los
nudos hijos de la composición está en el estado pausado y todos los otros eventos de presentación asociados
con los nudos hijos de composición están en el estado preparado o pausado. En caso contrario, el evento de
presentación está en el estado preparado.
NOTA
Otros detalles sobre el comportamiento de las máquinas de estado de evento de presentación para nudos de
media y de composición se suministran en la Sección 8.
Un evento de presentación asociado con un nudo switch, representado por un elemento <switch>, permanece en
el estado ocurriendo mientras el elemento-hijo del switch, elegido (nudo seleccionado) a través de las reglas de
enlace (bind rules), esté en el estado ocurriendo. Está en el estado pausado si el nudo seleccionado está en el
estado pausado. En caso contrario, el evento de presentación está en el estado preparado.
Un evento de selección es iniciado en el estado preparado. Permanece en el estado ocurriendo mientras el ancla
correspondiente (subconjunto de las unidades de información del objeto de media) esté siendo seleccionada.
Los eventos de atribución permanecen en el estado ocurriendo mientras los valores de propiedad
correspondientes estén siendo modificados. Obviamente, eventos instantáneos, como eventos para simple
atribución de valor, permanecen en el estado ocurriendo sólo durante un período infinitesimal de tiempo.
Un evento de composición (asociado a un nudo de composición representado por un elemento <body>, <context>
o <switch>) permanece en el estado ocurriendo mientras el mapa de la composición está siendo presentado.
Las relaciones se definen con base en los estados de los eventos, en las alteraciones sobre las máquinas de
estado de evento, sobre los valores de atributos de los eventos, y sobre los valores de propiedad de los nudos
(elemento <media>, <body>, <context> o <switch>). El módulo CausalConnectorFunctionality permite sólo la
definición de relaciones causales, definidas por el elemento <causalConnector> del módulo CausalConnector.
Un elemento <causalConnector> tiene una expresión de cola (glue expression), que define una expresión de
condición y una de acción. Cuando la expresión de condición es satisfecha, la expresión de acción debe ser
obligatoriamente ejecutada. El elemento <causalConnector> debe tener obligatoriamente un atributo id, que
identifica únicamente el elemento dentro de un documento.
Una expresión de condición puede ser simple (elemento <simpleCondition>) o compuesta (elemento
<compoundCondition>), ambos elementos definidos por el módulo ConnectorCausalExpression.
El elemento <simpleCondition> tiene un atributo role, cuyo valor debe ser obligatoriamente único en el conjunto
de roles del conector. Un role (papel) es un punto de interfaz del conector, que puede ser asociado a interfaces de
nudos por un eslabón que hace referencia al conector. Un elemento <simpleCondition> también define un tipo de
evento (atributo eventType) y a qué transición se refiere la condición (atributo transition). Los atributos eventType
y transition son opcionales. Pueden ser inferidos por el valor del atributo role si se utilizan valores reservados.
En caso contrario, atributos event Type y transition son obligatorios.
50
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
Los valores reservados utilizados para definir los roles en <simpleCondition> se establecen en la Tabla 24.
Si un valor de eventType es “selection”, el role también puede definir sobre a qué dispositivo se refiere la
selección (por ejemplo, teclas de un teclado o control remoto), a través de su atributo key. Por lo menos los
siguientes valores (que son sensibles al tipo mayúscula o minúscula) deben ser obligatoriamente aceptados por el
atributo key: “0”, “1”, “2”, “3”, “4”, “5”, “6”, “7”, “8”, “9”, “A”, “B”, “C”, “D”, “E”, “F”, “G”, “H”, “I”, “J”, “K”, “L”, “M”, “N”,
“O”, “P”, “Q”, “R”, “S”, “T”, “U”, “V”, “W”, “X”, “Y”, “Z”, “*”, “#”, “MENU”, “INFO”, “GUIDE”, “CURSOR_DOWN”,
“CURSOR_LEFT”,
“CURSOR_RIGHT”,
“CURSOR_UP”,
“CHANNEL_DOWN”,
“CHANNEL_UP”,
“VOLUME_DOWN”, “VOLUME_UP”, “”, “ENTER”, “RED”, “GREEN”, “YELLOW”, “BLUE”, “BACK”, “EXIT”,
“POWER”, “REWIND”, “STOP”, “EJECT”, “PLAY”, “RECORD”, “PAUSE”.
Tabla 24 — Valores reservados para especificación de la condición del role asociados a las
máquinas de estado de evento
Valor de role
Valor de la transición
Tipo de evento
onBegin
starts
presentation
onEnd
stops
presentation
onAbort
aborts
presentation
onPause
pauses
presentation
onResume
resumes
presentation
onSelection
starts
selection
onBeginAttribution
starts
attribution
onEndAttribution
stops
attribution
La cardinalidad del role especifica el número mínimo (atributo min) y máximo (atributo Max) de los participantes
que pueden ejercer el papel (número de binds) cuando el <causalConnector> se utiliza para crear un <link>.
El valor mínimo de la cardinalidad debe ser obligatoriamente siempre un valor finito positivo, mayor que cero y
menor o igual al valor máximo de la cardinalidad. Si la cardinalidad mínima y la máxima no se informan, “1” debe
ser obligatoriamente asumido como valor (default) para ambos parámetros. Cuando el valor máximo de
cardinalidad es mayor que uno, varios participantes pueden ejecutar el mismo papel (role), es decir, puede haber
varios enlaces (binds) conectando diversos nudos al mismo papel. El valor “unbounded” puede ser dado al
atributo max, si el role tuviera binds ilimitados asociados a él. En los dos últimos casos, conviene que un atributo
qualifier sea especificado para informar la relación lógica entre los binds de condición simple. Como descrito en la
Tabla 25, los valores posibles para el atributo qualifier son: “Or” (o) o “and” (y). Si el calificador (atributo qualifier)
establece un operador lógico “or”, el eslabón será accionado durante la ocurrencia de cualquier condición.
Si el calificador establece un operador lógico “and”, el eslabón será accionado después de la ocurrencia de todas
las condiciones simples. En caso de no ser especificado, se debe asumir obligatoriamente el valor (default) “or”.
Tabla 25 — Valores del calificador para condiciones simples
Elemento role
Calificador
Semántica
<simpleCondition>
“or”
Verdadero siempre que ocurre cualquier condición
simple asociada
simpleCondition>
“and”
Verdadero inmediatamente después de la
ocurrencia de todas las condiciones simples
asociadas
Un atributo de retardo (delay) también puede ser definido para una <simpleCondition>, especificando que la
condición es verdadera después de un período de retardo desde el momento en que ocurre la transición.
© ABNT 2007 - Todos los derechos reservados
51
ABNT NBR 15606-2:2007
El elemento <compoundCondition> tiene un atributo operator con el valor Booleano (“and” u “or”) relacionando sus
elementos-hijos: <simpleCondition>, <compoundCondition>,<assessmentStatement> y <compoundStatement>.
Un atributo delay también puede ser definido, especificando que la condición compuesta es verdadera después
que un tiempo de retardo del momento en que la expresión, relacionada a sus elementos-hijos, sea verdadera.
Los elementos <assessmentStatement> y <compoundStatement> son definidos por el módulo
ConnectorAssessmentExpression.
NOTA
Cuando una condición “and” compuesta se relaciona a más de una condición de disparo (es decir, una condición
solamente satisfecha en un instante de tiempo infinitesimal – como, por ejemplo, el final de la presentación de un objeto), la
condición compuesta debe ser obligatoriamente considerada verdadera en el instante inmediatamente después de la
satisfacción de todas las condiciones de disparo.
Una expresión de acción capta acciones que pueden ser ejecutadas en relaciones causales, pudiendo ser
compuestas por un elemento <simpleAction> o <compoundAction>, también definido por el módulo
ConnectorCausalExpression.
El elemento <simpleAction> tiene un atributo role, que debe ser obligatoriamente único en el conjunto de papeles
(roles) del conector. Como siempre, un papel es un punto de interfaz del conector, que está asociado a las
interfaces de nudos por un <link> que se refiere al conector. Un elemento <simpleAction> también define un tipo
de evento (atributo event Type) y qué transición de estado de evento él dispara (action Type).
Los atributos eventType y actionType son opcionales. Pueden ser inferidos por el valor de role, si se utilizan
valores reservados. En caso contrario, son obligatorios atributos eventType y actionType. Los valores reservados
utilizados para definir los roles de un elemento <simpleAction> se establecen en la Tabla 26.
Tabla 26 — Valores de role de acción reservados asociados a las máquinas de estado de evento
Role value
Action type
Event type
start
start
presentation
stop
stop
presentation
abort
abort
presentation
pause
pause
presentation
resume
resume
presentation
set
start
attribution
Si un valor eventType es “attribution”, el elemento <simpleAction> también debe definir obligatoriamente el valor
que será atribuido, a través de su atributo value. Si ese valor se especifica como “&anyName”, (donde el $
es símbolo reservado a anyName es cadena de caracteres, excepto uno de los nombres reservados para apeles),
el valor a ser atribuido se debe obtener de la propiedad vinculada a role=”anyName”, definida en un elemento
<bind> del elemento <link> que utiliza el conector. Si ese valor no se puede obtener, no se debe realizar ninguna
atribución.
NOTA 1 Declarar el atributo role=“anyName” en un elemento <bind> de un <link>, implica tener un papel implícitamente
declarado como: <attributeAssessment role=“anyName” eventType=“attribution” attributeType=“nodeProperty”/>. Ese es el
único caso posible de un elemento <bind> referirse a un papel no definido explícitamente en un conector.
NOTA 2 En el caso de value=“$anyName”, el valor que se atribuirá debe ser obligatoriamente el valor de una propiedad
(elemento <property>) de un componente de la misma composición en la que el eslabón (elemento <link>) que referencia el
evento es referido, o una propiedad de composición en la que el eslabón es definido, o una propiedad de un elemento
accesible a través de un puerto de composición en el que el eslabón es definido o, aún, una propiedad de un elemento
accesible a través de un puerto de una composición (elementos <port> o <switchPort> anidada en la misma composición en
que el eslabón es definido.
52
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
Como en el caso de los elementos <simpleCondition>, la cardinalidad del role especifica el número mínimo
(atributo min) y máximo (atributo Max) de los participantes de un role (número de binds), cuando el
<causalConnector> se utiliza para crear un eslabón. Cuando el valor máximo de la cardinalidad es mayor que uno,
varios participantes pueden participar de un mismo role. Cuando tiene valor “unbounded”, el número de binds es
ilimitado. En los dos últimos casos, un calificador debe, obligatoriamente, ser especificado. La Tabla 27 presenta
los posibles valores de calificador.
Tabla 27 — Valores del calificador de acción
Elemento role
Calificador
Semántica
<simpleAction>
“par”
Todas las acciones se deben ejecutar obligatoriamente en
paralelo
<simpleAction>
“seq”
Todas las acciones se deben ejecutar obligatoriamente en
la secuencia de las declaraciones dada por el bind
Un atributo delay también puede ser definido por un <simpleAction>, especificando, cuando sea definido, que la
acción debe ser obligatoriamente disparada sólo después de esperar por el tiempo especificado. Además de ello,
el <simpleAction> también puede definir un atributo repeat para ser aplicado al atributo repetitions del evento, y
un atributo repeatDelay, para ser aguardado antes de la repetición de la acción.
Además de todos los atributos mencionados, el elemento <simpleAction> también puede tener atributos definidos
en el área funcional Animation (atributos duration y by), si su valor de event Type es “attribution” (ver 7.2.13).
El elemento <compoundAction> tiene un atributo operator (“par” o “seq”) relacionando sus elementos-hijos:
<SimpleAction> y <compoundAction>. Acciones compuestas paralelas ("par") y secuenciales ("seq") especifican
que la ejecución de las acciones se deberá realizar obligatoriamente en cualquier orden o en un orden específico,
respectivamente. Un atributo de delay también puede ser definido, especificando que la acción compuesta se
debe aplicar obligatoriamente después del retardo especificado.
Cuando el operador secuencial se utiliza, las acciones deben ser iniciadas obligatoriamente en el orden
especificado. Sin embargo, una acción no necesita esperar hasta que la anterior sea completada para entonces
ser iniciada.
El
módulo
ConnectorAssessmentExpression
define
cuatro
<attributeAssessment>, <valueAssessment> y <compoundStatement>.
elementos:
<assessmentStatement>,
El <attributeAssessment> tiene un atributo role, que debe ser obligatoriamente único en el conjunto de roles del
conector. Como normalmente ocurre, un role es un punto de interfaz del conector, que es asociado a las
interfaces de los nudos por un <link> que hace referencia al conector. Un <attributeAssessment> también define
un tipo de evento (atributo event Type).
Si el valor de eventType es “selection” (selección), conviene al <attributeAssessment> también definir sobre a qué
equipo se refiere la selección (por ejemplo, teclas de un teclado o control remoto), a través de su atributo key.
Si el valor eventType es “presentation”, el atributo attributeType especifica el atributo de evento (“occurrences” o
“repetitions”) o el estado del evento (“state”); si el valor eventType es “selection”, el atributo attribute Type es
opcional y, en caso de estar presente, puede tener el valor “occurrences” (default) o “state”; si el eventType es
“attribution” el attributeType es opcional y puede tener el valor “nodeProperty” (default), “occurrences”, “repetition”
o “state”. En el primer caso, el evento representa una propiedad del nudo a ser evaluada, en los otros, el evento
representa la evaluación de la propiedad de evento de atribución correspondiente o el estado del evento de
atribución. Un valor de compensación (offset) se puede agregar a un <attributeAssessment> antes de la
comparación (por ejemplo, una compensación se puede agregar a una evaluación de atributo para especificar: “la
posición vertical de la pantalla más 50 pixels”.
El elemento <valueAssessment> tiene un atributo value que debe asumir obligatoriamente un valor de estado de
evento, o cualquier valor a ser comparado con una propiedad del nudo o atributo de evento.
© ABNT 2007 - Todos los derechos reservados
53
ABNT NBR 15606-2:2007
El elemento <assessmentStatement> tiene un atributo comparator que compara los valores inferidos desde sus
elementos-hijos (elementos <attributeAssessment> y <valueAssessment>):
d)
en el caso de <attributeAssessment>: un valor de propiedad del nudo [eventType = “attribution” y el attribute
Type = “nodeProperty”]; o un valor de atributo de evento [eventType = (“presentation”, “attribution” o
“selection”) y el attributeType = (“occurrences” o “repetition”)]; o un estado de evento [event Type =
(“presentation”, “attribution” o “selection”) y el attribute Type = “state”];
e)
en el caso del <valueAssessment>: un valor de su atributo value.
El elemento <compoundStatement> tiene un atributo operator con un valor Booleano (“and” u “or”) relacionando
sus elementos-hijos: <AssessmentStatement> o <compoundStatement>. Un atributo isNegated también se puede
definir para especificar si el elemento-hijo del <compoundStatement> debe ser obligatoriamente negado antes
que la operación Booleana sea evaluada.
El elemento <causalConnector> puede tener elementos-hijos (elementos <connectorParam>), que se utilizan para
parametrizar valores de los atributos de los conectores. El módulo ConnectorCommonPart define el tipo de
elemento <connectorParam>, que tiene atributos name y type.
Para especificar cuáles atributos reciben valores de parámetro definidos por el conector, sus valores se
especifican como el nombre del parámetro, precedido por el símbolo $.
EJEMPLO
Para parametrizar el atributo delay, un parámetro denominado actionDelay se define (<connectorParam
name="actionDelay" type=”unsignedLong”/>) y el valor “$actionDelay” se utiliza en el atributo (delay=”$actionDelay”).
Los elementos del módulo CausalConnectorFunctionality, sus elementos-hijos y sus atributos deben estar de
acuerdo obligatoriamente con la Tabla 28.
Tabla 28 — Módulo CausalConnectorFunctionality extendido
Elementos
causalConnector
id
connectorParam
name, type
simpleCondition
role, delay, eventType, key,
transition, min, max, qualifier
Contenido
(connectorParam*, (simpleCondition |
compoundCondition), (simpleAction |
compoundAction))
vacío
vacío
compoundCondition
operator, delay
((simpleCondition |
compoundCondition)+,
(assessmentStatement |
compoundStatement)*)
simpleAction
role, delay, event Type, action
Type, value, min, max,
qualifier, repeat, repeatDelay,
duration, by
vacío
compoundAction
operator, delay
(simpleAction | compoundAction)+
assessmentStatement
comparator
(attributeAssessment,
(attributeAssessment |
valueAssessment)
valueAssessment
role, eventType, key,
attributeType, offset
value
compoundStatement
operator, isNegated
attributeAssessment
54
Atributos
vacío
vacío
(assessmentStatement |
compoundStatement)+
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
El módulo ConnectorBase define un elemento denominado <connectorBase>, que permite la agrupación de
conectores. Como normalmente ocurre, se recomienda que el elemento <connectorBase> tenga un atributo id,
que identifica únicamente el elemento dentro de un documento.
El contenido exacto de una base de conectores es especificado por un perfil de lenguaje que utiliza las facilidades
ofrecidas por los conectores. Sin embargo, como la definición de conectores no es fácilmente realizada por
usuarios inexpertos, la idea es tener usuarios experimentados definiendo los conectores, almacenándolos en
bibliotecas (bases de conectores) que puedan ser importadas, tornándolas disponibles a otros usuarios para la
creación de eslabones. El Anexo C suministra un ejemplo de definiciones de conectores que pueden ser
importadas.
Los elementos del módulo ConnectorBase, sus elementos-hijos, y sus atributos deben estar de acuerdo
obligatoriamente con la Tabla 29.
Tabla 29 — Módulo ConnectorBase extendido
Elementos
Atributos
connectorBase
7.2.9
Contenido
(importBase|causalConnector)*
id
Área funcional Presentation Control
El alcance del área funcional Presentation Control es especificar alternativas de contenido y presentación para un
documento. Ese área funcional se divide en cuatro módulos, denominados TestRule, TestRuleUse,
ContentControl y DescriptorControl.
El módulo TestRule permite la definición de reglas que, cuando satisfechas, seleccionan alternativas para la
presentación del documento. La especificación de reglas en NCL 3.0 se realiza en un módulo separado, porque
son útiles para definir tanto componentes cuanto descriptores alternativos.
El elemento <ruleBase> especifica un conjunto de reglas y se debe definir obligatoriamente como elemento-hijo
del elemento <head>. Esas reglas pueden ser simples, definidas por el elemento <rule>, o compuestas, definidas
por el elemento <compositeRule>. Las reglas simples definen un identificador (atributo id), una variable (atributo
var), un valor (atributo value) y un comparador (atributo comparator) relacionando la variable a un valor.
La variable debe ser obligatoriamente una propiedad del nudo settings (elemento <media> del tipo application/xginga-settings), es decir, el atributo var debe poseer obligatoriamente el mismo valor del atributo name de un
elemento <property>, definido como hijo del elemento <media> del tipo application/x-ginga-settings. Las reglas
compuestas tienen un identificador (atributo id) y un operador Booleano (“and” u “or” – atributo operator)
relacionando sus reglas-hijas. Como normalmente ocurre, el atributo id identifica únicamente los elementos <rule>
y <compositeRule> dentro de un documento.
Los elementos del módulo TestRule, sus elementos-hijos y sus atributos deben estar de acuerdo obligatoriamente
con la Tabla 30.
Tabla 30 — Módulo TestRule extendido
Elementos
Atributos
Contenido
ruleBase
id
(importBase|rule|compositeRule)+
Rule
id, var,
comparator, value
vacío
compositeRule
id, operator
(rule | compositeRule)+
El TestRuleUse define el elemento <bindRule>, que se utiliza para asociar reglas con componentes de un
elemento <switch> o <descriptorSwitch>, a través de sus atributos rule y constituent, respectivamente.
© ABNT 2007 - Todos los derechos reservados
55
ABNT NBR 15606-2:2007
El elemento del módulo TestRuleUse y sus atributos deben estar de acuerdo obligatoriamente con la Tabla 31.
Tabla 31 — Módulo TestRuleUse extendido
Elementos
Atributos
bindRule
constituent, rule
Contenido
vacío
El módulo ContentControl especifica el elemento <switch>, permitiendo la definición de nudos alternativos a ser
elegidos en tiempo de presentación del documento. Las reglas de prueba utilizadas para escoger el componente
del switch a ser presentado se definen por el módulo TestRule, o son reglas de prueba específicamente definidas
e incorporadas en una implementación del formateador NCL. El módulo ContentControl también define el
elemento <defaultComponent>, cuyo atributo component (del tipo IDREF) identifica el elemento (default) que
debe ser obligatoriamente seleccionado si ninguna de las reglas bindRule es evaluada como verdadera.
Para permitir la definición de eslabones que se conectan a anclas del componente elegido después de la
evaluación de las reglas de un switch, se recomienda que un perfil del lenguaje también incluya el módulo
SwitchInterface, que permite la definición de interfaces especiales, denominadas <switchPort>.
Los elementos <switch> deben tener obligatoriamente un atributo id, que identifica únicamente el elemento dentro
de un documento. El atributo refer es una extensión definida en el módulo Reuse (ver 7.2.11).
Cuando un <context> se define como elemento-hijo de un <switch>, los elementos <link> en forma recursiva
contenidos en el elemento <context> deben ser obligatoriamente considerados por un exhibidor NCL apenas si
<context> es seleccionado después de la evaluación del switch. En caso contrario, se recomienda que los
elementos <link> sean considerados desactivados y obligatoriamente no deben interferir en la presentación del
documento.
Los elementos del módulo ContentControl, sus elementos-hijos y sus atributos deben estar de acuerdo
obligatoriamente con la Tabla 32.
Tabla 32 — Módulo ContentControl extendido
Elementos
Atributos
switch
id, refer
defaultComponent
component
Contenido
defaultComponent?, (switchPort | bindRule | media |
context | switch)*)
vacío
El módulo DescriptorControl especifica el elemento <descriptorSwitch>, que contiene un conjunto de descriptores
alternativos a ser asociado a un objeto. Los elementos <descriptorSwitch> deben tener obligatoriamente un
atributo id, que identifica únicamente el elemento dentro de un documento. Análogamente al elemento <switch>,
la elección <descriptorSwitch> se realiza en tiempo de presentación, utilizando reglas de prueba definidas por el
módulo TestRule, o reglas de prueba específicamente definidas e incorporadas en una implementación del
formateador NCL. El módulo DescriptorControl también define el elemento <defaultDescriptor>, cuyo atributo
descriptor (del tipo IDREF) identifica el elemento (default) que debe ser obligatoriamente seleccionado si ninguna
de las reglas bindRule es evaluada como verdadera.
Los elementos del módulo DescriptorControl, sus elementos-hijos y sus atributos deben estar de acuerdo
obligatoriamente con la Tabla 33.
56
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
Tabla 33 — Módulo DescriptorControl extendido
Elementos
Atributos
Contenido
descriptorSwitch
id
(defaultDescriptor?, (bindRule | descriptor)*)
defaultDescriptor
descriptor
vacío
Durante la presentación de un documento, desde el momento en el que un <switch> es evaluado, se considera
resuelto hasta el final de su presentación, es decir, mientras su evento de presentación correspondiente está en el
estado ocurriendo o pausado. Durante la presentación de un documento, desde el momento en el que un
<descriptorSwitch> es evaluado, se considera resuelto hasta el final de la presentación del elemento <media> que
le fue asociado, es decir, mientras cualquier evento de presentación asociado con el elemento <media> esté en el
estado ocurriendo o pausado.
NOTA
Se recomienda que los formateadores NCL aplacen la evaluación del switch hasta el momento que un eslabón
anclado al switch necesite ser evaluado. Conviene que la evaluación del descriptor Switch sea atrasada hasta el momento en
el que el objeto refiriéndose a él necesite estar listo para ser presentado.
7.2.10 Área funcional Timing
El área funcional Timing define el módulo Timing. El módulo Timing permite la definición de atributos temporales
para componentes de un documento. Básicamente, ese módulo define atributos para especificar qué pasa con un
objeto al final de su presentación (freeze) y la duración ideal de un objeto (explicitDur). Esos atributos pueden ser
incorporados por los elementos <descriptor>.
7.2.11 Área funcional Reuse
NCL permite una gran reutilización de sus elementos. El área funcional Reuse de NCL se divide en tres módulos:
Import, EntityReuse y ExtendedEntityReuse.
Para permitir que una base de entidades sea incorporada a otra base ya existente, el módulo Import define el
elemento <importBase>, que tiene dos atributos: DocumentURI y alias. El atributo documentURI se refiere a un
URI correspondiente al documento NCL conteniendo la base a ser importada. El atributo alias especifica un
nombre a ser utilizado como código cuando sea necesario referirse a elementos de esa base importada.
El nombre del atributo alias debe ser obligatoriamente único en un documento y su alcance está supeditado al
documento que lo definió. La referencia tendría el formato: alias#element_id. La operación de importación es
transitiva, es decir, si la baseA importa la baseB que importa la baseC, entonces la baseA importa la baseC. Sin
embargo, el alias definido para la baseC dentro de la baseB obligatoriamente no debe ser tenido en cuenta por la
baseA.
Cuando un perfil de lenguaje utiliza el módulo Import, se permiten las siguientes especificaciones:
 el elemento <descriptorBase> puede tener un elemento-hijo <importBase> refiriéndose a un URI
correspondiente a otro documento NCL conteniendo la base de descriptores a ser importada (en realidad sus
elementos-hijos) y anidada. Cuando una base de descriptores es importada, la base de regiones y la base de
reglas, si existen en el documento importado, son también automáticamente importadas para las bases de
regiones y de reglas del documento correspondiente que realiza la importación;
 el elemento <connectorBase> puede tener un elemento-hijo <importBase> refiriéndose a un URI
correspondiente a otra base de conectores a ser importada (en realidad sus elementos-hijos) y anidada;
 el elemento <transitionBase> puede tener un elemento-hijo <importBase> refiriéndose a un URI
correspondiente a otra base de transiciones a ser importada (en realidad sus elementos-hijos) y anidada;
 el elemento <regionBase> puede tener un elemento-hijo <importBase> refiriéndose a un URI correspondiente
a otro documento NCL conteniendo la base de la regiones a ser importada (en realidad sus elementos-hijos) y
anidada. Aunque NCL defina su modelo de layout, nada impide que un documento NCL utilice otros modelos
© ABNT 2007 - Todos los derechos reservados
57
ABNT NBR 15606-2:2007
de layout, desde que definan regiones donde los objetos pueden ser presentados, como, por ejemplo,
modelos de layout SMIL 2.1. Al importar una <regionBase>, un atributo opcional denominado región se puede
especificar, dentro de un elemento <importBase>. Cuando está presente, el atributo debe identificar
obligatoriamente el id de un elemento <región> declarado en el elemento <región Base> del documento
hospedero (documento que hizo la operación de importación). Como consecuencia, todos los elementos
<región>, hijos del <regionBase> importados, deben ser obligatoriamente considerados elementos <región>
hijos de la región referida por el atributo región del <importBase>. Si no es especificado, los elementos
<región>, hijos del <regionBase> importado, deben ser obligatoriamente considerados hijos directos del
elemento <regionBase> del documento hospedero.
El elemento <importedDocumentBase> especifica un conjunto de documentos NCL importados y se debe definir
obligatoriamente como elemento-hijo del elemento <head>. El elemento <importedDocumentBase> debe tener
obligatoriamente un atributo id, que identifica únicamente el elemento dentro de un documento.
Un documento NCL puede ser importado a través de un elemento <importNCL>. Todas las bases definidas dentro
de un documento NCL, así como el elemento <body> del documento, se importan todos a la vez, a través del
elemento <importNCL>. Las bases son tratadas como si cada una hubiese sido importada por un elemento
<importBase>. El elemento <body> importado será tratado como un elemento <context>. El elemento
<importNCL> no “incluye” el documento NCL referido, sino que sólo hace visible el documento referido para que
sus componentes puedan ser reutilizados por el documento que definió el elemento <importNCL>. Así, el <Body>
importado, así como cualesquiera de sus nudos, puede ser reutilizado dentro del elemento <body> del documento
NCL que realizó la importación.
El elemento <importNCL> tiene dos atributos: DocumentURI y alias. El documentURI se refiere a un URI
correspondiente al documento a ser importado. El atributo alias especifica un nombre que se usa cuando se
realiza una referencia a elementos de ese documento importado. Como en el elemento <importBase>, el nombre
debe ser obligatoriamente único (type=ID) y su alcance se supedita al documento que definió el atributo alias. La
referencia tendría el formato: alias#element_id. Es importante notar que el mismo alias conviene que se utilice
cuando es necesario referirse a elementos definidos en las bases del documento importado (<regionBase>,
<connectorBase>, <descriptorBase> etc.).
La operación del elemento <importNCL> también tiene propiedad transitiva, es decir, si el documentoA importa
documentoB que importa documentoC, entonces el documentoA importa el documentoC. Sin embargo, el alias
definido para el documentoC dentro del documentoB obligatoriamente no se debe tener en cuenta por el
documentoA.
Los elementos del módulo Import, sus elementos-hijos y sus atributos deben estar de acuerdo obligatoriamente
con la Tabla 34.
Tabla 34 — Módulo Import extendido
Elementos
Atributos
Contenido
importBase
alias, documentURI, región
vacío
imported DocumentBase
id
(importNCL)+
importNCL
alias, documentURI
vacío
El módulo EntityReuse permite que un elemento NCL sea reutilizado. Ese módulo define el atributo refer, que
hace referencia a un elemento id que será reutilizado. Sólo <media>, <context>, <body> o <switch> se pueden
reutilizar. Un elemento que hace referencia a otro elemento no puede ser reutilizado; es decir, su id no puede ser
el valor de un atributo refer.
Si el nudo referido se define dentro de un documento D importado, el valor del atributo refer debe tener
obligatoriamente el formato “alias#iD”, donde “alias” es el valor del atributo alias asociado al documento D
importado.
58
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
Cuando un perfil del lenguaje utiliza el módulo EntityReuse, puede agregar el atributo refer a:
 un elemento <media> o <switch>. En ese caso, el elemento referido debe ser obligatoriamente,
respectivamente, un elemento <media> o <switch>, que representa el mismo nudo previamente definido en el
propio <body> del documento o en un <body> externo importado. El elemento referido debe contener,
obligatoriamente, directamente la definición de todos sus atributos y elementos-hijos;
 un elemento <context>. En ese caso, el elemento referido debe ser obligatoriamente un elemento <context> o
<body>, que representa el mismo contexto previamente definido en el <body> del propio documento o en un
<body> externo importado. El elemento referido debe contener, obligatoriamente, directamente la definición
de todos sus atributos y elementos-hijos.
Cuando un elemento declara un atributo refer, todos los atributos y elementos-hijos definidos por el elemento
referido son heredados. Todos los otros atributos y elementos-hijos, si son definidos por el elemento que realiza la
referencia, deben ser obligatoriamente ignorados por el formateador, excepto el atributo id que se debe definir
obligatoriamente. La única otra excepción es para elementos <media>, para los cuales nuevos elementos-hijos
<area> y <property> pueden ser agregados, y se puede definir un nuevo atributo, instance.
Si el nuevo elemento <property> agregado tiene el mismo atributo name de un elemento <property> ya existente
(definido en el elemento <media> reutilizado), el nuevo elemento <property> agregado debe ser obligatoriamente
ignorado. Igualmente, si el nuevo elemento <area> agregado tiene el mismo atributo id de un elemento <area> ya
existente (definido en el elemento <media> reutilizado), el nuevo elemento <area> agregado debe ser
obligatoriamente ignorado. El atributo instance se define en el módulo ExtendedEntityReuse y tiene “new” como
su valor default de string.
El elemento referido y el elemento que le hace referencia deben ser obligatoriamente considerados el mismo, con
relación a sus estructuras de datos. En otras palabras, eso significa que un nudo NCM puede ser representado
por más que un elemento NCL. Como nudos contenidos en un nudo de composición NCM definen un conjunto, un
nudo NCM puede ser representado por no más que un elemento NCL dentro de una composición. Eso significa
que el atributo id de un elemento NCL representando un nudo NCM no es sólo un identificador único para el
elemento, sino el único identificador correspondiente al nudo NCM en la composición.
NOTA
Se puede consultar la NCMCore:2005 para otras informaciones.
EJEMPLO
Suponiendo que el elemento NCL (node1) representa un nudo NCM, los elementos NCL que lo mencionan
(node1ReuseA, node1ReuseB) representan el mismo nudo NCM. En otras palabras, el nudo NCM único es representado por
más de un elemento NCL (node1, node1ReuseA, y node1ReuseB). Más aún, como los nudos contenidos en un nudo de
composición NCM definen un conjunto, cada uno de los elementos NCL, node1, node1ReuseA y node1ReuseB, debe ser
declarado dentro de una composición diferente.
El elemento referido y el elemento que le hace referencia también deben ser obligatoriamente considerados el
mismo nudo con relación a su estructura de presentación, si el atributo instance recibe un valor “instSame” o
“gradSame”. Por lo tanto, la siguiente semántica debe ser obligatoriamente respetada. Considere el conjunto de
elementos <media> compuesto por el elemento <media> referido y todos los elementos <media> que lo
mencionan. Si cualquier elemento del subconjunto formado por el elemento <media> referido y todos los otros
elementos <media> que tienen el atributo instance igual a “instSame” o “gradSame” estuvieran programados para
ser presentados, se presume que todos los otros elementos en ese subconjunto, que no son descendentes de un
elemento <switch>, están también programados para presentación y, más que eso, cuando éstos se presentan,
deben ser obligatoriamente representados por la misma instancia de presentación. Los elementos descendentes
de un elemento <switch> también deben tener obligatoriamente el mismo comportamiento, si todas las reglas
necesarias para presentarlos se cumplen; en caso contrario, no deben ser programados para presentación. Si el
atributo instance fuera igual a “instSame”, todos los nudos programados del subconjunto deben ser presentados
obligatoriamente en una única instancia, inmediatamente (la instrucción star aplicada en todos los elementos del
subconjunto simultáneamente). Si el atributo instance fuera igual a “gradSame”, todos los nudos programados son
presentados en una única instancia, pero gradualmente, a medida que van sufriendo la instrucción star,
procedente de eslabones etc.. La instancia común en presentación debe obligatoriamente notificar todos los
eventos asociados con los elementos <area> y <property> definidos en todos los elementos <media> del
subconjunto que fueron programados para presentación. Por otro lado, los elementos <media> en el conjunto que
tiene valores de atributo instance iguales a “new” obligatoriamente no deben ser programados para presentación.
© ABNT 2007 - Todos los derechos reservados
59
ABNT NBR 15606-2:2007
Cuando son individualmente programados para presentación, ningún otro elemento del conjunto tiene su
comportamiento afectado, y más aún, nuevas instancias independientes de presentación deben ser
obligatoriamente creadas a cada inicio individual de presentación.
7.2.12 Área funcional Navigational Key
El área funcional Navigational Key define el módulo KeyNavigation que ofrece las extensiones necesarias para
describir las operaciones de movimiento del foco, definido por un dispositivo, como un control remoto.
Básicamente, el módulo define atributos que pueden ser incorporados por elementos <descriptor>.
El atributo focusIndex especifica un índice para el elemento <media> sobre el cual el foco puede ser aplicado,
cuando ese elemento esté en exhibición, utilizando el elemento <descriptor> que definió el atributo. Cuando un
elemento <descriptor> no define ese atributo, se considera como si no pudiese recibir el foco. En un determinado
momento de la presentación, si el foco no ha sido aún definido, o si está perdido, un foco será inicialmente
aplicado al elemento que esté siendo presentado cuyo descriptor tenga el menor valor de índice.
Los valores del atributo focusIndex deben ser obligatoriamente únicos en un documento NCL. En caso contrario,
los atributos repetidos deben ser obligatoriamente ignorados, si en un momento dado hubiera más de un
elemento <media> recibiendo el foco. Además, cuando un elemento <media> hace referencia a otro elemento
<media> (utilizando el atributo refer especificado en 7.2.11), debe obligatoriamente ignorar el focusIndex
especificado por el elemento <descriptor> asociado al elemento <media> referido.
El atributo moveUp especifica un valor igual al valor del focusIndex asociado al elemento sobre el cual será
aplicado el foco cuando sea presionada la tecla “flecha hacia arriba” (“up arrow key”). El atributo moveDown
especifica un valor igual al valor del focusIndex asociado al elemento sobre el cual el foco será aplicado cuando
sea presionada la tecla “flecha hacia abajo” (“down arrow key”).
El atributo moveRight especifica un valor igual al valor del focusIndex asociado al elemento sobre el cual el foco
será aplicado cuando la tecla “flecha para la derecha “(“right arrow key”) sea presionada. El atributo moveLeft
especifica un valor igual al valor del focusIndex asociado al elemento sobre el cual el foco será aplicado cuando la
tecla “flecha para la izquierda” (“left arrow key”) sea presionada.
Cuando el foco se aplica a un elemento con la propiedad de visibilidad con el valor “false”, o a un elemento que
no está siendo presentado, el foco actual no debe moverse.
El atributo focusSrc puede especificar un contenido alternativo a ser presentado, en vez del contenido de la
presentación actual, si un elemento recibe el foco. Ese atributo sigue las mismas reglas del atributo src del
elemento <media>.
Cuando un elemento recibe un foco, el marco (box) definido por los atributos de posicionamiento del elemento
debe ser obligatoriamente destacado. El atributo focusBorderColor define el color de destaque y puede recibir los
nombres reservados de color: “white”, “black”, “silver”, “gray”, “red”, “maroon”, “fuchsia”, “purple”, “lime”, “green”,
“yellow”, “olive”, “blue”, “navy”, “aqua”, o “teal”. El atributo focusBorder Width define el ancho en pixels del borde
en destaque (0 significa que no aparece ningún borde, valores positivos significan que el borde está fuera del
contenido del objeto y valores negativos significan que el borde se dibuja sobre el contenido del objeto); el atributo
focusBorderTransparency define la transparencia del color de destaque. El focusBorderTransparency debe ser
obligatoriamente un valor real entre 0 1, o un valor real en la banda [0,100] terminando con el carácter “%” (por
ejemplo, 30 %), con “1” ó “100 %” significando transparencia total y “0” ó “0 %” significando ninguna transparencia.
Cuando el focusBorderColor, el focusBorderWidth o el focusBorderTransparency no están definidos, valores
default deben ser obligatoriamente asumidos. Esos valores se especifican en las propiedades del elemento
<media> del tipo application/x-Ginga-settings: DefaultFocusBorderColor, defaultFocusBorderWidth y defaultFocus
Transparency, respectivamente.
Cuando un elemento en foco es seleccionado presionando la tecla de activación, el atributo focusSelSrc puede
especificar un contenido de media alternativo a ser presentado, en vez de la presentación actual. Este atributo
sigue las mismas reglas del atributo src del elemento <media>. Cuando esté seleccionada, la caja definida por los
atributos de posicionamiento de elemento debe ser obligatoriamente destacada con el color definido por el
atributo selBorderColor (valor-default especificado por el defaultSelBorderColor del elemento <media> del tipo
60
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
application/xginga-settings), el ancho del borde en destaque es definido por el atributo focusBorder Width y la
transparencia del color del borde es definida por el atributo focusBorderTransparency.
Cuando un elemento en foco es seleccionado presionando la tecla de activación, el control del foco debe ser
obligatoriamente pasado al exhibidor del elemento <media> (player). El exhibidor puede entonces seguir sus
propias reglas para navegación. El control de foco debe ser obligatoriamente devuelto al formateador NCL cuando
la tecla “back” es presionada. En ese caso, el foco va para el elemento identificado por el atributo
service.currentFocus del nudo settings (elemento <media> del tipo application/x-ginga-settings.
NOTA
El control del foco puede también ser pasado alterando el valor del atributo service.currentKeyMaster del nudo
settings (elemento <media> del tipo applicaton/x-ginga-settins). Esto se puede hacer vía acción de un eslabón (<link> element),
vía un comando ejecutado por un código imperativo de un nudo (objeto NCLua o NCLet), o por el exhibidor del nudo que
detenta el control corriente.
7.2.13 Área funcional Animation
Animación es en realidad una combinación de dos factores: soporte al dibujo del objeto y soporte al movimiento
del objeto o, más propiamente, soporte para la alteración del objeto en función del tiempo.
NCL no es un formato de contenido y, como tal, no tiene soporte para la creación de objetos de media y no tiene
un método generalizado para alterar el contenido del objeto de media. Al contrario, NCL es un formato de
escalonamiento y orquestación. Eso significa que NCL no se puede utilizar para hacer dibujos animados, pero se
puede utilizar para exhibir objetos de dibujo animado en el contexto de una presentación general y para alterar las
propiedades de sincronización y exhibición de un objeto de un dibujo animado (o cualquier otro) globalmente,
mientras el objeto esté siendo exhibido.
Las primitivas de animación NCL permiten que los valores de propiedades de los nudos sean alterados durante
una duración determinada. Como la animación NCL puede ser computacionalmente intensa, solamente es
soportada por el perfil EDTV y sólo las propiedades que definen valores numéricos y colores pueden ser
animadas.
El área funcional Animation define el módulo Animation que suministra las extensiones necesarias para describir
qué pasa cuando el valor de una propiedad de un nudo es alterado. Básicamente, el módulo define atributos que
pueden ser incorporados por los elementos <simpleAction> de un conector, si su valor eventType es “attribution”.
Dos nuevos atributos son definidos: duration e by.
Al atribuir un nuevo valor para una propiedad, la alteración es instantánea por default (duration=”0”), pero la
alteración también se puede realizar durante un período explícitamente declarado, especificado por el atributo
duration.
Además de ello, al atribuir un nuevo valor a una propiedad, la alteración del valor antiguo para el nuevo puede ser
lineal por default (by=”indefinite”), o hecha paso a paso, con el paso especificado por el atributo by.
La combinación de las definiciones de los atributos duration y by ofrece la definición de cómo (de forma discreta o
lineal) la alteración se debe realizar obligatoriamente y su intervalo de transformación.
7.2.14 Área funcional SMIL Transition Effects
El área funcional Transition Effects se divide en dos módulos: TransitionBase y Transition.
NOTA
Se puede consultar el SMIL 2.1 Specification:2005 para otras informaciones.
El módulo TransitionBase es definido por la NCL 3.0 y consiste en un elemento <transitionBase> que especifica
un conjunto de efectos de transición y se debe definir obligatoriamente como elemento-hijo del elemento <head>.
El elemento <transitionBase>, sus elementos-hijos y sus atributos deben estar de acuerdo obligatoriamente con la
Tabla 35.
© ABNT 2007 - Todos los derechos reservados
61
ABNT NBR 15606-2:2007
Tabla 35 — Módulo TransitionBase extendido
Elementos
transitionBase
Atributos
id
Contenido
(importBase, transition)+
El módulo Transition está basado en las especificaciones SMIL 2.1. El módulo solamente tiene un elemento
llamado <transition>.
NOTA
Se puede consultar el SMIL 2.1 Specification, 2005 para otras informaciones.
En el perfil NCL 3.0 DTV Avanzado, el elemento <transition> se especifica en el elemento <transitionBase> y
permite que sea definido un estándar (template) de transición. Cada elemento <transition> define un estándar
único de transición y debe tener obligatoriamente un atributo id para que pueda ser referido dentro de un
elemento <descriptor>.
Siete atributos del elemento <transition> son derivados de la especificación del módulo BasicTransitions de SMIL:
type; subtype; dur; startProgress; endProgress; direction; y fadeColor.
Las transiciones se clasifican de acuerdo con una taxonomía de dos niveles: tipos y subtipos. Cada tipo de
transición describe un grupo de transiciones que están íntimamente relacionadas. Dentro de ese tipo, cada una
de las transiciones individuales se asocia a un subtipo que enfatiza las características distintas de la transición.
El atributo type es obligatorio y utilizado para especificar la transición general. Si el tipo nominado no es soportado
por el formateador NCL, la transición debe ser obligatoriamente ignorada. Eso no es una condición de error, pues
las implementaciones son libres para ignorar transiciones.
El atributo subtype suministra el control específico para la transición. Ese atributo es opcional y, si es especificado,
debe ser obligatoriamente uno de los subtipos de transición apropiados para el tipo correspondiente. Si ese
atributo no se especifica, la transición debe ser obligatoriamente revertida para el subtipo default del tipo
especificado. Sólo los subtipos para los cinco tipos de transición obligatorios, listados en la Tabla 36, deben ser
obligatoriamente soportados; los otros tipos y subtipos definidos en la especificación SMIL son opcionales.
Tabla 36 — Tipos y subtipos de transición exigidos
Tipo de transition
Subtipo default
barWipe
leftToRight
irisWipe
rectangle
clockWipe
clockwiseTwelve
snakeWipe
topLeftHorizontal
fade
crossfade
El atributo dur especifica la duración de la transición. La duración default es de 1 s.
El atributo startProgress especifica la cantidad de efecto de transición del inicio de la ejecución. Los valores
permitidos son números reales en la banda [0.0,1.0]. Por ejemplo, puede quererse iniciar un crossfade con
imagen destino ya transparente en 30 % inicialmente. Para ese caso, el startProgress sería 0.3. El valor default es
0.0.
El atributo endProgress especifica la cantidad de efecto de transición al término de la ejecución. Los valores
permitidos son números reales en la banda [0.0,1.0] y el valor de ese atributo debe ser obligatoriamente mayor o
igual al valor del atributo startProgress. Si endProgress es igual a startProgress, entonces la transmisión
permanece en un valor fijo por la duración de la transmisión. El valor default es 1,0.
El atributo direction especifica la dirección en que ocurrirá la transición. Los valores permitidos son “forward”
“reverse”. El valor default es “forward”. No todas las transiciones tendrán interpretaciones reversas significantes.
62
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
Por ejemplo, un crossfade no es una transición geométrica y, por lo tanto, no tiene interpretación de dirección
reversa. Las transiciones que no tienen interpretación reversa deben tener el atributo direction ignorado y el valor
default "forward" asumido.
Si el valor del atributo type es “fade” y el valor del atributo subtype es “fadeToColor” o “fadeFromColor” (valores de
subtipo que no son obligatorios en una implementación Ginga), entonces el atributo fadeColor especifica el color
final o inicial del fade. Si el valor del atributo type no es “fade”, o si el valor del atributo subtype no es
“fadeToColor” o “fadeFromColor”, entonces el atributo fadeColor debe ser obligatoriamente ignorado. El valor
default es “black”.
El módulo Transition también define los atributos a ser utilizados en los elementos <descriptor>, para los
estándares de transición definidos por los elementos <transition>: atributos transIn y transOut. Las transiciones
especificadas con un atributo transIn empezarán en el comienzo de la duración activa de los elementos de media
(cuando la presentación del objeto empieza). Las transiciones especificadas con un atributo transOut terminarán
al final de la duración activa de los elementos de media (cuando la presentación del objeto pasa del estado
ocurriendo a preparado).
Los atributos transIn y transOut son agregados a los elementos <descriptor>. El valor default de ambos atributos
es una string vacía, que indica que, obligatoriamente, ninguna transición se debe realizar.
El valor de los atributos transIn y transOut es una lista separada por punto y coma de los identificadores de
transición. Cada uno de los identificadores debe corresponder obligatoriamente al valor del identificador XML de
uno de los elementos de transición anteriormente definidos en el elemento <transitionBase>. El alcance de la lista
separada por punto y coma es permitir que los autores especifiquen un conjunto de transiciones alternativas
(fallback) si la transición preferida no está disponible.
La primera transición en la lista se debe realizar si el agente del usuario implementa esta transición. Si esa
transición no está disponible, entonces la segunda transición en la lista se debe realizar, y así sucesivamente.
Si el valor del atributo transIn o transOut no corresponde al valor del identificador XML de ninguno de los
elementos de transición previamente definidos, entonces hay un error. En caso de ocurrir ese error, el valor del
atributo que se debe considerar como siendo una string vacía y, entonces, obligatoriamente, ninguna transición se
debe realizar.
Todas las transiciones definidas en el módulo Transition aceptan cuatro atributos adicionales (procedentes de la
especificación del módulo TranstionModifiers de SMIL) que se pueden utilizar para controlar la apariencia de las
transiciones. El atributo horRepeat especifica cuántas veces se realizará el estándar de transiciones a lo largo del
eje horizontal. El valor default es 1 (el estándar ocurre una vez horizontalmente). El atributo vertRepeat especifica
cuántas veces se realizará el estándar de transición a lo largo del eje vertical. El valor default es 1 (el estándar
ocurre una vez verticalmente). El atributo borderWidth especifica el ancho de un borde generado a lo largo de un
área apagada. Los valores permitidos son enteros mayores o iguales a 0. Si el valor de borderWidth es igual a 0,
entonces conviene que ningún borde se genere a lo largo del área apagada. El valor default es 0. Si el valor del
atributo type no es "fade", entonces el atributo borderColor especifica el contenido de un borde generado a lo
largo de un área apagada. Si el valor de ese atributo es un color, entonces el borde generado se rellena con el
color definido. Si el valor de este atributo es “blend”, entonces el borde generado es una mezcla aditiva (o blur) de
las fuentes de media. El valor default para ese atributo es “black”.
El elemento del módulo Transition extendido, sus elementos-hijos y sus atributos deben estar de acuerdo
obligatoriamente con la Tabla 37.
Tabla 37 — Módulo Transition extendido
Elementos
transition
© ABNT 2007 - Todos los derechos reservados
Atributos
id, type, subtype, dur,
startProgress, endProgress,
direction, fadeColor, horRepeat,
vertRepeat, borderWidth,
borderColor
Contenido
vacío
63
ABNT NBR 15606-2:2007
7.2.15 Área funcional Metainformation
Una metainformación no contiene informaciones de contenido utilizadas o exhibidas durante la presentación de un
documento. En vez de eso, contiene informaciones sobre el contenido utilizado o exhibido. El área funcional
Metainformation está compuesta por el módulo metainformation, derivado del módulo Metainformation SMIL.
El elemento <meta> especifica un único par de propiedad/valor en los atributos name y content, respectivamente.
El elemento <metadata> contiene informaciones que también se relacionan con la metainformación del documento.
Actúa como el elemento raíz del árbol RDF. El elemento <metadata> puede tener como elementos-hijos:
Elementos RDF y sus subelementos
NOTA
Se puede consultar la RDF:1999 para otras informaciones.
Los elementos del módulo Metainformation, sus elementos-hijos y sus atributos deben estar de acuerdo
obligatoriamente con la Tabla 38.
Tabla 38 — Módulo Meta-Information extendido
Elementos
Atributos
Contenido
meta
name, content
vacío
metadata
empty
RDF tree
7.3 Perfiles del lenguaje NCL para el SBTVD
7.3.1
Módulos de perfiles
Cada perfil NCL puede agrupar un subconjunto de módulos NCL, permitiendo la creación de lenguajes de
acuerdo con las necesidades de los usuarios.
Cualquier documento de conformidad con los perfiles NCL debe tener obligatoriamente el elemento <ncl> como
su elemento-raíz.
El perfil NCL 3.0 completo, también denominado perfil Lenguaje NCL 3.0, es el “perfil completo” del lenguaje NCL
3.0. Comprende todos los módulos NCL (incluso los discutidos en 7.2) y suministra todas las facilidades para la
autoría declarativa de documentos NCL.
Los perfiles definidos para el SBTVD son:
a)
perfil NCL 3.0 DTV Avanzado: el perfil NCL 3.0 DTV Avanzado incluye los módulos: Structure, Layout, Media,
Context, MediaContentAnchor, CompositeNodeInterface, PropertyAnchor, SwitchInterface, Descriptor, Linking,
CausalConnectorFunctionality, ConnectorBase, TestRule, TestRuleUse, ContentControl, DescriptorControl,
Timing, Import, EntityReuse, ExtendedEntityReuse KeyNavigation, Animation, TransitionBase, Transition y
Meta-information de la NCL 3.0. Las tablas presentadas en 7.2 muestran cada elemento de cada módulo, ya
extendidos por los atributos y elementos hijos heredados de otros módulos por ese perfil (ver los esquemas
XML en 7.3.2);
b)
perfil NCL 3.0 CausalConnector: el perfil CausalConnector permite la creación de conectores simples
hipermedia. El perfil incluye los módulos Structure, CausalConnectorFunctionality y ConnectorBase. En el
perfil, el elemento <body> del módulo Structure no se utiliza (ver los esquemas XML en 7.3.3);
c)
perfil NCL 3.0 DTV Básico: el perfil NCL 3.0 DTV Básico incluye los módulos Structure, Layout, Media,
Context, MediaContentAnchor, CompositeNodeInterface, PropertyAnchor, SwitchInterface, Descriptor, Linking,
CausalConnectorFunctionality, ConnectorBase, TestRule, TestRuleUse, ContentControl, DescriptorControl,
Timing, Import, EntityReuse, ExtendedEntityReuse y KeyNavigation. Las tablas presentadas en 7.3.4
muestran cada elemento de cada módulo de ese perfil, ya extendidos por los atributos y elementos-hijos
heredados de otros módulos (ver los esquemas XML en 7.3.5).
64
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
7.3.2
Esquema del perfil NCL 3.0 DTV avanzado
NCL30EDTV.xsd
<!-XML Schema for the NCL Language
This is NCL
Copyright: 2000-2005 PUC-RIO/LABORATORIO TELEMIDIA, All Rights Reserved.
See http://www.telemidia.puc-rio.br
Public URI: http://www.ncl.org.br/NCL3.0/profiles/NCL30EDTV.xsd
Author: TeleMidia Laboratory
Revision: 19/09/2006
-->
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:animation="http://www.ncl.org.br/NCL3.0/Animation"
xmlns:compositeInterface="http://www.ncl.org.br/NCL3.0/CompositeNodeInterface"
xmlns:causalConnectorFunctionality="http://www.ncl.org.br/NCL3.0/CausalConnectorFunctionality"
xmlns:connectorBase="http://www.ncl.org.br/NCL3.0/ConnectorBase"
xmlns:connectorCausalExpression="http://www.ncl.org.br/NCL3.0/ConnectorCausalExpression"
xmlns:contentControl="http://www.ncl.org.br/NCL3.0/ContentControl"
xmlns:context="http://www.ncl.org.br/NCL3.0/Context"
xmlns:descriptor="http://www.ncl.org.br/NCL3.0/Descriptor"
xmlns:entityReuse="http://www.ncl.org.br/NCL3.0/EntityReuse"
xmlns:extendedEntityReuse="http://www.ncl.org.br/NCL3.0/ExtendedEntityReuse"
xmlns:descriptorControl="http://www.ncl.org.br/NCL3.0/DescriptorControl"
xmlns:import="http://www.ncl.org.br/NCL3.0/Import"
xmlns:keyNavigation="http://www.ncl.org.br/NCL3.0/KeyNavigation"
xmlns:layout="http://www.ncl.org.br/NCL3.0/Layout"
xmlns:linking="http://www.ncl.org.br/NCL3.0/Linking"
xmlns:media="http://www.ncl.org.br/NCL3.0/Media"
xmlns:mediaAnchor="http://www.ncl.org.br/NCL3.0/MediaContentAnchor"
xmlns:propertyAnchor="http://www.ncl.org.br/NCL3.0/PropertyAnchor"
xmlns:structure="http://www.ncl.org.br/NCL3.0/Structure"
xmlns:switchInterface="http://www.ncl.org.br/NCL3.0/SwitchInterface"
xmlns:testRule="http://www.ncl.org.br/NCL3.0/TestRule"
xmlns:testRuleUse="http://www.ncl.org.br/NCL3.0/TestRuleUse"
xmlns:timing="http://www.ncl.org.br/NCL3.0/Timing"
xmlns:transitionBase="http://www.ncl.org.br/NCL3.0/TransitionBase"
xmlns:metainformation="http://www.ncl.org.br/NCL3.0/Metainformation"
xmlns:transition="http://www.ncl.org.br/NCL3.0/Transition"
xmlns:metainformation="http://www.w3.org/2001/SMIL20/Metainformation"
xmlns:basicTransition="http://www.w3.org/2001/SMIL20/BasicTransitions"
xmlns:profile="http://www.ncl.org.br/NCL3.0/EDTVProfile"
targetNamespace="http://www.ncl.org.br/NCL3.0/EDTVProfile"
elementFormDefault="qualified" attributeFormDefault="unqualified" >
<!-- import the definitions in the modules namespaces -->
<import namespace="http://www.ncl.org.br/NCL3.0/Animation"
schemaLocation="http://www.ncl.org.br/NCL3.0/modules/NCL30Animation.xsd"/>
<import namespace="http://www.ncl.org.br/NCL3.0/CompositeNodeInterface"
schemaLocation="http://www.ncl.org.br/NCL3.0/modules/NCL30CompositeNodeInterface.xsd"/>
<import namespace="http://www.ncl.org.br/NCL3.0/CausalConnectorFunctionality"
schemaLocation="http://www.ncl.org.br/NCL3.0/modules/NCL30CausalConnectorFunctionality.xsd"/>
<import namespace="http://www.ncl.org.br/NCL3.0/ConnectorBase"
schemaLocation="http://www.ncl.org.br/NCL3.0/modules/NCL30ConnectorBase.xsd"/>
<import namespace="http://www.ncl.org.br/NCL3.0/ConnectorCausalExpression"
schemaLocation="http://www.ncl.org.br/NCL3.0/modules/NCL30ConnectorCausalExpression.xsd"/>
<import namespace="http://www.ncl.org.br/NCL3.0/ContentControl"
schemaLocation="http://www.ncl.org.br/NCL3.0/modules/NCL30ContentControl.xsd"/>
<import namespace="http://www.ncl.org.br/NCL3.0/Context"
schemaLocation="http://www.ncl.org.br/NCL3.0/modules/NCL30Context.xsd"/>
© ABNT 2007 - Todos los derechos reservados
65
ABNT NBR 15606-2:2007
<import namespace="http://www.ncl.org.br/NCL3.0/Descriptor"
schemaLocation="http://www.ncl.org.br/NCL3.0/modules/NCL30Descriptor.xsd"/>
<import namespace="http://www.ncl.org.br/NCL3.0/DescriptorControl"
schemaLocation="http://www.ncl.org.br/NCL3.0/modules/NCL30DescriptorControl.xsd"/>
<import namespace="http://www.ncl.org.br/NCL3.0/EntityReuse"
schemaLocation="http://www.ncl.org.br/NCL3.0/modules/NCL30EntityReuse.xsd"/>
<import namespace="http://www.ncl.org.br/NCL3.0/ExtendedEntityReuse"
schemaLocation="http://www.ncl.org.br/NCL3.0/modules/NCL30ExtendedEntityReuse.xsd"/>
<import namespace="http://www.ncl.org.br/NCL3.0/Import"
schemaLocation="http://www.ncl.org.br/NCL3.0/modules/NCL30Import.xsd"/>
<import namespace="http://www.ncl.org.br/NCL3.0/KeyNavigation"
schemaLocation="http://www.ncl.org.br/NCL3.0/modules/NCL30KeyNavigation.xsd"/>
<import namespace="http://www.ncl.org.br/NCL3.0/Layout"
schemaLocation="http://www.ncl.org.br/NCL3.0/modules/NCL30Layout.xsd"/>
<import namespace="http://www.ncl.org.br/NCL3.0/Linking"
schemaLocation="http://www.ncl.org.br/NCL3.0/modules/NCL30Linking.xsd"/>
<import namespace="http://www.ncl.org.br/NCL3.0/Media"
schemaLocation="http://www.ncl.org.br/NCL3.0/modules/NCL30Media.xsd"/>
<import namespace="http://www.ncl.org.br/NCL3.0/MediaContentAnchor"
schemaLocation="http://www.ncl.org.br/NCL3.0/modules/NCL30MediaContentAnchor.xsd"/>
<import namespace="http://www.ncl.org.br/NCL3.0/PropertyAnchor"
schemaLocation="http://www.ncl.org.br/NCL3.0/modules/NCL30PropertyAnchor.xsd"/>
<import namespace="http://www.ncl.org.br/NCL3.0/Structure"
schemaLocation="http://www.ncl.org.br/NCL3.0/modules/NCL30Structure.xsd"/>
<import namespace="http://www.ncl.org.br/NCL3.0/SwitchInterface"
schemaLocation="http://www.ncl.org.br/NCL3.0/modules/NCL30SwitchInterface.xsd"/>
<import namespace="http://www.ncl.org.br/NCL3.0/TestRule"
schemaLocation="http://www.ncl.org.br/NCL3.0/modules/NCL30TestRule.xsd"/>
<import namespace="http://www.ncl.org.br/NCL3.0/TestRuleUse"
schemaLocation="http://www.ncl.org.br/NCL3.0/modules/NCL30TestRuleUse.xsd"/>
<import namespace="http://www.ncl.org.br/NCL3.0/Timing"
schemaLocation="http://www.ncl.org.br/NCL3.0/modules/NCL30Timing.xsd"/>
<import namespace="http://www.ncl.org.br/NCL3.0/TransitionBase"
schemaLocation="http://www.ncl.org.br/NCL3.0/modules/NCL30TransitionBase.xsd"/>
<import namespace="http://www.ncl.org.br/NCL3.0/Metainformation"
schemaLocation="http://www.ncl.org.br/NCL3.0/modules/NCL30Metainformation.xsd"/>
<import namespace="http://www.ncl.org.br/NCL3.0/Transition"
schemaLocation="http://www.ncl.org.br/NCL3.0/modules/NCL30Transition.xsd"/>
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- Structure
-->
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- extends ncl element -->
<element name="ncl" substitutionGroup="structure:ncl"/>
<!-- extends head element -->
<complexType name="headType">
<complexContent>
<extension base="structure:headPrototype">
<sequence>
<element ref="profile:importedDocumentBase" minOccurs="0" maxOccurs="1"/>
<element ref="profile:ruleBase" minOccurs="0" maxOccurs="1"/>
<element ref="profile:transitionBase" minOccurs="0" maxOccurs="1"/>
<element ref="profile:regionBase" minOccurs="0" maxOccurs="unbounded"/>
<element ref="profile:descriptorBase" minOccurs="0" maxOccurs="1"/>
<element ref="profile:connectorBase" minOccurs="0" maxOccurs="1"/>
<element ref="profile:meta" minOccurs="0" maxOccurs="unbounded"/>
<element ref="profile:metadata" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
66
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
<element name="head" type="profile:headType" substitutionGroup="structure:head"/>
<!-- extends body element -->
<complexType name="bodyType">
<complexContent>
<extension base="structure:bodyPrototype">
<choice minOccurs="0" maxOccurs="unbounded">
<group ref="profile:contextInterfaceElementGroup"/>
<element ref="profile:media"/>
<element ref="profile:context"/>
<element ref="profile:switch"/>
<element ref="profile:link"/>
<element ref="profile:meta"/>
<element ref="profile:metadata"/>
</choice>
</extension>
</complexContent>
</complexType>
<element name="body" type="profile:bodyType" substitutionGroup="structure:body"/>
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- Layout
-->
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- extends regionBase element -->
<complexType name="regionBaseType">
<complexContent>
<extension base="layout:regionBasePrototype">
<choice minOccurs="1" maxOccurs="unbounded">
<element ref="profile:importBase"/>
<element ref="profile:region"/>
</choice>
</extension>
</complexContent>
</complexType>
<complexType name="regionType">
<complexContent>
<extension base="layout:regionPrototype">
</extension>
</complexContent>
</complexType>
<element name="regionBase" type="profile:regionBaseType" substitutionGroup="layout:regionBase"/>
<element name="region" type="profile:regionType" substitutionGroup="layout:region"/>
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- Media
-->
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- extends Media elements -->
<!-- media interface element groups -->
<group name="mediaInterfaceElementGroup">
<choice>
<element ref="profile:area"/>
<element ref="profile:property"/>
</choice>
</group>
<complexType name="mediaType">
<complexContent>
<extension base="media:mediaPrototype">
© ABNT 2007 - Todos los derechos reservados
67
ABNT NBR 15606-2:2007
<choice minOccurs="0" maxOccurs="unbounded">
<group ref="profile:mediaInterfaceElementGroup"/>
</choice>
<attributeGroup ref="descriptor:descriptorAttrs"/>
<attributeGroup ref="entityReuse:entityReuseAttrs"/>
<attributeGroup ref="extendedEntityReuse:extendedEntityReuseAttrs"/>
</extension>
</complexContent>
</complexType>
<element name="media" type="profile:mediaType" substitutionGroup="media:media"/>
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- Context
-->
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- extends context element -->
<!-- composite node interface element groups -->
<group name="contextInterfaceElementGroup">
<choice>
<element ref="profile:port"/>
<element ref="profile:property"/>
</choice>
</group>
<complexType name="contextType">
<complexContent>
<extension base="context:contextPrototype">
<choice minOccurs="0" maxOccurs="unbounded">
<group ref="profile:contextInterfaceElementGroup"/>
<element ref="profile:media"/>
<element ref="profile:context"/>
<element ref="profile:link"/>
<element ref="profile:switch"/>
<element ref="profile:meta"/>
<element ref="profile:metadata"/>
</choice>
<attributeGroup ref="entityReuse:entityReuseAttrs"/>
</extension>
</complexContent>
</complexType>
<element name="context" type="profile:contextType" substitutionGroup="context:context"/>
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- MediaContentAnchor
-->
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- extends area element -->
<complexType name="componentAnchorType">
<complexContent>
<extension base="mediaAnchor:componentAnchorPrototype">
</extension>
</complexContent>
</complexType>
<element name="area" type="profile:componentAnchorType" substitutionGroup="mediaAnchor:area"/>
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- CompositeNodeInterface
-->
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- extends port element -->
<complexType name="compositeNodePortType">
<complexContent>
68
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
<extension base="compositeInterface:compositeNodePortPrototype">
</extension>
</complexContent>
</complexType>
<element name="port" type="profile:compositeNodePortType" substitutionGroup="compositeInterface:port"/>
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- PropertyAnchor
-->
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- extends property element -->
<complexType name="propertyAnchorType">
<complexContent>
<extension base="propertyAnchor:propertyAnchorPrototype">
</extension>
</complexContent>
</complexType>
<element name="property" type="profile:propertyAnchorType" substitutionGroup="propertyAnchor:property"/>
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- SwitchInterface
-->
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- extends switchPort element -->
<complexType name="switchPortType">
<complexContent>
<extension base="switchInterface:switchPortPrototype">
</extension>
</complexContent>
</complexType>
<element name="mapping" substitutionGroup="switchInterface:mapping"/>
<element name="switchPort" type="profile:switchPortType" substitutionGroup="switchInterface:switchPort"/>
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- Descriptor
-->
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- substitutes descriptorParam element -->
<element name="descriptorParam" substitutionGroup="descriptor:descriptorParam"/>
<!-- extends descriptor element -->
<complexType name="descriptorType">
<complexContent>
<extension base="descriptor:descriptorPrototype">
<attributeGroup ref="layout:regionAttrs"/>
<attributeGroup ref="timing:explicitDurAttrs"/>
<attributeGroup ref="timing:freezeAttrs"/>
<attributeGroup ref="keyNavigation:keyNavigationAttrs"/>
<attributeGroup ref="transition:transAttrs"/>
</extension>
</complexContent>
</complexType>
<element name="descriptor" type="profile:descriptorType" substitutionGroup="descriptor:descriptor"/>
<!-- extends descriptorBase element -->
<complexType name="descriptorBaseType">
<complexContent>
<extension base="descriptor:descriptorBasePrototype">
<choice minOccurs="1" maxOccurs="unbounded">
© ABNT 2007 - Todos los derechos reservados
69
ABNT NBR 15606-2:2007
<element ref="profile:importBase"/>
<element ref="profile:descriptor"/>
<element ref="profile:descriptorSwitch"/>
</choice>
</extension>
</complexContent>
</complexType>
<element name="descriptorBase" type="profile:descriptorBaseType" substitutionGroup="descriptor:descriptorBase"/>
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- Linking
-->
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- substitutes linkParam and bindParam elements -->
<element name="linkParam" substitutionGroup="linking:linkParam"/>
<element name="bindParam" substitutionGroup="linking:bindParam"/>
<!-- extends bind element and link element, as a consequence-->
<complexType name="bindType">
<complexContent>
<extension base="linking:bindPrototype">
<attributeGroup ref="descriptor:descriptorAttrs"/>
</extension>
</complexContent>
</complexType>
<element name="bind" type="profile:bindType" substitutionGroup="linking:bind"/>
<!-- extends link element -->
<complexType name="linkType">
<complexContent>
<extension base="linking:linkPrototype">
</extension>
</complexContent>
</complexType>
<element name="link" type="profile:linkType" substitutionGroup="linking:link"/>
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- Connector
-->
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- extends connectorBase element -->
<complexType name="connectorBaseType">
<complexContent>
<extension base="connectorBase:connectorBasePrototype">
<choice minOccurs="0" maxOccurs="unbounded">
<element ref="profile:importBase"/>
<element ref="profile:causalConnector" />
</choice>
</extension>
</complexContent>
</complexType>
<complexType name="simpleActionType">
<complexContent>
<extension base="connectorCausalExpression:simpleActionPrototype">
<attributeGroup ref="animation:animationAttrs"/>
</extension>
</complexContent>
</complexType>
<element name="connectorBase" type="profile:connectorBaseType" substitutionGroup="connectorBase:connectorBase"/>
70
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
<element name="causalConnector" substitutionGroup="causalConnectorFunctionality:causalConnector"/>
<element name="connectorParam" substitutionGroup="causalConnectorFunctionality:connectorParam"/>
<element name="simpleCondition" substitutionGroup="causalConnectorFunctionality:simpleCondition"/>
<element name="compoundCondition" substitutionGroup="causalConnectorFunctionality:compoundCondition"/>
<element name="simpleAction" type="profile:simpleActionType"
substitutionGroup="causalConnectorFunctionality:simpleAction"/>
<element name="compoundAction" substitutionGroup="causalConnectorFunctionality:compoundAction"/>
<element name="assessmentStatement" substitutionGroup="causalConnectorFunctionality:assessmentStatement"/>
<element name="attributeAssessment" substitutionGroup="causalConnectorFunctionality:attributeAssessment"/>
<element name="valueAssessment" substitutionGroup="causalConnectorFunctionality:valueAssessment"/>
<element name="compoundStatement" substitutionGroup="causalConnectorFunctionality:compoundStatement"/>
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- TestRule
-->
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- extends rule element -->
<complexType name="ruleType">
<complexContent>
<extension base="testRule:rulePrototype">
</extension>
</complexContent>
</complexType>
<element name="rule" type="profile:ruleType" substitutionGroup="testRule:rule"/>
<!-- extends compositeRule element -->
<complexType name="compositeRuleType">
<complexContent>
<extension base="testRule:compositeRulePrototype">
</extension>
</complexContent>
</complexType>
<element name="compositeRule" type="profile:compositeRuleType" substitutionGroup="testRule:compositeRule"/>
<!-- extends ruleBase element -->
<complexType name="ruleBaseType">
<complexContent>
<extension base="testRule:ruleBasePrototype">
<choice minOccurs="1" maxOccurs="unbounded">
<element ref="profile:importBase"/>
<element ref="profile:rule"/>
<element ref="profile:compositeRule"/>
</choice>
</extension>
</complexContent>
</complexType>
<element name="ruleBase" type="profile:ruleBaseType" substitutionGroup="testRule:ruleBase"/>
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- TestRuleUse
-->
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- extends bindRule element -->
<complexType name="bindRuleType">
© ABNT 2007 - Todos los derechos reservados
71
ABNT NBR 15606-2:2007
<complexContent>
<extension base="testRuleUse:bindRulePrototype">
</extension>
</complexContent>
</complexType>
<element name="bindRule" type="profile:bindRuleType" substitutionGroup="testRuleUse:bindRule"/>
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- ContentControl
-->
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- extends switch element -->
<!-- switch interface element groups -->
<group name="switchInterfaceElementGroup">
<choice>
<element ref="profile:switchPort"/>
</choice>
</group>
<!-- extends defaultComponent element -->
<complexType name="defaultComponentType">
<complexContent>
<extension base="contentControl:defaultComponentPrototype">
</extension>
</complexContent>
</complexType>
<element name="defaultComponent" type="profile:defaultComponentType"
substitutionGroup="contentControl:defaultComponent"/>
<complexType name="switchType">
<complexContent>
<extension base="contentControl:switchPrototype">
<choice minOccurs="0" maxOccurs="unbounded">
<group ref="profile:switchInterfaceElementGroup"/>
<element ref="profile:bindRule"/>
<element ref="profile:switch"/>
<element ref="profile:media"/>
<element ref="profile:context"/>
</choice>
<attributeGroup ref="entityReuse:entityReuseAttrs"/>
</extension>
</complexContent>
</complexType>
<element name="switch" type="profile:switchType" substitutionGroup="contentControl:switch"/>
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- DescriptorControl
-->
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- extends defaultDescriptor element -->
<complexType name="defaultDescriptorType">
<complexContent>
<extension base="descriptorControl:defaultDescriptorPrototype">
</extension>
</complexContent>
</complexType>
<element name="defaultDescriptor" type="profile:defaultDescriptorType"
substitutionGroup="descriptorControl:defaultDescriptor"/>
<!-- extends descriptorSwitch element -->
<complexType name="descriptorSwitchType">
72
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
<complexContent>
<extension base="descriptorControl:descriptorSwitchPrototype">
<choice minOccurs="0" maxOccurs="unbounded">
<element ref="profile:descriptor"/>
<element ref="profile:bindRule"/>
</choice>
</extension>
</complexContent>
</complexType>
<element name="descriptorSwitch" type="profile:descriptorSwitchType"
substitutionGroup="descriptorControl:descriptorSwitch"/>
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- Timing
-->
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- Import
-->
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<complexType name="importBaseType">
<complexContent>
<extension base="import:importBasePrototype">
</extension>
</complexContent>
</complexType>
<complexType name="importNCLType">
<complexContent>
<extension base="import:importNCLPrototype">
</extension>
</complexContent>
</complexType>
<complexType name="importedDocumentBaseType">
<complexContent>
<extension base="import:importedDocumentBasePrototype">
</extension>
</complexContent>
</complexType>
<element name="importBase" type="profile:importBaseType" substitutionGroup="import:importBase"/>
<element name="importNCL" type="profile:importNCLType" substitutionGroup="import:importNCL"/>
<element name="importedDocumentBase" type="profile:importedDocumentBaseType"
substitutionGroup="import:importedDocumentBase"/>
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- EntityReuse
-->
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- ExtendedEntityReuse
-->
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- KeyNavigation
-->
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- TransitionBase
-->
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- extends transitionBase element -->
© ABNT 2007 - Todos los derechos reservados
73
ABNT NBR 15606-2:2007
<complexType name="transitionBaseType">
<complexContent>
<extension base="transitionBase:transitionBasePrototype">
<choice minOccurs="0" maxOccurs="unbounded">
<element ref="profile:transition"/>
<element ref="profile:importBase"/>
</choice>
</extension>
</complexContent>
</complexType>
<element name="transitionBase" type="profile:transitionBaseType" substitutionGroup="transitionBase:transitionBase"/>
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- Transition
-->
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<element name="transition" substitutionGroup="transition:transition"/>
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- Metainformation
--> <!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
= = = = = = = = = = = = = = = = = = = = = = = -->
<element name="meta" substitutionGroup="metainformation:meta"/>
<element name="metadata" substitutionGroup="metainformation:metadata"/>
</schema>
7.3.3
Esquema del perfil NCL 3.0 CausalConnector
CausalConnector.xsd
<!-XML Schema for the NCL Language
This is NCL
Copyright: 2000-2005 LABORATORIO TELEMIDIA, All Rights Reserved.
See http://www.telemidia.puc-rio.br
Public URI: http://www.ncl.org.br/NCL3.0/profiles/CausalConnector.xsd
Author: TeleMidia Laboratory
Revision: 19/09/2006
-->
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:causalConnectorFunctionality="http://www.ncl.org.br/NCL3.0/CausalConnectorFunctionality"
xmlns:connectorBase="http://www.ncl.org.br/NCL3.0/ConnectorBase"
xmlns:structure="http://www.ncl.org.br/NCL3.0/Structure"
xmlns:import="http://www.ncl.org.br/NCL3.0/Import"
xmlns:profile="http://www.ncl.org.br/NCL3.0/CausalConnectorProfile"
targetNamespace="http://www.ncl.org.br/NCL3.0/CausalConnectorProfile"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<!-- import the definitions in the modules namespaces -->
<import namespace="http://www.ncl.org.br/NCL3.0/CausalConnectorFunctionality"
schemaLocation="http://www.ncl.org.br/NCL3.0/modules/NCL30CausalConnectorFunctionality.xsd"/>
<import namespace="http://www.ncl.org.br/NCL3.0/ConnectorBase"
schemaLocation="http://www.ncl.org.br/NCL3.0/modules/NCL30ConnectorBase.xsd"/>
<import namespace="http://www.ncl.org.br/NCL3.0/Structure"
schemaLocation="http://www.ncl.org.br/NCL3.0/modules/NCL30Structure.xsd"/>
<import namespace="http://www.ncl.org.br/NCL3.0/Import"
schemaLocation="http://www.ncl.org.br/NCL3.0/modules/NCL30Import.xsd"/>
74
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- Structure
-->
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- extends ncl element -->
<complexType name="nclType">
<complexContent>
<restriction base="structure:nclPrototype">
<sequence>
<element ref="structure:head" minOccurs="0" maxOccurs="1"/>
<element ref="structure:body" minOccurs="0" maxOccurs="0"/>
</sequence>
</restriction>
</complexContent>
</complexType>
<element name="ncl" type="profile:nclType" substitutionGroup="structure:ncl"/>
<!-- extends head element -->
<complexType name="headType">
<complexContent>
<extension base="structure:headPrototype">
<all>
<element ref="profile:connectorBase" />
</all>
</extension>
</complexContent>
</complexType>
<element name="head" type="profile:headType" substitutionGroup="structure:head"/>
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- XConnector
-->
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- extends connectorBase element -->
<complexType name="connectorBaseType">
<complexContent>
<extension base="connectorBase:connectorBasePrototype">
<choice minOccurs="0" maxOccurs="unbounded">
<element ref="profile:importBase"/>
<element ref="profile:causalConnector" />
</choice>
</extension>
</complexContent>
</complexType>
<element name="connectorBase" type="profile:connectorBaseType" substitutionGroup="connectorBase:connectorBase"/>
<element name="causalConnector" substitutionGroup="causalConnectorFunctionality:causalConnector"/>
<element name="connectorParam" substitutionGroup="causalConnectorFunctionality:connectorParam"/>
<element name="simpleCondition" substitutionGroup="causalConnectorFunctionality:simpleCondition"/>
<element name="compoundCondition" substitutionGroup="causalConnectorFunctionality:compoundCondition"/>
<element name="simpleAction" substitutionGroup="causalConnectorFunctionality:simpleAction"/>
<element name="compoundAction" substitutionGroup="causalConnectorFunctionality:compoundAction"/>
© ABNT 2007 - Todos los derechos reservados
75
ABNT NBR 15606-2:2007
<element name="assessmentStatement" substitutionGroup="causalConnectorFunctionality:assessmentStatement"/>
<element name="attributeAssessment" substitutionGroup="causalConnectorFunctionality:attributeAssessment"/>
<element name="valueAssessment" substitutionGroup="causalConnectorFunctionality:valueAssessment"/>
<element name="compoundStatement" substitutionGroup="causalConnectorFunctionality:compoundStatement"/>
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- ImportBase
-->
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<element name="importBase" substitutionGroup="import:importBase"/>
</schema>
7.3.4
Atributos y elementos del perfil NCL 3.0 DTV básico
Los elementos y sus atributos, utilizados en el perfil NCL 3.0 DTV Básico, se presentan en las Tablas 39 a 55. Se
quiere resaltar que los atributos y contenidos (elementos-hijos) de elementos se pueden definir en el módulo en sí
o en el perfil NCL DTV Básico que agrupa los módulos. Los atributos obligatorios están subrayados. En las Tablas
39 a 55, se emplean los siguientes símbolos: (?) opcional (cero o una ocurrencia), (|) o (*) cero o más ocurrencias,
(+) una o más ocurrencias.
Tabla 39 — Elementos y atributos del módulo Structure extendido utilizados en el perfil DTV Básico
Elementos
ncl
Atributos
id, title, xmlns
(head?, body?)
(importedDocumentBase? ruleBase?,
regionBase*, descriptorBase?,
connectorBase?),
head
body
Contenido
(port| property| media|context|switch|link)*
id
Tabla 40 — Elementos y atributos del módulo Layout extendido utilizados en el perfil DTV Básico
Elementos
Atributos
Contenido
regionBase
id, device, region
(importBase|region)+
Region
id, title, left, right, top, bottom, height,
width, zIndex
(region)*
Tabla 41 — Elementos y atributos del Módulo Media extendido utilizados en el perfil DTV Básico
Elementos
media
76
Atributos
id, src, refer, instance, type, descriptor
Contenido
(area|property)*
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
Tabla 42 — Elementos y atributos del módulo Context extendido utilizados en el perfil DTV Básico
Elementos
context
Atributos
Contenido
(port|property|media|context|link|switch)*
id, refer
Tabla 43 — Elementos y atributos del módulo MediaContentAnchor extendido utilizados
en el perfil DTV Básico
Elementos
area
Atributos
ID, coords, begin, end, text, position, first,
last, label
© ABNT 2007 - Todos los derechos reservados
Contenido
vacío
77
ABNT NBR 15606-2:2007
Tabla 44 — Elementos y atributos del módulo CompositeNodeInterface extendido utilizados
en el perfil DTV Básico
Elementos
port
Atributos
id, component, interface
Contenido
vacío
Tabla 45 — Elementos y atributos del módulo PropertyAnchor extendido utilizados en el perfil DTV Básico
Elementos
Atributos
property
Contenido
vacío
name, value
Tabla 46 — Elementos y atributos del módulo SwitchInterface extendido utilizados en el perfil DTV Básico
Elementos
Atributos
Contenido
switchPort
id
mapping+
mapping
component, interfaz
vacío
Tabla 47 — Elementos y atributos del módulo Descriptor extendido utilizados en el perfil DTV Básico
Elementos
Atributos
Contenido
descriptor
id, player, explicitDur, region, freeze,
moveLeft, moveRight, moveUp;
moveDown, focusIndex,
focusBorderColor; focusBorderWidth;
focusBorderTransparency,
focusSrc,focusSelSrc, selBorderColor
(descriptorParam)*
descriptorParam
name, value
vacío
descriptorBase
id
(importBase | descriptor | descriptorSwitch)+
Tabla 48 — Elementos y atributos del módulo Linking extendido utilizados en el perfil DTV Básico
Elementos
78
Atributos
Contenido
bind
role, component, interface, descriptor
(bindParam)*
bindParam
name, value
vacío
linkParam
name, value
vacío
link
id, xconnector
(linkParam*, bind+)
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
Tabla 49 — Elementos y atributos del módulo CausalConnectorFunctionality extendido utilizados
en el perfil DTV Básico
Elementos
Atributos
Contenido
causalConnector
id
(connectorParam*, (simpleCondition |
compoundCondition), (simpleAction |
compoundAction))
connectorParam
name, type
vacío
simpleCondition
role, delay, event Type, key,
transition, min, max, qualifier
vacío
compoundCondition
operator, delay
((simpleCondition |
compoundCondition)+,
(assessmentStatement |
compoundStatement)*)
simpleAction
role, delay, eventType, actionType,
value, min, max, qualifier, repeat,
repeatDelay
vacío
compoundAction
operator, delay
(simpleAction | compoundAction)+
assessmentStatement
comparator
(attributeAssessment,
(attributeAssessment |
valueAssessment))
attributeAssessment
role, eventType, key, attributeType,
offset
vacío
valueAssessment
value
vacío
compoundStatement
operator, isNegated
(assessmentStatement |
compoundStatement)+
Tabla 50 — Elementos y atributos del módulo ConnectorBase extendido utilizados en el perfil DTV Básico
Elementos
Atributos
connectorBase id
Contenido
(importBase|causalConnector)*
Tabla 51 — Elementos y atributos del módulo TestRule extendido utilizados en el perfil DTV Básico
Elementos
Atributos
Contenido
ruleBase
id
(importBase|rule|compositeRule)+
rule
id, var, comparator, value
vacío
compositeRule
id, operator
(rule | compositeRule)+
© ABNT 2007 - Todos los derechos reservados
79
ABNT NBR 15606-2:2007
Tabla 52 — Elementos y atributos del módulo TestRuleUse extendido utilizados
en el perfil DTV Básico
Elementos
bindRule
Atributos
Contenido
vacío
constituent, rule
Tabla 53 — Elementos y atributos del módulo ContentControl extendido utilizados
en el perfil DTV Básico
Elementos
Atributos
Contenido
switch
id, refer
(defaultComponent?, (switch Port|
bindRule|media| context | switch)*)
defaultComponent
component
vacío
Tabla 54 — Elementos y atributos del módulo DescriptorControl extendido utilizados
en el perfil DTV Básico
Elementos
Atributos
descriptorSwitch
id
defaultDescriptor
descriptor
Contenido
(defaultDescriptor?,
descriptor)*)
(bindRule
|
vacío
Tabla 55 — Elementos y atributos del módulo Import extendido utilizados en el perfil DTV Básico
Elementos
importBase
80
Atributos
alias, documentURI, región
Contenido
vacío
imported DocumentBase id
(importNCL)+
importNCL
vacío
alias, documentURI,
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
7.3.5
Esquema del perfil NCL 3.0 DTV Básico
NCL30BDTV.xsd
<!-XML Schema for the NCL Language
This is NCL
Copyright: 2000-2005 PUC-RIO/LABORATORIO TELEMIDIA, All Rights Reserved.
See http://www.telemidia.puc-rio.br
Public URI: http://www.ncl.org.br/NCL3.0/profiles/NCL30BDTV.xsd
Author: TeleMidia Laboratory
Revision: 19/09/2006
-->
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:compositeInterface="http://www.ncl.org.br/NCL3.0/CompositeNodeInterface"
xmlns:causalConnectorFunctionality="http://www.ncl.org.br/NCL3.0/CausalConnectorFunctionality"
xmlns:connectorBase="http://www.ncl.org.br/NCL3.0/ConnectorBase"
xmlns:contentControl="http://www.ncl.org.br/NCL3.0/ContentControl"
xmlns:context="http://www.ncl.org.br/NCL3.0/Context"
xmlns:descriptor="http://www.ncl.org.br/NCL3.0/Descriptor"
xmlns:entityReuse="http://www.ncl.org.br/NCL3.0/EntityReuse"
xmlns:extendedEntityReuse="http://www.ncl.org.br/NCL3.0/ExtendedEntityReuse"
xmlns:descriptorControl="http://www.ncl.org.br/NCL3.0/DescriptorControl"
xmlns:import="http://www.ncl.org.br/NCL3.0/Import"
xmlns:keyNavigation="http://www.ncl.org.br/NCL3.0/KeyNavigation"
xmlns:layout="http://www.ncl.org.br/NCL3.0/Layout"
xmlns:linking="http://www.ncl.org.br/NCL3.0/Linking"
xmlns:media="http://www.ncl.org.br/NCL3.0/Media"
xmlns:mediaAnchor="http://www.ncl.org.br/NCL3.0/MediaContentAnchor"
xmlns:propertyAnchor="http://www.ncl.org.br/NCL3.0/PropertyAnchor"
xmlns:structure="http://www.ncl.org.br/NCL3.0/Structure"
xmlns:switchInterface="http://www.ncl.org.br/NCL3.0/SwitchInterface"
xmlns:testRule="http://www.ncl.org.br/NCL3.0/TestRule"
xmlns:testRuleUse="http://www.ncl.org.br/NCL3.0/TestRuleUse"
xmlns:timing="http://www.ncl.org.br/NCL3.0/Timing"
xmlns:profile="http://www.ncl.org.br/NCL3.0/BDTVProfile"
targetNamespace="http://www.ncl.org.br/NCL3.0/BDTVProfile"
elementFormDefault="qualified" attributeFormDefault="unqualified" >
<!-- import the definitions in the modules namespaces -->
<import namespace="http://www.ncl.org.br/NCL3.0/CompositeNodeInterface"
schemaLocation="http://www.ncl.org.br/NCL3.0/modules/NCL30CompositeNodeInterface.xsd"/>
<import namespace="http://www.ncl.org.br/NCL3.0/CausalConnectorFunctionality"
schemaLocation="http://www.ncl.org.br/NCL3.0/modules/NCL30CausalConnectorFunctionality.xsd"/>
<import namespace="http://www.ncl.org.br/NCL3.0/ConnectorBase"
schemaLocation="http://www.ncl.org.br/NCL3.0/modules/NCL30ConnectorBase.xsd"/>
<import namespace="http://www.ncl.org.br/NCL3.0/ContentControl"
schemaLocation="http://www.ncl.org.br/NCL3.0/modules/NCL30ContentControl.xsd"/>
<import namespace="http://www.ncl.org.br/NCL3.0/Context"
schemaLocation="http://www.ncl.org.br/NCL3.0/modules/NCL30Context.xsd"/>
<import namespace="http://www.ncl.org.br/NCL3.0/Descriptor"
schemaLocation="http://www.ncl.org.br/NCL3.0/modules/NCL30Descriptor.xsd"/>
<import namespace="http://www.ncl.org.br/NCL3.0/DescriptorControl"
schemaLocation="http://www.ncl.org.br/NCL3.0/modules/NCL30DescriptorControl.xsd"/>
<import namespace="http://www.ncl.org.br/NCL3.0/EntityReuse"
schemaLocation="http://www.ncl.org.br/NCL3.0/modules/NCL30EntityReuse.xsd"/>
<import namespace="http://www.ncl.org.br/NCL3.0/ExtendedEntityReuse"
schemaLocation="http://www.ncl.org.br/NCL3.0/modules/NCL30ExtendedEntityReuse.xsd"/>
<import namespace="http://www.ncl.org.br/NCL3.0/Import"
schemaLocation="http://www.ncl.org.br/NCL3.0/modules/NCL30Import.xsd"/>
<import namespace="http://www.ncl.org.br/NCL3.0/KeyNavigation"
© ABNT 2007 - Todos los derechos reservados
81
ABNT NBR 15606-2:2007
schemaLocation="http://www.ncl.org.br/NCL3.0/modules/NCL30KeyNavigation.xsd"/>
<import namespace="http://www.ncl.org.br/NCL3.0/Layout"
schemaLocation="http://www.ncl.org.br/NCL3.0/modules/NCL30Layout.xsd"/>
<import namespace="http://www.ncl.org.br/NCL3.0/Linking"
schemaLocation="http://www.ncl.org.br/NCL3.0/modules/NCL30Linking.xsd"/>
<import namespace="http://www.ncl.org.br/NCL3.0/Media"
schemaLocation="http://www.ncl.org.br/NCL3.0/modules/NCL30Media.xsd"/>
<import namespace="http://www.ncl.org.br/NCL3.0/MediaContentAnchor"
schemaLocation="http://www.ncl.org.br/NCL3.0/modules/NCL30MediaContentAnchor.xsd"/>
<import namespace="http://www.ncl.org.br/NCL3.0/PropertyAnchor"
schemaLocation="http://www.ncl.org.br/NCL3.0/modules/NCL30PropertyAnchor.xsd"/>
<import namespace="http://www.ncl.org.br/NCL3.0/Structure"
schemaLocation="http://www.ncl.org.br/NCL3.0/modules/NCL30Structure.xsd"/>
<import namespace="http://www.ncl.org.br/NCL3.0/SwitchInterface"
schemaLocation="http://www.ncl.org.br/NCL3.0/modules/NCL30SwitchInterface.xsd"/>
<import namespace="http://www.ncl.org.br/NCL3.0/TestRule"
schemaLocation="http://www.ncl.org.br/NCL3.0/modules/NCL30TestRule.xsd"/>
<import namespace="http://www.ncl.org.br/NCL3.0/TestRuleUse"
schemaLocation="http://www.ncl.org.br/NCL3.0/modules/NCL30TestRuleUse.xsd"/>
<import namespace="http://www.ncl.org.br/NCL3.0/Timing"
schemaLocation="http://www.ncl.org.br/NCL3.0/modules/NCL30Timing.xsd"/>
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- Structure
-->
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- extends ncl element -->
<element name="ncl" substitutionGroup="structure:ncl"/>
<!-- extends head element -->
<complexType name="headType">
<complexContent>
<extension base="structure:headPrototype">
<sequence>
<element ref="profile:importedDocumentBase" minOccurs="0" maxOccurs="1"/>
<element ref="profile:ruleBase" minOccurs="0" maxOccurs="1"/>
<element ref="profile:regionBase" minOccurs="0" maxOccurs="unbounded"/>
<element ref="profile:descriptorBase" minOccurs="0" maxOccurs="1"/>
<element ref="profile:connectorBase" minOccurs="0" maxOccurs="1"/>
</sequence>
</extension>
</complexContent>
</complexType>
<element name="head" type="profile:headType" substitutionGroup="structure:head"/>
<!-- extends body element -->
<complexType name="bodyType">
<complexContent>
<extension base="structure:bodyPrototype">
<choice minOccurs="0" maxOccurs="unbounded">
<group ref="profile:contextInterfaceElementGroup"/>
<element ref="profile:media"/>
<element ref="profile:context"/>
<element ref="profile:switch"/>
<element ref="profile:link"/>
</choice>
</extension>
</complexContent>
</complexType>
<element name="body" type="profile:bodyType" substitutionGroup="structure:body"/>
82
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- Layout
-->
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- extends regionBase element -->
<complexType name="regionBaseType">
<complexContent>
<extension base="layout:regionBasePrototype">
<choice minOccurs="1" maxOccurs="unbounded">
<element ref="profile:region"/>
<element ref="profile:importBase"/>
</choice>
</extension>
</complexContent>
</complexType>
<complexType name="regionType">
<complexContent>
<extension base="layout:regionPrototype">
</extension>
</complexContent>
</complexType>
<element name="regionBase" type="profile:regionBaseType" substitutionGroup="layout:regionBase"/>
<element name="region" type="profile:regionType" substitutionGroup="layout:region"/>
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- Media
-->
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- extends Media elements -->
<!-- media interface element groups -->
<group name="mediaInterfaceElementGroup">
<choice>
<element ref="profile:area"/>
<element ref="profile:property"/>
</choice>
</group>
<complexType name="mediaType">
<complexContent>
<extension base="media:mediaPrototype">
<choice minOccurs="0" maxOccurs="unbounded">
<group ref="profile:mediaInterfaceElementGroup"/>
</choice>
<attributeGroup ref="descriptor:descriptorAttrs"/>
<attributeGroup ref="entityReuse:entityReuseAttrs"/>
<attributeGroup ref="extendedEntityReuse:extendedEntityReuseAttrs"/>
</extension>
</complexContent>
</complexType>
<element name="media" type="profile:mediaType" substitutionGroup="media:media"/>
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- Context
-->
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- extends context element -->
<!-- composite node interface element groups -->
<group name="contextInterfaceElementGroup">
<choice>
<element ref="profile:port"/>
<element ref="profile:property"/>
</choice>
© ABNT 2007 - Todos los derechos reservados
83
ABNT NBR 15606-2:2007
</group>
<complexType name="contextType">
<complexContent>
<extension base="context:contextPrototype">
<choice minOccurs="0" maxOccurs="unbounded">
<group ref="profile:contextInterfaceElementGroup"/>
<element ref="profile:media"/>
<element ref="profile:context"/>
<element ref="profile:link"/>
<element ref="profile:switch"/>
</choice>
<attributeGroup ref="entityReuse:entityReuseAttrs"/>
</extension>
</complexContent>
</complexType>
<element name="context" type="profile:contextType" substitutionGroup="context:context"/>
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- MediaContentAnchor
-->
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- extends area element -->
<complexType name="componentAnchorType">
<complexContent>
<extension base="mediaAnchor:componentAnchorPrototype">
</extension>
</complexContent>
</complexType>
<element name="area" type="profile:componentAnchorType" substitutionGroup="mediaAnchor:area"/>
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- CompositeNodeInterface
-->
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- extends port element -->
<complexType name="compositeNodePortType">
<complexContent>
<extension base="compositeInterface:compositeNodePortPrototype">
</extension>
</complexContent>
</complexType>
<element name="port" type="profile:compositeNodePortType" substitutionGroup="compositeInterface:port"/>
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- PropertyAnchor
-->
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- extends property element -->
<complexType name="propertyAnchorType">
<complexContent>
<extension base="propertyAnchor:propertyAnchorPrototype">
</extension>
</complexContent>
</complexType>
<element name="property" type="profile:propertyAnchorType" substitutionGroup="propertyAnchor:property"/>
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- SwitchInterface
-->
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- extends switchPort element -->
84
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
<complexType name="switchPortType">
<complexContent>
<extension base="switchInterface:switchPortPrototype">
</extension>
</complexContent>
</complexType>
<element name="mapping" substitutionGroup="switchInterface:mapping"/>
<element name="switchPort" type="profile:switchPortType" substitutionGroup="switchInterface:switchPort"/>
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- Descriptor
-->
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- substitutes descriptorParam element -->
<element name="descriptorParam" substitutionGroup="descriptor:descriptorParam"/>
<!-- extends descriptor element -->
<complexType name="descriptorType">
<complexContent>
<extension base="descriptor:descriptorPrototype">
<attributeGroup ref="layout:regionAttrs"/>
<attributeGroup ref="timing:explicitDurAttrs"/>
<attributeGroup ref="timing:freezeAttrs"/>
<attributeGroup ref="keyNavigation:keyNavigationAttrs"/>
</extension>
</complexContent>
</complexType>
<element name="descriptor" type="profile:descriptorType" substitutionGroup="descriptor:descriptor"/>
<!-- extends descriptorBase element -->
<complexType name="descriptorBaseType">
<complexContent>
<extension base="descriptor:descriptorBasePrototype">
<choice minOccurs="1" maxOccurs="unbounded">
<element ref="profile:importBase"/>
<element ref="profile:descriptor"/>
<element ref="profile:descriptorSwitch"/>
</choice>
</extension>
</complexContent>
</complexType>
<element name="descriptorBase" type="profile:descriptorBaseType" substitutionGroup="descriptor:descriptorBase"/>
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- Linking
-->
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- substitutes linkParam and bindParam elements -->
<element name="linkParam" substitutionGroup="linking:linkParam"/>
<element name="bindParam" substitutionGroup="linking:bindParam"/>
<!-- extends bind element and link element, as a consequence-->
<complexType name="bindType">
<complexContent>
<extension base="linking:bindPrototype">
<attributeGroup ref="descriptor:descriptorAttrs"/>
</extension>
</complexContent>
© ABNT 2007 - Todos los derechos reservados
85
ABNT NBR 15606-2:2007
</complexType>
<element name="bind" type="profile:bindType" substitutionGroup="linking:bind"/>
<!-- extends link element -->
<complexType name="linkType">
<complexContent>
<extension base="linking:linkPrototype">
</extension>
</complexContent>
</complexType>
<element name="link" type="profile:linkType" substitutionGroup="linking:link"/>
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- Connector
-->
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- extends connectorBase element -->
<complexType name="connectorBaseType">
<complexContent>
<extension base="connectorBase:connectorBasePrototype">
<choice minOccurs="0" maxOccurs="unbounded">
<element ref="profile:importBase"/>
<element ref="profile:causalConnector" />
</choice>
</extension>
</complexContent>
</complexType>
<element name="connectorBase" type="profile:connectorBaseType" substitutionGroup="connectorBase:connectorBase"/>
<element name="causalConnector" substitutionGroup="causalConnectorFunctionality:causalConnector"/>
<element name="connectorParam" substitutionGroup="causalConnectorFunctionality:connectorParam"/>
<element name="simpleCondition" substitutionGroup="causalConnectorFunctionality:simpleCondition"/>
<element name="compoundCondition" substitutionGroup="causalConnectorFunctionality:compoundCondition"/>
<element name="simpleAction" substitutionGroup="causalConnectorFunctionality:simpleAction"/>
<element name="compoundAction" substitutionGroup="causalConnectorFunctionality:compoundAction"/>
<element name="assessmentStatement" substitutionGroup="causalConnectorFunctionality:assessmentStatement"/>
<element name="attributeAssessment" substitutionGroup="causalConnectorFunctionality:attributeAssessment"/>
<element name="valueAssessment" substitutionGroup="causalConnectorFunctionality:valueAssessment"/>
<element name="compoundStatement" substitutionGroup="causalConnectorFunctionality:compoundStatement"/>
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- TestRule
-->
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- extends rule element -->
<complexType name="ruleType">
<complexContent>
<extension base="testRule:rulePrototype">
</extension>
</complexContent>
</complexType>
<element name="rule" type="profile:ruleType" substitutionGroup="testRule:rule"/>
86
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
<!-- extends compositeRule element -->
<complexType name="compositeRuleType">
<complexContent>
<extension base="testRule:compositeRulePrototype">
</extension>
</complexContent>
</complexType>
<element name="compositeRule" type="profile:compositeRuleType" substitutionGroup="testRule:compositeRule"/>
<!-- extends ruleBase element -->
<complexType name="ruleBaseType">
<complexContent>
<extension base="testRule:ruleBasePrototype">
<choice minOccurs="1" maxOccurs="unbounded">
<element ref="profile:importBase"/>
<element ref="profile:rule"/>
<element ref="profile:compositeRule"/>
</choice>
</extension>
</complexContent>
</complexType>
<element name="ruleBase" type="profile:ruleBaseType" substitutionGroup="testRule:ruleBase"/>
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- TestRuleUse
-->
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- extends bindRule element -->
<complexType name="bindRuleType">
<complexContent>
<extension base="testRuleUse:bindRulePrototype">
</extension>
</complexContent>
</complexType>
<element name="bindRule" type="profile:bindRuleType" substitutionGroup="testRuleUse:bindRule"/>
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- ContentControl
-->
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- extends switch element -->
<!-- switch interface element groups -->
<group name="switchInterfaceElementGroup">
<choice>
<element ref="profile:switchPort"/>
</choice>
</group>
<!-- extends defaultComponent element -->
<complexType name="defaultComponentType">
<complexContent>
<extension base="contentControl:defaultComponentPrototype">
</extension>
</complexContent>
</complexType>
<element name="defaultComponent" type="profile:defaultComponentType"
substitutionGroup="contentControl:defaultComponent"/>
<complexType name="switchType">
<complexContent>
<extension base="contentControl:switchPrototype">
<choice minOccurs="0" maxOccurs="unbounded">
© ABNT 2007 - Todos los derechos reservados
87
ABNT NBR 15606-2:2007
<group ref="profile:switchInterfaceElementGroup"/>
<element ref="profile:bindRule"/>
<element ref="profile:switch"/>
<element ref="profile:media"/>
<element ref="profile:context"/>
</choice>
<attributeGroup ref="entityReuse:entityReuseAttrs"/>
</extension>
</complexContent>
</complexType>
<element name="switch" type="profile:switchType" substitutionGroup="contentControl:switch"/>
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- DescriptorControl
-->
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- extends defaultDescriptor element -->
<complexType name="defaultDescriptorType">
<complexContent>
<extension base="descriptorControl:defaultDescriptorPrototype">
</extension>
</complexContent>
</complexType>
<element name="defaultDescriptor" type="profile:defaultDescriptorType"
substitutionGroup="descriptorControl:defaultDescriptor"/>
<!-- extends descriptorSwitch element -->
<complexType name="descriptorSwitchType">
<complexContent>
<extension base="descriptorControl:descriptorSwitchPrototype">
<choice minOccurs="0" maxOccurs="unbounded">
<element ref="profile:descriptor"/>
<element ref="profile:bindRule"/>
</choice>
</extension>
</complexContent>
</complexType>
<element name="descriptorSwitch" type="profile:descriptorSwitchType"
substitutionGroup="descriptorControl:descriptorSwitch"/>
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- Timing
-->
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- Import
-->
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<complexType name="importBaseType">
<complexContent>
<extension base="import:importBasePrototype">
</extension>
</complexContent>
</complexType>
<complexType name="importNCLType">
<complexContent>
<extension base="import:importNCLPrototype">
</extension>
</complexContent>
</complexType>
88
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
<complexType name="importedDocumentBaseType">
<complexContent>
<extension base="import:importedDocumentBasePrototype">
</extension>
</complexContent>
</complexType>
<element name="importBase" type="profile:importBaseType" substitutionGroup="import:importBase"/>
<element name="importNCL" type="profile:importNCLType" substitutionGroup="import:importNCL"/>
<element name="importedDocumentBase" type="profile:importedDocumentBaseType"
substitutionGroup="import:importedDocumentBase"/>
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- EntityReuse
-->
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- ExtendedEntityReuse
-->
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- KeyNavigation
-->
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
</schema>
8
Objetos de media en presentaciones NCL
8.1 Implementación modular de Ginga-NCL
La presentación de un documento NCL requiere el control de la sincronización de varios objetos de media
(especificados a través del elemento <media>). Para cada objeto de media, un player (exhibidor de media) puede
ser cargado para el control del objeto y de sus eventos NCL. Un exhibidor de media (o su adaptador) debe ser
capaz obligatoriamente de recibir los comandos de presentación, controlar las máquinas de estado de los eventos
del objeto de media controlado y responder a las exigencias del formateador.
Para favorecer la incorporación de players de terceros dentro de la implementación de la arquitectura Ginga, se
recomienda un proyecto modular del Ginga-NCL para separar los players de la máquina de presentación
(formateador NCL).
La Figura 4 sugiere una organización modular para la implementación Ginga-NCL. Los exhibidores son módulos
plug-in de la máquina de presentación. Por ser interesante utilizar los players ya existentes, que puedan tener
interfaces propietarias que no sean compatibles con las exigidas por la máquina de presentación, será necesario
desarrollar módulos para hacer las adaptaciones necesarias. En ese caso, el exhibidor será constituido por un
adaptador además del exhibidor no-conforme en sí.
© ABNT 2007 - Todos los derechos reservados
89
ABNT NBR 15606-2:2007
Figura 4 — API para integrar los players a la implementación de la máquina de presentación NCL
NOTA
Como la arquitectura e implementación Ginga-NCL es una elección de cada receptor, esta subsección no tiene la
intención de estandarizar la sintaxis de la API de la máquina de presentación. El objetivo de esta sección es sólo definir el
comportamiento esperado del exhibidor de media cuando se está controlando objetos que forman parte de un documento NCL.
Lo descrito en 8.2 a 8.4 se refiere a los exhibidores de media para elemento <media> cuyo contenido no es código procedural,
es decir, elementos <media> cuyos tipos son diferentes de application/x-ginga-NCLua” y “application/x-ginga-NCLet”. Un
elemento <media> del tipo “application/x-ginga-NCL” se comporta como si fuera un nudo de composición constituido por su
elemento <body>, como presenta la Sección 8.4. Lo descrito en 8.5 se refiere a los exhibidores de media (máquinas Lua y
Java) para los elementos <media> cuyo contenido son códigos procedurales (Lua y Java).
8.2 Comportamiento esperado de los exhibidores de media
8.2.1
Instrucción start para eventos de presentación
Antes de enviar la instrucción start, se recomienda que el formateador encuentre el exhibidor de media más
apropiado, con base en el tipo de contenido a ser exhibido. Para tanto, el formateador lleva en consideración el
atributo player del elemento <descriptor> asociado con el objeto de media a ser exhibido. Si ese atributo no se
especifica, el formateador debe obligatoriamente tener en cuenta el atributo type del elemento <media>. Si ese
atributo tampoco se especifica, el formateador debe considerar obligatoriamente la extensión del archivo
especificado en el atributo src del elemento <media>.
La instrucción start emitida por un formateador debe informar obligatoriamente al exhibidor de media los
siguientes parámetros: El objeto de media a ser controlado, su descriptor asociado, una lista de eventos
(presentación, selección o atribución) que necesitan ser monitoreados por el exhibidor de media, el evento de
presentación a ser iniciado (denominado evento principal), un tiempo de compensación (offset-time) opcional y un
tiempo de retardo, opcional.
Un objeto de media debe ser obligatoriamente derivado de un elemento <media>, cuyo atributo src se debe usar
obligatoriamente, por el exhibidor de media, para localizar el contenido e iniciar la presentación. Si el contenido no
se puede localizar, o si el exhibidor de media no sabe cómo manejar el tipo de contenido, el exhibidor de media
debe obligatoriamente encerrar la operación de iniciación sin realizar ninguna acción.
El descriptor a ser utilizado debe ser obligatoriamente elegido por el formateador siguiendo las directrices
especificadas en el documento NCL. Si la instrucción start resulta de una acción de un eslabón que tenga un
descriptor explícitamente declarado en su elemento <bind> (atributo descriptor del elemento <bind>), el descriptor
resultante informado por el formateador debe obligatoriamente mezclar los atributos del descriptor especificado
por el <bind> con los atributos del descriptor especificado en el elemento <media> correspondiente, si ese
atributo ha sido especificado. Para atributos en común, la información del descriptor del <bind> debe
obligatoriamente superponer los datos del descriptor de la <media>. Si el elemento <bind> no contiene un
descriptor explícito, el descriptor informado por el formateador debe ser obligatoriamente el descriptor
especificado por el elemento <media>, si el atributo ha sido especificado. En caso contrario, debe ser
obligatoriamente elegido, por el formateador, un descriptor default para el tipo de <media> específico.
90
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
Conviene que la lista de eventos a ser monitoreados por un exhibidor de media también sea computada por el
formateador, teniendo en cuenta la especificación del documento NCL. Debe obligatoriamente chequear todos los
eslabones de los cuales participa el objeto de media y el descriptor resultante. Al computar los eventos a ser
monitoreados, el formateador debe considerar obligatoriamente la perspectiva del objeto de media, es decir, el
camino de los varios elementos <body> y <context> para alcanzar en profundidad el elemento <media>
correspondiente. Conviene que apenas eslabones contenidos en esos elementos <body> y <context> sean
considerados en la computación de los eventos monitoreados.
El parámetro offset-time es opcional y tiene “cero” como su valor default. El parámetro es significativo solamente
para media continua o estática con duración explícita. En ese caso, el parámetro define un tiempo de
compensación, desde el inicio (beginning-time) del evento principal, desde el cual la presentación de ese evento
debe ser inmediatamente iniciada (es decir, comanda el exhibidor para saltar para el beginning-time + offset-time).
Obviamente, el valor del offset-time debe ser obligatoriamente menor que la duración del evento principal.
Si el offset-time es mayor que cero, el exhibidor de media debe obligatoriamente colocar el evento principal en el
estado ocurriendo (occurring), pero la transición de inicio (starts) del evento obligatoriamente no debe ser
notificada. Si el offset-time es cero, el exhibidor de media debe obligatoriamente colocar el evento principal en el
estado ocurriendo y notificar la ocurrencia de la transición de inicio. Los eventos que tendrían sus tiempos de
finalización anteriores al tiempo de inicio del evento principal y eventos que tendrían sus tiempos de inicio
después del tiempo de finalización del evento principal no necesitan ser monitoreados por el exhibidor de media
(conviene que el formateador haga esa verificación cuando construya la lista de eventos monitoreados).
Los eventos monitoreados que tienen tiempos de inicio antes del tiempo de inicio del evento principal y tiempos
de finalización después del tiempo de inicio del evento principal deben ser obligatoriamente colocados en el
estado de ocurriendo, pero sus transiciones de inicio obligatoriamente no deben ser notificadas (eslabones que
dependen de esa transición obligatoriamente no deben ser disparados). Los eventos monitoreados que tendrían
sus tiempos de finalización después del tiempo de inicio del evento principal, pero antes del tiempo de inicio
(beginning-time + offset-time), deben tener obligatoriamente su atributo occurrences incrementado, pero las
transiciones de inicio y término (stops) no deben ser notificadas. Los eventos monitoreados que tienen su tiempo
de inicio antes del momento de inicio (beginning time + offset-time) y tiempo de finalización después del tiempo de
inicio deben ser obligatoriamente colocados en el estado de ocurriendo, pero la transición de inicio
correspondiente obligatoriamente no debe ser notificada.
El tiempo de retardo también es un parámetro opcional y su valor default también es “cero”. Si es mayor que cero,
ese parámetro contiene un tiempo a ser esperado por el exhibidor de media antes de iniciar su presentación.
Ese parámetro se debe tener en cuenta apenas si el parámetro de offset-time es igual a “cero”.
Si un exhibidor de media recibe una instrucción de start para un objeto ya siendo presentado (pausado o no),
debe obligatoriamente ignorar la instrucción y mantener el control de la presentación en marcha. En este caso, el
elemento <simpleAction> que causó la instrucción start no debe causar cualquier transición en la máquina de
estados del evento a él asociado.
8.2.2
Instrucción stop
La instrucción stop necesita sólo identificar un objeto de media que ya está siendo controlado. Identificar el objeto
de media significa identificar el elemento <media>, el descriptor correspondiente y la perspectiva del objeto de
media. Así, si un elemento <simpleAction> con el action Type igual a “stop” se conecta por un eslabón a una
interfaz de nudo, la interfaz debe ser ignorada cuando la acción es ejecutada.
Si el objeto no está siendo presentado (es decir, si ninguno de los eventos en la lista de eventos del objeto está
en el estado occurring o paused) y el exhibidor de media no está aguardando debido a una instrucción atrasada
de start, la instrucción stop debe ser obligatoriamente ignorada. Si el objeto está siendo presentado, el evento
principal (evento pasado como parámetro cuando el objeto de media fue iniciado) y todos los eventos
monitoreados en el estado occurring o paused, con tiempo de finalización igual o anterior al tiempo de término del
evento principal deben obligatoriamente transitar para el estado sleeping y sus transiciones stops deben ser
obligatoriamente notificadas.
© ABNT 2007 - Todos los derechos reservados
91
ABNT NBR 15606-2:2007
Los eventos monitoreados en el estado occurring o paused con tiempo de finalización posterior al tiempo de
finalización del evento principal deben ser obligatoriamente colocados en el estado sleeping, pero sus transiciones
stops no deben ser notificadas y su atributo occurrences no se debe incrementar. La presentación del contenido
del objeto debe ser obligatoriamente parada. Si el atributo repetitions del evento es mayor que cero, debe ser
obligatoriamente disminuido en uno y la presentación del evento principal debe obligatoriamente reiniciar después
del tiempo entre repeticiones (el tiempo de retardo entre repeticiones debe obligatoriamente haber sido
transmitido al exhibidor de media como parámetro de retardo de inicio). Si el objeto de media está esperando para
ser presentado después de una instrucción start atrasada y si es emitida una instrucción stop, la instrucción de
start anterior debe ser obligatoriamente retirada.
“NOTA
Cuando todos los objetos de media que se refieren al flujo elemental que transporta el video principal de un
programa estén en estado sleeping, la exhibición del video principal ocupa toda la pantalla. Solamente por medio de un objeto
de media en ejecución se puede redimensionar el video principal. Lo mismo acontece con el audio principal de un programa,
cuando todos los objetos de media que se refieren al flujo elemental que transporta el audio principal de un programa están en
estado sleeping, la exhibición del audio principal adquiere el 100% de su volumen.
8.2.3
Instrucción abort
La instrucción abort necesita sólo identificar un objeto de media que ya está siendo controlado. Si un elemento
<simpleAction> con el action Type igual a “abort” se conecta por un eslabón a una interfaz de nudo, la interfaz
debe ser ignorada cuando la acción es ejecutada.
Si el objeto no está siendo presentado y no está esperando ser presentado después de una instrucción de start
atrasada, la instrucción abort debe ser obligatoriamente ignorada. Si el objeto está siendo presentado, evento
principal y todos los eventos monitoreados en el estado occurring o paused deben obligatoriamente transitar para el
estado sleeping, y sus transiciones aborts deben ser obligatoriamente notificadas. Cualquier presentación de
contenido debe obligatoriamente parar.
Si el atributo repetitions del evento es mayor que cero, debe ser colocado obligatoriamente en cero y la
presentación del objeto de media no debe ser reiniciada. Si el objeto de media está esperando para ser
presentado después de una instrucción start atrasada y es emitida una instrucción abort, la instrucción start debe
ser obligatoriamente retirada.
8.2.4
Instrucción pause
La instrucción pause sólo necesita identificar un objeto de media que ya está siendo controlado. Si un elemento
<simpleAction> con el action Type igual a “pause” se conecta por un eslabón a una interfaz de nudo, la interfaz
debe ser ignorada cuando la acción es ejecutada.
Si el objeto no está siendo presentado (si el evento principal, pasado como parámetro cuando el objeto de media
fue iniciado, no está en el estado occurring) y el exhibidor de media no está esperando por el retardo de inicio, la
instrucción debe ser obligatoriamente ignorada. Si el objeto está siendo presentado, el evento principal y todos los
eventos monitoreados en el estado occurring deben obligatoriamente pasar para el estado paused y sus
transiciones pauses deben ser obligatoriamente notificadas. La presentación del objeto debe ser obligatoriamente
pausada y el tiempo de pausa transcurrido obligatoriamente no se debe tener en cuenta como parte de la
duración del objeto. Como ejemplo, si un objeto tiene duración explícita de 30 s, y después de 25 s se pausa,
incluso si el objeto permanece pausado durante 5 min, después del reinicio, el evento principal del objeto debe
obligatoriamente permanecer ocurriendo por 5 S. Si el evento principal aún no está ocurriendo porque el exhibidor
de media está esperando el retardo de inicio, el objeto de media debe obligatoriamente esperar por una
instrucción resume para continuar aguardando el retardo de inicio.
8.2.5
Instrucción resume
La instrucción resume necesita apenas identificar un objeto de media que ya está siendo controlado. Si un
elemento <simpleAction> con el actionType igual a “resume” se conecta por un eslabón a una interfaz de nudo, la
interfaz debe ser ignorada cuando la acción es ejecutada.
92
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
Si el objeto no está pausado (si el evento principal, pasado como parámetro cuando el objeto de media fue
iniciado, no está en el estado paused) y el exhibidor de media no está pausado (esperando por el retardo de
inicio), la instrucción debe ser obligatoriamente ignorada.
Si el exhibidor de media está pausado aguardando el retardo de inicio, debe obligatoriamente retomar la
exhibición desde el instante en que fue pausado. Si el evento principal está en el estado paused, el evento
principal y todos los eventos monitoreados en el estado paused deben ser obligatoriamente colocados en el
estado occurring y sus transiciones resumes deben ser obligatoriamente notificadas.
8.2.6
Instrucción start para eventos de atribución
La instrucción start puede ser aplicada a un atributo de un objeto independientemente del hecho de estar siendo
presentado o no (en este último caso, aunque el objeto no esté siendo presentado, su exhibidor de media ya debe
obligatoriamente haber sido referido). En el primer caso, la instrucción start necesita identificar el objeto de media
siendo controlado, un evento de atribución monitoreado y un valor a ser atribuido al atributo que definió el evento.
En el segundo caso, la instrucción también debe identificar obligatoriamente el elemento <descriptor> que será
usado durante la presentación del objeto (como se hace para la instrucción start para presentación).
Al aplicar un valor al atributo, el exhibidor de media debe obligatoriamente pasar la máquina del estado de evento
de atribución al estado occurring y, después de terminada la atribución, nuevamente para el estado sleeping,
generando la transición starts y a continuación la transición stops.
Para cada evento de atribución monitoreado, si el exhibidor de media altera, por su propia cuenta, el valor
correspondiente de un atributo, debe obligatoriamente proceder como si hubiese recibido una instrucción de
ajuste externa.
8.2.7
Instrucción addEvent
La instrucción addEvent es emitida en el caso de edición de un comando de edición NCL addInterface (ver
Sección 11). La instrucción necesita apenas identificar un objeto de media que ya esté siendo controlado y un
nuevo evento que deba ser obligatoriamente incluido para ser monitoreado.
Todas las reglas aplicadas a la intersección de eventos monitoreados con el evento principal se deberán aplicar
obligatoriamente al nuevo evento. Si el tiempo de inicio del nuevo evento es anterior al tiempo actual del objeto y
el tiempo de finalización del nuevo evento es posterior al tiempo actual del objeto, el nuevo evento debe ser
colocado obligatoriamente en el mismo estado del evento principal (occurring o paused), sin notificar la transición
correspondiente.
8.2.8
Instrucción removeEvent
La instrucción removeEvent es emitida en el caso de recepción de un comando de NCL removeInterface.
La instrucción necesita identificar un objeto de media que ya esté siendo controlado y un nuevo evento que ya no
tiene que ser controlado. El estado del evento debe ser colocado obligatoriamente en el estado sleeping sin
generar ninguna transición.
8.2.9
Finalización natural de una presentación
Los eventos de un objeto, con duración explícita o intrínseca, normalmente terminan sus presentaciones
naturalmente, sin necesitar instrucciones externas. En ese caso, el exhibidor de media debe obligatoriamente
pasar el evento para el estado sleeping y notificar la transición stops. Lo mismo debe ser obligatoriamente hecho
para eventos monitoreados en el estado occurring con el mismo tiempo de finalización del evento principal o con
tiempo de finalización desconocido, cuando el evento principal termina. Los eventos en el estado occurring con
tiempo de finalización posterior al tiempo de finalización del evento principal deben ser obligatoriamente
colocados en el estado sleeping sin generar la transición stops y sin incrementar el atributo occurences.
Es importante resaltar que, si el evento principal corresponde a un ancla temporal interna al objeto, cuando la
presentación de ese ancla termine, toda la presentación del objeto de media debe obligatoriamente terminar.
© ABNT 2007 - Todos los derechos reservados
93
ABNT NBR 15606-2:2007
8.3 Comportamiento esperado de los exhibidores de media después de instrucciones aplicadas
a los objetos de composición
NOTA
Los conceptos establecidos en esta subsección también se aplican a los elementos <media> del tipo “application/xginga-NCL”, que se comportarán como si fueran nudos de composición constituidos por sus elementos <body>.
8.3.1
Eslabones refiriendo nudos de composición
Un <simpleCondition> o <simpleAction> con valor del atributo eventType igual a “presentation” puede ser
asociado por un eslabón a un nudo de composición (representado por un elemento <context> o <body>) como un
todo (es decir, sin que una de sus interfaces sea informada). Como normalmente ocurre, la máquina de estado del
evento de presentación definido por el nudo de composición debe ser obligatoriamente controlada como
especificado en 7.2.8.
De forma análoga, un <attributeAssessment>, con valor de atributo eventType igual a “presentation” y
attributeType igual a “state”, “occurrences” o “repetitions” puede ser asociado por un eslabón a un nudo de
composición (representado por un elemento <context> o <body>) como un todo. Se recomienda que el valor del
atributo derive de la máquina de estado del evento de presentación definido por el nudo de composición.
Sin embargo, si una <simpleAction> con valor de atributo eventType igual a “presentation” es asociada por un
eslabón a un nudo de composición (representado por un elemento <context> o <body>) como un todo (es decir,
sin que una de sus interfaces sea informada), la instrucción debe ser obligatoriamente reflejada en las máquinas
de estado de evento de los nudos hijos de la composición.
8.3.2
Empezando la presentación de un contexto
Si un elemento <context> o <body> participa en un papel (role) action cuyo tipo de acción es "start", cuando esa
acción es accionada, la instrucción start también se debe aplicar obligatoriamente a todos los eventos de
presentación mapeados por los puertos de los elementos <context> o <body>.
Si el autor quisiera iniciar la presentación usando un puerto específico, también debe indicar obligatoriamente el id
de <port> como valor de interfaz <bind>.
8.3.3
Parando la presentación de un contexto
Si un elemento <context> o <body> participa en un papel (role) action cuyo tipo de acción es "stop", cuando esa
acción es accionada, la instrucción stop también se debe aplicar obligatoriamente a todos los eventos de
presentación de los nudos hijos de la composición.
Si la composición contiene eslabones siendo evaluados (o con su evaluación pausada), las evaluaciones deben
ser obligatoriamente suspendidas y obligatoriamente ninguna acción debe ser accionada.
8.3.4
Abortando la presentación de un contexto
Si un elemento <context> o <body> participa en un papel (role) action cuyo tipo de acción es "abort", cuando esa
acción es accionada, la instrucción abort también se debe aplicar obligatoriamente a todos los eventos de
presentación de los nudos hijos de la composición.
Si la composición contiene eslabones siendo evaluados (o con su evaluación pausada), las evaluaciones deben
ser obligatoriamente suspendidas y obligatoriamente ninguna acción debe ser accionada.
8.3.5
Pausando la presentación de un contexto
Si un elemento <context> o <body> participa en un papel (role) action cuyo tipo de acción es "pause", cuando esa
acción es accionada, la instrucción pause también se debe aplicar obligatoriamente a todos los eventos de
presentación de los nudos hijos de la composición que estén en el estado occurring.
Si la composición contiene eslabones siendo evaluados, todas las evaluaciones deben ser obligatoriamente
suspendidas hasta que una acción resume, stop o abort sea emitida.
94
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
Si la composición contiene nudos-hijos con eventos de presentación en el estado paused cuando la acción
paused en la composición es emitida, ésos nudos deben ser obligatoriamente identificados, porque, si la
composición recibe una instrucción resume, esos eventos obligatoriamente no deben ser retomados.
8.3.6
Retomando la presentación de un contexto
Si un elemento <context> o <body> participa en un papel (role) action cuyo tipo de acción es "resume", cuando
esa acción sea accionada, la instrucción resume también se debe aplicar obligatoriamente a todos los eventos de
presentación de los nudos hijos de la composición que estén en el estado paused, excepto los que ya estaban
pausados antes de la composición ser pausada.
Si la composición contiene eslabones con evaluaciones pausadas, deben ser obligatoriamente reiniciadas.
8.4 Relación entre las máquinas de estado de eventos de presentación de un nudo y la máquina
de estado del evento de presentación de su nudo de composición padre
NOTA
Los conceptos establecidos en esta sub-sección también se aplican a elementos <media> del tipo “application/xginga-NCL”, que se comportarán como si fueran nudos de composición constituidos por sus elementos <body>.
Siempre que el evento de presentación de un nudo (media o composición) va al estado occurring, el evento de
presentación del nudo de composición que contiene el nudo también debe obligatoriamente entrar en el estado
occurring.
Cuando todos los nudos-hijos de un nudo de composición tengan sus eventos de presentación en el estado
sleeping, el evento de presentación del nudo de composición también debe obligatoriamente estar en el estado
sleeping.
Los nudos de composición no necesitan inferir transiciones aborts a partir de sus nudos-hijos. Esas transiciones
en los eventos de presentación de nudos de composición deben ocurrir obligatoriamente sólo cuando se aplican
instrucciones directamente a su evento de presentación (ver 8.3).
Cuando todos los nudos hijos de un nudo de composición tienen sus eventos de presentación en un estado
diferente de occurring y al menos uno de los nudos tiene su evento principal en el estado paused, el evento de
presentación del nudo de composición también debe estar en el estado paused.
Si un elemento <switch> es iniciado, pero no define un componente default y ninguna de las reglas <bindRule>
referenciadas es evaluada como verdadera, la presentación switch obligatoriamente no debe entrar en el estado
occurring.
8.5 Comportamiento esperado de los exhibidores procedurales en aplicaciones NCL
Objetos procedurales pueden ser insertados en documentos NCL, trayendo capacidades computacionales
adicionales a los documentos declarativos. La forma de agregar objetos procedurales en documentos NCL es
definir un elemento <media> cuyo contenido (localizado por el atributo src) es el código procedural a ser
ejecutado. Los perfiles EDTV y BDTV de NCL 3.0 permiten que dos tipos de media sean asociados con el
elemento <media>: Application/x-ginga-NCLua, para códigos procedurales Lua (extensión de archivo .lua); y
application/x-ginga-NCLet, para códigos procedurales Java (Xlet) (extensión de archivo .class o .jar).
Autores pueden definir eslabones NCL para iniciar, parar, pausar, retomar o abortar la ejecución de un código
procedural. Un exhibidor procedural (máquina de ejecución del lenguaje) debe proveer obligatoriamente la interfaz
del ambiente de ejecución procedural con el formateador NCL.
Análogamente a lo realizado por los exhibidores de contenidos de media convencional, los exhibidores
procedurales deben obligatoriamente controlar las máquinas de estado de los eventos asociados con el nudo
procedural NCL (NCLua o NCLet). Como ejemplo, si un código termina su ejecución, el exhibidor debe
obligatoriamente generar la transición stops en la máquina de estado de presentación del evento correspondiente
a la ejecución procedural.
NCL permite que la ejecución del código procedural sea sincronizada con otros objetos NCL (procedural o no). Un
elemento <media> conteniendo un código procedural también puede definir anclas (a través de elementos
<area>) y propiedades (a través de elementos <property>).
© ABNT 2007 - Todos los derechos reservados
95
ABNT NBR 15606-2:2007
Un código procedural puede ser asociado a elementos <area> (a través del atributo label). Si eslabones externos
empiezan, paran, pausan, retoman o abortan la presentación del ancla, callbacks en el código procedural deben
ser obligatoriamente disparados. La forma de cómo esos callbacks se definen es responsabilidad de cada código
procedural asociado con el objeto procedural NCL.
Por otro lado, un código procedural puede también comandar el inicio, parada, pausa, reconquista o aborto de
esas anclas, a través de una API ofrecida por el lenguaje procedural. Esas transiciones se pueden utilizar como
condiciones de eslabones NCL para disparar acciones en otros objetos NCL del mismo documento. Así, una
sincronización de dos vías puede ser establecida entre el código procedural y el resto del documento NCL.
La otra forma que un código procedural puede ser sincronizado con otros objetos NCL es a través de elementos
<property>. Un elemento <property> definido como hijo de un elemento <media>, representando un código
procedural, puede ser mapeado para un trecho de código (función, método etc.) o para un atributo del código.
Cuando es mapeado para un trecho de código, una acción de eslabón “set” aplicada a la propiedad debe
obligatoriamente causar la ejecución del código con los valores atribuidos interpretados como parámetros de
entrada. El atributo name del elemento <property> se debe utilizar obligatoriamente para identificar el trecho de
código procedural.
Un elemento <property> definido como hijo de un elemento <media> representa un código procedural, también
puede estar asociado a un assessment role de un eslabón NCL. En ese caso, el formateador NCL debe
obligatoriamente cuestionar el valor de la propiedad para evaluar la expresión del eslabón. Si el elemento
<property> es mapeado para un atributo de código, su valor debe ser retornado obligatoriamente por el exhibidor
procedural al formateador NCL. Si el elemento <property> es mapeado para un atributo de código, su valor debe
obligatoriamente ser retornado por el exhibidor procedural al formateador NCL. Si el elemento <property> es
mapeado para un trecho de código, debe obligatoriamente ser llamado y el valor del resultado de su ejecución
debe obligatoriamente ser retomado por el exhibidor procedural al formateador NCL.
La instrucción start emitida por un formateador debe informar obligatoriamente al exhibidor procedural los
siguientes parámetros: El objeto procedural a ser controlado, su descriptor asociado, una lista de eventos
(definidos por los elementos <area> y <property>, hijos del elemento <media> que define el objeto procedural)
que necesitan ser monitoreados por el exhibidor procedural, el identificador (id) del elemento <area> asociado al
código procedural a ser ejecutado, y un tiempo de retardo, opcional. Desde el atributo src, el exhibidor procedural
debe intentar localizar el código procedural e iniciar su ejecución. Si el contenido no se puede localizar, el
exhibidor procedural debe obligatoriamente finalizar la operación de inicialización sin realizar ninguna acción.
La lista de eventos a ser monitoreados por un exhibidor procedural se aconseja también que sea computada por
el formateador, teniendo en cuenta la especificación del documento NCL. Debe obligatoriamente chequear todos
los eslabones de los cuales participa el objeto de media procedural y el descriptor resultante. Al computar los
eventos a ser monitoreados, el formateador debe considerar obligatoriamente la perspectiva del objeto de media
procedural, es decir, el camino de los varios elementos <body> y <context> para alcanzar en profundidad el
elemento <media> correspondiente. Apenas eslabones contenidos en esos elementos <body> y <context> deben
ser considerados en la computación de los eventos monitoreados.
Como con todos los tipos de elemento <media>, el tiempo de retardo es un parámetro opcional, y su valor default
es “cero”. Si es mayor que cero, ese parámetro contiene un tiempo a ser esperado por el exhibidor procedural
antes de iniciar la ejecución.
A diferencia de los procedimientos realizados para otros tipos de elementos <media>, si un exhibidor procedural
recibe una instrucción start para un evento asociado a un elemento <area> y ese evento esté en el estado
sleeping, debe dar inicio a la ejecución del código procedural asociado al elemento, incluso si otra parte del
código procedural del objeto de media está en ejecución (pausado o no). Sin embargo, si el evento asociado al
elemento <area> destino está en el estado occurring o paused, la instrucción start debe ser ignorada por el
exhibidor procedural que continuará controlando la ejecución anteriormente iniciada. Como consecuencia,
a diferencia de lo que ocurre para los otros elementos <media>, una acción <simpleAction> con el atributo
actionType igual a “stop”, “pause”, “resume” o “abort” debe conectarse, a través de un eslabón, a una interfaz del
nudo procedural, que no debe ser ignorada cuando la acción se aplica.
La instrucción start emitida por un formateador para un evento asociado a un elemento <property> puede ser
aplicada a un objeto procedural independientemente de si está siendo ejecutado o no (en ese último caso,
aunque el objeto no esté siendo ejecutado, su exhibidor procedural debe obligatoriamente ya haber sido referido).
96
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
En el primer caso, la instrucción start necesita identificar el objeto procedural, un evento de atribución
monitoreado y un valor a ser pasado al código procedural asociado al evento. En el segundo caso, debe
obligatoriamente también identificar el elemento <descriptor> que será usado durante la ejecución del objeto
(análogo a lo que se hace para la instrucción start para eventos de pressentación).
Para cada evento de atribución monitoreado, si el exhibidor procedural cambia por sí mismo el valor del atributo,
debe proceder obligatoriamente como si hubiese recibido una instrucción externa de start.
Se recomienda que lenguajes procedurales ofrezcan una API que permita que los códigos procedurales
cuestionen cualquier valor de propiedades predefinidas o dinámicas del nudo settings NCL (elemento <media> del
tipo “application/x-ginga-settings”). Sin embargo, se debe observar que no se permite atribuir valores a esas
propiedades directamente. Las propiedades de los nudos del tipo application/x-ginga-settings sólo pueden ser
modificadas a través del uso de eslabones NCL.
9
Transmisión de contenido y eventos NCL
9.1 Bases privadas
El núcleo de la máquina de presentación Ginga-NCL está compuesto por el formateador NCL y su módulo Gestor
de Base Privada.
El formateador NCL es responsable por recibir un documento NCL y controlar su presentación, intentando
garantizar que las relaciones especificadas entre los objetos de media sean respetadas. El formateador trata con
documentos NCL que son recolectados dentro de una estructura de datos conocida como base privada. Ginga
asocia una base privada a un canal de televisión. Los documentos NCL en una base privada pueden ser iniciados,
pausados, retomados, parados y pueden referirse unos a los otros.
El Gestor de Base Privada es responsable por recibir comandos de edición de documentos NCL y por la edición
de los documentos NCL activos (documentos siendo presentados).
Esta subsección trata solamente de comandos de edición enviados por el canal de difusión terrestre.
NOTA
Los mismos comandos de edición también pueden ser recibidos por el canal de interactividad o por eventos
generados por los objetos imperativos NCLua y NCLet.
Ginga adopta secciones MPEG-2 específicas (identificadas por el campo tableID de la Sección MPEG-2) para
transportar los comandos de edición en flujos elementales MPEG-2 TS, cuando los comandos son enviados por el
canal de difusión terrestre.
Los Comandos de Edición son empaquetados en una estructura llamada descriptor de evento. Cada dsriptor de
evento tiene una esteructura compuesta, básicamente, por un id (identificación), una referencia de tiempo y un
campo de datos privados. La identificación define de forma unívoca cada evento.
La referencia de tiempo indica el exacto momento de disparar el evento. Un tiempo de referencia igual a cero
informa que el evento debe, obligatoriamente, ser inmediatamente disparado después de ser recibido (eventos
transportando este tipo de referencia de tiempo son comúnmente conocidos como eventos “do it now”). El campo
de datos privados ofrece soporte para parámetros del evento, como presenta la Figura 5.
Sintaxis
EventDescriptor ( ) {
eventId
eventNPT
privateDataLenght
commandTag
sequenceNumber
finalFlag
privateDataPayload
FCS
Número de bits
16
33
8
8
7
1
8 a 2008
8
}
Figura 5 – Descriptor de evento para comandos de edición
© ABNT 2007 - Todos los derechos reservados
97
ABNT NBR 15606-2:2007
El campo commandTag identifica en forma unívoca los comandos de edición, como especificado en la Tabla 56.
Para permitir enviar un comando completo con más de 255 bytes en más de un descriptor de evento, todos los
descriptores de un mismo comando deben obligatoriamente ser numerados y enviados en secuencia (o sea, no
puede ser multiplexado con otros comandos de edición con el mismo commandTag), con el finalFlag igual a 1,
excepto para el último receptor, que debe obligatoriamente tener el campo finalFlag igual a 0.
El privateDataPayload contiene los parámetros de comando de edición. Y por último, el campo FCS contiene un
checksum de todo el campo privateData, incluso el privateDataLength.
EJEMPLO
Eventos de flujo se pueden usar para transportar descriptores de eventos. El protocolo de carrusel de objetos
DSM-cc permite la transmisión cíclica de objetos de eventos y sistemas de archivo. Los objetos de eventos se utilizan para
mapear nombres de eventos de flujo en ids de eventos de flujo, definidos por los descriptores de evento. Los objetos de
eventos son utilizados para informar al Ginga sobre eventos de flujo DSN-CC que pueden recibirse. Los nombres de los
eventos permiten especificar tipos de eventos, ofreciendo mayor nivel de abstracción a las aplicaciones del middleware.
En ese caso, es conveniente que el Gestor de la Base Privada, así como los objetos de ejecución procedural NCL(ejemplo,
NCLua, NCLet), se registren como observadores de los eventos de flujo con los que trabajan, utilizando nombres de evento.
Los archivos de documento NCL y los contenidos de objeto de media NCL se organizan en estructuras de
sistemas de archivos. Los parámetros de comando de edición, basados en XML, pueden ser directamente
transportados en el playload de un descriptor de evento o, alternativamente, organizados en estructuras de
sistema de archivos a ser transportadas en el canal de difusión de datos o, incluso, ser recibidas por el canal de
interactividad.
EJEMPLO Un generador de carrusel DSM-CC podía usarse para unir los sistemas de archivos y los objetos de eventos de
flujo en un flujo elemental de datos. Cuando un comando de edición de documentos NCL precisara ser enviado, podría criarse
un objeto de eventos DSM-CC, mapeando la string “nclEditingCommand” en una id de evento de flujo, y entonces colocado en
un carrusel de objetos DSM-CC. Uno o más descriptores de evento de flujo DSM-CC con la id previamente seleccionada
podrían entonces ser creados y enviados en otro flujo elemental MPEG-2 TS. Estos eventos de flujo podrían tener su
referencia de tiempo fijada en cero, pero también podrían ser aplazados para ser ejecutados en un tiempo específico. El
Gestor de la Base Privada debería registrarse como un oyente “nclEditingCommand” y sería notificado cuando estos eventos
de flujo llegasen.
El commandTag recibido es utilizado por el Gestor de la Base Privada para interpretar la semántica de la
command string. Si el command parameter basado en XML es lo suficientemente corto, puede ser transportado
directamente en el payload de los descriptores de evento. Si no, el privateDatePayload transporta un conjunto de
pares de referencia. En el caso de archivos recibidos por el canal de difusión (documentos en nudos NCL
enviados sin solicitación), cada par relaciona un conjunto de caminos de archivos y su respectiva localización en
el sistema de transporte. En el caso de archivos recibidos sobre pedido por el canal de interactividad o localizados
en el propio receptor, ningún par de referencias necesita ser enviado, excepto el par {uri, “null”} asociado al
documento NCL o a la especificación XML del nudo NCL que deberá ser adicionado según el comando de adición
correspondiente.
La Tabla 56 muestra las strings de comando y, rodeados por paréntesis, los parámetros transportados como
contenido payload del descriptor de evento de nclEditingCommand. Los comandos se dividen en tres grupos:
El primero para operación de la base privada (para abrir, ativar, desactivar, cerrar y grabar bases privadas); el
segundo para manipulación de documento (para adicionar, borrar y grabar un documento en una base privada y
para iniciar, pausar, retomar y parar presentaciones de documentos); y el último para manejar entidades NCL.
Para cada entidad NCL, fueron definidos los comandos add y remove. Si una entidad ya existe, el comando add
tiene la semántica de actualización (alteración).”
NOTA
El primer grupo de comandos de operación normalmente no viene a través del canal de difusión de datos. Como ya
fue mencionado, comandos de edición también pueden ser recibidos por el canal de interactividad o venir de eventos
generados por objetos imperativos NCLua y NCLet. Los comandos de edición también pueden ser generados internamente
por el middleware.
98
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
Tabla 56 — Comandos de edición para el Gestor de la Base Privada Ginga
Tag de
comando
Descripción
openBase (baseId, location)
0x00
Abre una base privada existente localizada por el parámetro location. Si la base privada
no existe o si el parámetro location no es informado, una nueva base es creada con el
identificador baseId. El parámetro location debe obligatoriamente especificar el
dispositivo y el camino donde está la base a ser abierta
activateBase (baseId)
0x01
Activa una base privada abierta
deactivateBase (baseId)
0x02
Desactiva una base privada abierta
saveBase (baseId, location)
0x03
Graba todo el contenido de la base privada en un dispositivo de almacenamiento
persistente (si disponible). El parámetro location debe especificar obligatoriamente el
dispositivo y camino para grabar la base
closeBase (baseId)
0x04
Cierra la base privada y descarta todo el contenido de la base privada
String de comando
Agrega un documento NCL a una base privada. Los documentos NCL pueden ser:
a) enviados sin solicitación por la red de difusión de datos; en este caso, el par {uri, id}
se usa para relacionar un conjunto de caminos de archivos en el documento NCL con
sus respectivas localizaciones en el sistema de transporte (vea ejemplos en la Sección
12);
addDocument (baseId, {uri, ior}+)
0x05
NOTA Los conjuntos de pares de referencia obligatoriamente deben ser suficientes
para que el middleware pueda mapear cualquier referencia a archivos presentes en la
especificación del documento NCL en su localización concreta en la memoria del
dispositivo receptor.
b) recibidos por el canal de interactividad sobre pedido, o ya ser residentes en el
receptor; para estos archivos, ningún par {uri, id} necesita ser enviado, excepto el par
{uri, “null”} asociado al documento NCL, que deberá añadirse en la base baseId, si el
documento NCL no fuese recibido sin solicitación (pushed file)
removeDocument (baseId,
documentId)
saveDocument (baseId,
documented, location)
0x06
Remueve un documento NCL de una base privada
0x2E
Grava un documento NCL en un dispositivo de almacenamiento persistente (si
disponible). El parámetro location debe especificar el dispositivo y el camino en el
dispositivo en el que el documento será gravado. Si el documento NCL está siendo
exhibido, primero debe pararse (todos los eventos en el estado occurring se deben
parar)
Inicia la reproducción de un documento NCL en una base privada, empezando la
presentación desde una interfaz específica del documento. La referencia del tiempo
transportada en el campo eventNPT establece el punto de inicio del documento, con
respecto a la base de tiempo NPT del contenido refNodeId del documento
refDocumentId siendo recibido. Pueden darse tres casos:
startDocument (baseId, documentId,
interfaceId, offset, refDocumentId,
refNoteId)
0x07
a) Si eventNPT es mayor o igual al valor de NPT de la base temporal del contenido
refNodeId siendo recibido, se espera hasta que NPT alcance el valor dado en eventNPT
y empiece la exhibición del documento desde su punto inicial en el tiempo+offset
b) Si eventNPT es menor que el valor de NPT de la base temporal del contenido
refNodeId siendo recibido, el inicio de la exhibición del documento es inmediato y
desplazado en el tiempo de su punto inicial del valor “offset+(NPT – eventNPT)
segundos”
stopDocument (baseId,
documentId)
0x08
pauseDocument (baseId,
documentId)
0x09
© ABNT 2007 - Todos los derechos reservados
NOTA Solamente en este caso, el parámetro offset puede recibir un valor negativo,
pero offset+(NPT – eventNPT)segundos debe obligatoriamente ser un valor positivo
Para la presentación de un documento NCL en una base privada. Todos los eventos del
documento que están en marcha deben ser obligatoriamente parados
Pausa la presentación de un documento NCL en una base privada. Todos los eventos
del documento que están en marcha deben ser obligatoriamente pausados
99
ABNT NBR 15606-2:2007
Tabla 56 (continuación)
String de comando
resumeDocument (baseId, documentId)
Tag de comando
Descripción
0x0A
Retoma la presentación de un documento NCL en una base privada. Todos
los eventos del documento que fueron previamente pausados por el
comando de edición pauseDocument deben ser obligatoriamente retomados
Agrega un elemento <region> como hijo de otro <region> en el
addRegion (baseId, documentId,
regionBaseId, regionId, xmlRegion)
0x0B
<RegionBase>, o como hijo del <regionBase> (regionId=”null”)
de un documento NCL en una base privada
removeRegion (baseId, documentId,
regionId)
0x0C
addRegionBase (baseId, documentId,
xmlRegionBase)
0x0D
removeRegionBase (baseId, documentId,
regionBaseId)
0x0E
addRule (baseId, documentId, xmlRule)
0x0F
removeRule (baseId, documentId, ruleId)
0x10
addRuleBase (baseId, documentId,
xmlRuleBase)
100
0x11
Remueve un elemento <region> de un <regionBase> de un documento NCL
en una base privada
Agrega un elemento <regionBase> al elemento <head> de un documento
NCL en una base privada. Si la especificación XML del regionBase es
enviada en un sistema de transporte como un sistema de archivo, el
parámetro xmlRegionBase es sólo una referencia para ese contenido
Remueve un elemento <regionBase> del elemento <head> de un
documento NCL en una base privada
Agrega un elemento <rule> al <ruleBase> de un documento NCL en una
base privada
Remueve un elemento <rule> del <ruleBase> de un documento NCL en una
base privada
Agrega un elemento <ruleBase> al elemento <head> de un
documento NCL en una base privada. Si la especificación XML del
ruleBase es enviada en un sistema de transporte como un sistema
de archivo, el parámetro xmlRuleBase es apenas una referencia
para ese contenido
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
Tabla 56 (continuación)
Tag de
comando
Descripción
removeRuleBase (baseId, documentId,
ruleBaseId)
0x12
Remueve un elemento <ruleBase> del elemento
<head> de un documento NCL en una base
privada
addConnector (baseId, documentId,
xmlConnector)
0x13
Agrega un elemento <connector> al
<connectorBase> de un documento NCL en una
base privada
removeConnector (baseId, documentId,
connectorId)
0x14
Remueve un elemento <connector> del
<connectorBase> de un documento NCL en una
base privada
addConnectorBase (baseId, documentId,
xmlConnectorBase)
0x15
Agrega un elemento <connectorBase> al
elemento <head> de un documento NCL en una
base privada. Si la especificación XML del
connectorBase es enviada en un sistema de
transporte como un sistema de archivo, el
parámetro xmlConnectorBase es apenas una
referencia para ese contenido
removeConnectorBase (baseId, documentId,
connectorBaseId)
0x16
Remueve un elemento <connectorBase> del
elemento <head> de un documento NCL en una
base privada
addDescriptor (baseId, documentId,
xmlDescriptor)
0x17
Agrega un elemento <descriptor> al
<descriptorBase> de un documento NCL en una
base privada
removeDescriptor (baseId, documentId,
descriptorId)
0x18
Remueve un elemento <descriptor> del
<descriptorBase> de un documento NCL en una
base privada
addDescriptorSwitch (baseId, documentId,
xmlDescriptorSwitch)
0x19
Agrega un elemento <descriptorSwitch> al
<descriptorBase> de un documento NCL en una
base privada. Si la especificación XML del
descriptorSwitch es enviada en un sistema de
transporte como un sistema de archivo, el
parámetro xmlDescriptorSwitch es apenas una
referencia para ese contenido
removeDescriptorSwitch (baseId, documentId,
descriptorSwitchId)
0x1A
Remueve un elemento <descriptorSwitch> del
<descriptorBase> de un documento NCL en una
base privada
addDescriptorBase (baseId, documentId,
xmlDescriptorBase)
0x1B
Agrega un elemento <descriptorBase> al
elemento <head> de un documento NCL en una
base privada. Si la especificación XML del
descriptorBase es enviada en un sistema de
transporte como un sistema de archivo, el
parámetro xmlDescriptorBase es apenas una
referencia para ese contenido
removeDescriptorBase (baseId, documentId,
descriptorBaseId)
0x1C
Remueve un elemento <descriptorBase> del
elemento <head> de un documento NCL en una
base privada
addTransition (baseId, documentId,
xmlTransition)
0x1D
Agrega un elemento <transition> al
<transitionBase> de un documento NCL en una
base privada
removeTransition (baseId, documentId,
transitionId)
0x1E
Remueve un elemento <transition> del
<transitionBase> de un documento NCL en una
base privada
String de comando
© ABNT 2007 - Todos los derechos reservados
101
ABNT NBR 15606-2:2007
Tabla 56 (continuación)
String de comando
Tag de
comando
addTransitionBase (baseId, documentId,
xmlTransitionBase)
0x1F
removeTransitionBase (baseId, documentId,
transitionBaseId)
0x20
addImportBase (baseId, documentId, docBaseId,
xmlImportBase)
0x21
removeImportBase (baseId, documentId,
docBaseId, documentURI)
0x22
addImportedDocumentBase
(baseId, documentId, xmlImportedDocumentBase)
removeImportedDocumentBase (baseId,
documentId, importedDocumentBaseId)
addImportNCL (baseId, documentId,
xmlImportNCL)
0x23
0x24
0x25
removeImportNCL (baseId, documentId,
documentURI)
0x26
addNode (baseId, documentId, compositeId, {uri,
ior}+)
0x27
removeNode(baseId, documentId, compositeId,
nodeId)
0x28
addInterface (baseId, documentId, nodeId,
xmlInterface)
0x29
removeInterface (baseId, documentId, nodeId,
interfaceId)
0x2A
addLink (baseId, documentId, compositeId,
xmlLink)
0x2B
102
Descripción
Agrega un elemento <transitionBase> al elemento <head> de un
documento NCL en una base privada. Si la especificación XML del
transitionBase es enviada en un sistema de transporte como un sistema
de archivo, el parámetro xmlTransitionBase es apenas una referencia
para ese contenido
Remueve un elemento <transitionBase> del elemento <head> de un
documento NCL en una base privada
Agrega un elemento <importBase> a la base (elemento <regionBase>,
<descriptorBase>, <ruleBase>, <transitionBase>, o <connectorBase>) de
un documento NCL en una base privada
Remueve un elemento <importBase>, cuyo atributo documentURI es
identificado por el parámetro documentURI, desde la base (elemento
<regionBase>, <descriptorBase>, <ruleBase>, <transitionBase>, o
<connectorBase>) de un documento NCL en una base privada
Agrega un elemento <importedDocumentBase> al elemento <head> de
un documento NCL en una base privada
Remueve un elemento <importedDocumentBase> del elemento
<head> de un documento NCL en una base privada
Agrega un elemento <importNCL> al elemento
<importedDocumentBase> de un documento NCL en una base privada
Remueve un elemento <importNCL>, cuyo atributo documentURI es
identificado por el parámetro documentURI, desde el
<importedDocumentBase> de un documento NCL en una base privada
Agrega un nudo (elemento <media>, <context> o <switch>) a un nudo
de composición (elemento <body>, <context> o <switch>) de un
documento NCL en una base privada. La especificación XML del nudo
y su contenido de media pueden:
a) ser enviados sin solicitación por la red de difusión de datos; en ese
caso, el par {uri, id} es usado para relacionar un conjunto de caminos
de archivos, definidos en el documento XML de la especificación del
nudo, con sus respectivas localizaciones en el sistema de transporte
(ver ejemplos en la Sección 12);
NOTA Los conjuntos de pares de referencia deben obligatoriamente
ser suficientes para que el middleware pueda mapear cualquier
referencia a archivos, presentes en la especificación del nudo, en su
localización concreta en la memoria del dispositivo receptor.
b) ser recibidos por el canal de interactividad sobre pedido o ya ser
residentes en el receptor; para estos archivos, ningún par {uri, id}
necesita ser enviado, excepto el par {uri, “null”} asociado a la
especialización XML del nudo NCL que deberá ser adicionado en
compositeId, en el caso de que el documento XML no se reciba sin
solicitación (pushed file)
Remueve un nudo (elemento <media>, <context> o <switch>) de un
nudo de composición (elemento <body>, <context> o <switch>) de un
documento NCL en una base privada
Agrega una interfaz (<port>, <area>, <property> o <switchPort>) a un
nudo (elemento <media>, <body>, <context> o <switch>) de un
documento NCL en una base privada
Remueve una interfaz (<port>, <area>, <property>, o <switchPort>) de
un nudo (elemento <media>, <body>, <context> o <switch>) de un
documento NCL en una base privada. La interfaceID debe identificar
obligatoriamente un atributo name de un elemento <property> o un
atributo id de un elemento <port>, <area> o <switchPort>
Agrega un elemento <link> a un nudo de composición (elemento
<body>, <context> o <switch>) de un documento NCL en una base
privada
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
Tabla 56 (continuación)
String de comando
removeLink (baseId, documentId, compositeId,
linkId)
setPropertyValue(baseId, documentId, nodeId,
propertyId, value)
Tag de
comando
Descripción
0x2C
Remueve un elemento <link> de un nudo de composición (elemento
<body>, <context> o <switch>) de un documento NCL en una base
privada
0x2D
Atribuye el valor a una propiedad. La propertyId debe identificar
obligatoriamente un atributo name de un elemento <property> o un
atributo id de elemento <switchPort>. El <property> o <switchPort> debe
obligatoriamente pertenecer a un nudo (elemento <body>, <context>,
<switch> o <media>) de un documento NCL en una base privada
identificada por los parámetros
Los receptores que solamente implementan el perfil NCL DTV Básico pueden no manejar los siguientes
comandos: pauseDocument, resumeDocument, addTransition, remove Transition, add TransitionBase y remove
TransitionBase.
Ginga asocia una base privada a un canal de televisión. Cuando un canal es sintonizado, su base privada
correspondiente es abierta y activada por el Gestor de la Base Privada; otras bases privadas deben ser
desactivadas. Por razones de seguridad, sólo una única base privada puede estar activa por vez. El modo más
simple y restrictivo de gestionar bases privadas es tener una única base privada abierta por vez. Así, si el usuario
cambia el canal seleccionado, es recomendable cerrar la base privada actual. En este caso, el comando
openBase es siempre seguido por el comando activeBase y el comando deactiveBase nunca se utiliza.
Sin embargo, el número de bases privadas que pueden mantenerse abiertas es una decisión de implementación
del middleware.
Los comandos add tienen entidades NCL como sus argumentos (parámetros de comando basados en XML). Si la
entidad especificada ya existe o no, la consistencia del documento debe ser obligatoriamente mantenida por el
formateador NCL, en el sentido de que todos los atributos de identidad clasificados como obligatorios se deben
definir obligatoriamente. Las entidades se definen utilizando una notación sintáctica idéntica a aquella usada por
los esquemas NCL, con excepción del comando addInterface: el atributo begin de un elemento <area> puede
recibir el valor “now”, especificando el NPT actual del nodeId, que debe ser obligatoriamente el video principal
MPEG siendo reproducido por el decodificador de hardware.
Los identificadores utilizados en los comandos deben estar de acuerdo obligatoriamente con la Tabla 57.
Tabla 57 — Identificadores que se utilizan en los comandos de edición
Identificadores
Definición
baseId
Identificadores de canal de radiodifusión especificados por el SBTVD
DocumentId
Atributo id de un elemento <ncl> de un documento NCL
refDocumentId
Atributo id de un elemento <ncl> de un documento NCL
refNodeId
Atributo id de un elemento <media> de un documento NCL
regionId
Atributo id de un elemento <region> de un documento NCL
ruleId
Atributo id de un elemento <rule> de un documento NCL
connectorId
Atributo id de un elemento <connector> de un documento NCL
descriptorId
Atributo id de un elemento <descriptor> de un documento NCL
descriptorSwitchId
Atributo id de un elemento <descriptorSwitch> de un documento NCL
transitionId
Atributo id de un elemento <transition> de un documento NCL
regionBaseId
Atributo id de un elemento <regionBase> de un documento NCL
ruleBaseId
Atributo id de un elemento <ruleBase> de un documento NCL
© ABNT 2007 - Todos los derechos reservados
103
ABNT NBR 15606-2:2007
Tabla 57 (continuación)
Identificadores
Definición
connectorBaseId
Atributo id de un elemento <connectorBase> de un documento NCL
descriptorBaseId
transitionBaseId
Atributo id de un elemento <descriptorBase> de un documento NCL
Atributo id de un elemento <transitionBase> de un documento NCL
docBaseId
Atributo id de un elemento <regionBase>, <ruleBase>, <connectorBase>,
<descriptorBase>, o <transitionBase> de un documento NCL
documentU RI
Atributo documentURI de un elemento <importBase> o un elemento
<importNCL> de un documento NCL
importedDocumentBaseId
Atributo id de un elemento <importedDocumentBase> de un documento
NCL
compositeID
Atributo id de un elemento <body>, <context> o <switch> de un document
NCL
nodeId
Atributo id de un elemento <body>, <context>, <switch> o <media> de un
documento NCL
interfaceId
Atributo id de un elemento <port>, <area>, <property> o <switchPort> de
un documento NCL
linkId
Atributo id de un elemento <link> de un documento NCL
propertyId
Atributo id de un elemento <property>, o <switchPort> de un documento
NCL
9.2 Esquema XML de los parámetros de comando
Las entidades NCL utilizadas en los comandos de edición deben ser obligatoriamente un documento de
conformidad con el perfil de Comando NCL 3.0 definido por el esquema XML a continuación. Conviene que los
receptores que apenas implementan el perfil Básico NCL DTV ignoren los elementos y atributos XML
relacionados a las funcionalidades de Meta-information y Transition Efects.
Observar que, diferentemente de los documentos NCL, diversos elementos NCL pueden tener el elemento raíz en
los parámetros de comando XML.
NCL30EdCommand.xsd
<!-XML Schema for the NCL Language
This is NCL
Copyright: 2000-2005 PUC-RIO/LABORATORIO TELEMIDIA, All Rights Reserved.
See http://www.telemidia.puc-rio.br
Public URI: http://www.ncl.org.br/NCL3.0/profiles/NCL30EdCommand.xsd
Author: TeleMidia Laboratory
Revision: 19/09/2006
-->
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:animation="http://www.ncl.org.br/NCL3.0/Animation"
xmlns:compositeInterface="http://www.ncl.org.br/NCL3.0/CompositeNodeInterface"
xmlns:causalConnectorFunctionality="http://www.ncl.org.br/NCL3.0/CausalConnectorFunctionality"
xmlns:connectorBase="http://www.ncl.org.br/NCL3.0/ConnectorBase"
xmlns:connectorCausalExpression="http://www.ncl.org.br/NCL3.0/ConnectorCausalExpression"
104
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
xmlns:contentControl="http://www.ncl.org.br/NCL3.0/ContentControl"
xmlns:context="http://www.ncl.org.br/NCL3.0/Context"
xmlns:descriptor="http://www.ncl.org.br/NCL3.0/Descriptor"
xmlns:entityReuse="http://www.ncl.org.br/NCL3.0/EntityReuse"
xmlns:extendedEntityReuse="http://www.ncl.org.br/NCL3.0/ExtendedEntityReuse"
xmlns:descriptorControl="http://www.ncl.org.br/NCL3.0/DescriptorControl"
xmlns:import="http://www.ncl.org.br/NCL3.0/Import"
xmlns:keyNavigation="http://www.ncl.org.br/NCL3.0/KeyNavigation"
xmlns:layout="http://www.ncl.org.br/NCL3.0/Layout"
xmlns:linking="http://www.ncl.org.br/NCL3.0/Linking"
xmlns:media="http://www.ncl.org.br/NCL3.0/Media"
xmlns:mediaAnchor="http://www.ncl.org.br/NCL3.0/MediaContentAnchor"
xmlns:propertyAnchor="http://www.ncl.org.br/NCL3.0/PropertyAnchor"
xmlns:structure="http://www.ncl.org.br/NCL3.0/Structure"
xmlns:switchInterface="http://www.ncl.org.br/NCL3.0/SwitchInterface"
xmlns:testRule="http://www.ncl.org.br/NCL3.0/TestRule"
xmlns:testRuleUse="http://www.ncl.org.br/NCL3.0/TestRuleUse"
xmlns:timing="http://www.ncl.org.br/NCL3.0/Timing"
xmlns:transitionBase="http://www.ncl.org.br/NCL3.0/TransitionBase"
xmlns:metainformation="http://www.ncl.org.br/NCL3.0/Metainformation"
xmlns:transition="http://www.ncl.org.br/NCL3.0/Transition"
xmlns:profile="http://www.ncl.org.br/NCL3.0/EdCommandProfile"
targetNamespace="http://www.ncl.org.br/NCL3.0/EdCommandProfile"
elementFormDefault="qualified" attributeFormDefault="unqualified" >
<!-- import the definitions in the modules namespaces -->
<import namespace="http://www.ncl.org.br/NCL3.0/Animation"
schemaLocation="http://www.ncl.org.br/NCL3.0/modules/NCL30Animation.xsd"/>
<import namespace="http://www.ncl.org.br/NCL3.0/CompositeNodeInterface"
schemaLocation="http://www.ncl.org.br/NCL3.0/modules/NCL30CompositeNodeInterface.xsd"/>
<import namespace="http://www.ncl.org.br/NCL3.0/CausalConnectorFunctionality"
schemaLocation="http://www.ncl.org.br/NCL3.0/modules/NCL30CausalConnectorFunctionality.xsd"/>
<import namespace="http://www.ncl.org.br/NCL3.0/ConnectorBase"
schemaLocation="http://www.ncl.org.br/NCL3.0/modules/NCL30ConnectorBase.xsd"/>
<import namespace="http://www.ncl.org.br/NCL3.0/ConnectorCausalExpression"
schemaLocation="http://www.ncl.org.br/NCL3.0/modules/NCL30ConnectorCausalExpression.xsd"/>
<import namespace="http://www.ncl.org.br/NCL3.0/ContentControl"
schemaLocation="http://www.ncl.org.br/NCL3.0/modules/NCL30ContentControl.xsd"/>
<import namespace="http://www.ncl.org.br/NCL3.0/Context"
schemaLocation="http://www.ncl.org.br/NCL3.0/modules/NCL30Context.xsd"/>
<import namespace="http://www.ncl.org.br/NCL3.0/Descriptor"
schemaLocation="http://www.ncl.org.br/NCL3.0/modules/NCL30Descriptor.xsd"/>
<import namespace="http://www.ncl.org.br/NCL3.0/DescriptorControl"
schemaLocation="http://www.ncl.org.br/NCL3.0/modules/NCL30DescriptorControl.xsd"/>
<import namespace="http://www.ncl.org.br/NCL3.0/EntityReuse"
schemaLocation="http://www.ncl.org.br/NCL3.0/modules/NCL30EntityReuse.xsd"/>
<import namespace="http://www.ncl.org.br/NCL3.0/ExtendedEntityReuse"
schemaLocation="http://www.ncl.org.br/NCL3.0/modules/NCL30ExtendedEntityReuse.xsd"/>
<import namespace="http://www.ncl.org.br/NCL3.0/Import"
schemaLocation="http://www.ncl.org.br/NCL3.0/modules/NCL30Import.xsd"/>
<import namespace="http://www.ncl.org.br/NCL3.0/KeyNavigation"
schemaLocation="http://www.ncl.org.br/NCL3.0/modules/NCL30KeyNavigation.xsd"/>
<import namespace="http://www.ncl.org.br/NCL3.0/Layout"
schemaLocation="http://www.ncl.org.br/NCL3.0/modules/NCL30Layout.xsd"/>
<import namespace="http://www.ncl.org.br/NCL3.0/Linking"
schemaLocation="http://www.ncl.org.br/NCL3.0/modules/NCL30Linking.xsd"/>
<import namespace="http://www.ncl.org.br/NCL3.0/Media"
schemaLocation="http://www.ncl.org.br/NCL3.0/modules/NCL30Media.xsd"/>
<import namespace="http://www.ncl.org.br/NCL3.0/MediaContentAnchor"
schemaLocation="http://www.ncl.org.br/NCL3.0/modules/NCL30MediaContentAnchor.xsd"/>
<import namespace="http://www.ncl.org.br/NCL3.0/PropertyAnchor"
schemaLocation="http://www.ncl.org.br/NCL3.0/modules/NCL30PropertyAnchor.xsd"/>
<import namespace="http://www.ncl.org.br/NCL3.0/Structure"
schemaLocation="http://www.ncl.org.br/NCL3.0/modules/NCL30Structure.xsd"/>
© ABNT 2007 - Todos los derechos reservados
105
ABNT NBR 15606-2:2007
schemaLocation="http://www.ncl.org.br/NCL3.0/modules/NCL30SwitchInterface.xsd"/>
<import namespace="http://www.ncl.org.br/NCL3.0/TestRule"
schemaLocation="http://www.ncl.org.br/NCL3.0/modules/NCL30TestRule.xsd"/>
<import namespace="http://www.ncl.org.br/NCL3.0/TestRuleUse"
schemaLocation="http://www.ncl.org.br/NCL3.0/modules/NCL30TestRuleUse.xsd"/>
<import namespace="http://www.ncl.org.br/NCL3.0/Timing"
schemaLocation="http://www.ncl.org.br/NCL3.0/modules/NCL30Timing.xsd"/>
<import namespace="http://www.ncl.org.br/NCL3.0/TransitionBase"
schemaLocation="http://www.ncl.org.br/NCL3.0/modules/NCL30TransitionBase.xsd"/>
import namespace="http://www.ncl.org.br/NCL3.0/Metainformation"
schemaLocation="http://www.ncl.org.br/NCL3.0/modules/NCL30Metainformation.xsd"/>
..<import namespace="http://www.ncl.org.br/NCL3.0/Transition"
….schemaLocation="http://www.ncl.org.br/NCL3.0/modules/NCL30Transition.xsd"/>
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!--EditingCommand
-->
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!--defines the command element -->
<!--This is a pseudo-element, only defined to show the elements that may be used in the root of the command parameters
XML document-->
<!-<complexType name="commandType">
<choice minOccurs="1" maxOccurs="1">
<element ref="profile:ncl"/>
<element ref="profile:region"/>
<element ref="profile:rule"/>
<element ref="profile:connector"/>
<element ref="profile:descriptor"/>
<element ref="profile:descriptorSwitch"/>
<element ref="profile:transition"/>
<element ref="profile:regionBase"/>
<element ref="profile:ruleBase"/>
<element ref="profile:connectorBase"/>
<element ref="profile:descriptorBase"/>
<element ref="profile:transitionBase"/>
<element ref="profile:importBase"/>
<element ref="profile:importedDocumentBase"/>
<element ref="profile:importNCL"/>
<element ref="profile:media"/>
<element ref="profile:context"/>
<element ref="profile:switch"/>
<element ref="profile:port"/>
<element ref="profile:area"/>
<element ref="profile:property"/>
<element ref="profile:switchPort"/>
<element ref="profile:link"/>
<element ref=”profile:meta”/>
<element ref=”profile:metadata”/>
</choice>
</complexType>
<element name="command" type="profile:commandType"/>
-->
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- Structure
-->
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- extends ncl element -->
<element name="ncl" substitutionGroup="structure:ncl"/>
<!-- extends head element -->
<complexType name="headType">
106
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
<complexContent>
<extension base="structure:headPrototype">
<sequence>
<element ref="profile:importedDocumentBase" minOccurs="0" maxOccurs="1"/>
<element ref="profile:ruleBase" minOccurs="0" maxOccurs="1"/>
<element ref="profile:transitionBase" minOccurs="0" maxOccurs="1"/>
<element ref="profile:regionBase" minOccurs="0" maxOccurs="unbounded"/>
<element ref="profile:descriptorBase" minOccurs="0" maxOccurs="1"/>
<element ref="profile:connectorBase" minOccurs="0" maxOccurs="1"/>
<element ref="profile:meta" minOccurs="0" maxOccurs="unbounded"/>
<element ref="profile:metadata" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
<element name="head" type="profile:headType" substitutionGroup="structure:head"/>
<!-- extends body element -->
<complexType name="bodyType">
<complexContent>
<extension base="structure:bodyPrototype">
<choice minOccurs="0" maxOccurs="unbounded">
<group ref="profile:contextInterfaceElementGroup"/>
<element ref="profile:media"/>
<element ref="profile:context"/>
<element ref="profile:switch"/>
<element ref="profile:link"/>
</choice>
</extension>
</complexContent>
</complexType>
<element name="body" type="profile:bodyType" substitutionGroup="structure:body"/>
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- Layout
-->
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- extends regionBase element -->
<complexType name="regionBaseType">
<complexContent>
<extension base="layout:regionBasePrototype">
<choice minOccurs="1" maxOccurs="unbounded">
<element ref="profile:region"/>
<element ref="profile:importBase"/>
</choice>
</extension>
</complexContent>
</complexType>
<complexType name="regionType">
<complexContent>
<extension base="layout:regionPrototype">
</extension>
</complexContent>
</complexType>
<element name="regionBase" type="profile:regionBaseType" substitutionGroup="layout:regionBase"/>
<element name="region" type="profile:regionType" substitutionGroup="layout:region"/>
© ABNT 2007 - Todos los derechos reservados
107
ABNT NBR 15606-2:2007
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- Media
-->
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- extends Media elements -->
<!-- media interface element groups -->
<group name="mediaInterfaceElementGroup">
<choice>
<element ref="profile:area"/>
<element ref="profile:property"/>
</choice>
</group>
<complexType name="mediaType">
<complexContent>
<extension base="media:mediaPrototype">
<choice minOccurs="0" maxOccurs="unbounded">
<group ref="profile:mediaInterfaceElementGroup"/>
</choice>
<attributeGroup ref="descriptor:descriptorAttrs"/>
<attributeGroup ref="entityReuse:entityReuseAttrs"/>
<attributeGroup ref="extendedEntityReuse:extendedEntityReuseAttrs"/>
</extension>
</complexContent>
</complexType>
<element name="media" type="profile:mediaType" substitutionGroup="media:media"/>
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- Context
-->
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- extends context element -->
<!-- composite node interface element groups -->
<group name="contextInterfaceElementGroup">
<choice>
<element ref="profile:port"/>
<element ref="profile:property"/>
</choice>
</group>
<complexType name="contextType">
<complexContent>
<extension base="context:contextPrototype">
<choice minOccurs="0" maxOccurs="unbounded">
<group ref="profile:contextInterfaceElementGroup"/>
<element ref="profile:media"/>
<element ref="profile:context"/>
<element ref="profile:link"/>
<element ref="profile:switch"/>
<element ref=”profile:meta”/>
<element ref=”profile:metadata”/>
</choice>
<attributeGroup ref="entityReuse:entityReuseAttrs"/>
</extension>
</complexContent>
</complexType>
<element name="context" type="profile:contextType" substitutionGroup="context:context"/>
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- MediaContentAnchor
-->
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- extends area element -->
<complexType name="componentAnchorType">
108
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
<complexContent>
<extension base="mediaAnchor:componentAnchorPrototype">
<attribute name="now" type="string" use="optional"/>
</extension>
</complexContent>
</complexType>
<element name="area" type="profile:componentAnchorType" substitutionGroup="mediaAnchor:area"/>
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- CompositeNodeInterface
-->
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- extends port element -->
<complexType name="compositeNodePortType">
<complexContent>
<extension base="compositeInterface:compositeNodePortPrototype">
</extension>
</complexContent>
</complexType>
<element name="port" type="profile:compositeNodePortType" substitutionGroup="compositeInterface:port"/>
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- PropertyAnchor
-->
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- extends property element -->
<complexType name="propertyAnchorType">
<complexContent>
<extension base="propertyAnchor:propertyAnchorPrototype">
</extension>
</complexContent>
</complexType>
<element name="property" type="profile:propertyAnchorType" substitutionGroup="propertyAnchor:property"/>
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- SwitchInterface
-->
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- extends switchPort element -->
<complexType name="switchPortType">
<complexContent>
<extension base="switchInterface:switchPortPrototype">
</extension>
</complexContent>
</complexType>
<element name="mapping" substitutionGroup="switchInterface:mapping"/>
<element name="switchPort" type="profile:switchPortType" substitutionGroup="switchInterface:switchPort"/>
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- Descriptor
-->
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- substitutes descriptorParam element -->
<element name="descriptorParam" substitutionGroup="descriptor:descriptorParam"/>
© ABNT 2007 - Todos los derechos reservados
109
ABNT NBR 15606-2:2007
<complexType name="descriptorType">
<complexContent>
<extension base="descriptor:descriptorPrototype">
<attributeGroup ref="layout:regionAttrs"/>
<attributeGroup ref="timing:explicitDurAttrs"/>
<attributeGroup ref="timing:freezeAttrs"/>
<attributeGroup ref="keyNavigation:keyNavigationAttrs"/>
<attributeGroup ref="transition:transAttrs"/>
</extension>
</complexContent>
</complexType>
<element name="descriptor" type="profile:descriptorType" substitutionGroup="descriptor:descriptor"/>
<!-- extends descriptorBase element -->
<complexType name="descriptorBaseType">
<complexContent>
<extension base="descriptor:descriptorBasePrototype">
<choice minOccurs="1" maxOccurs="unbounded">
<element ref="profile:importBase"/>
<element ref="profile:descriptor"/>
<element ref="profile:descriptorSwitch"/>
</choice>
</extension>
</complexContent>
</complexType>
<element name="descriptorBase" type="profile:descriptorBaseType" substitutionGroup="descriptor:descriptorBase"/>
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- Linking
-->
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- substitutes linkParam and bindParam elements -->
<element name="linkParam" substitutionGroup="linking:linkParam"/>
<element name="bindParam" substitutionGroup="linking:bindParam"/>
<!-- extends bind element and link element, as a consequence-->
<complexType name="bindType">
<complexContent>
<extension base="linking:bindPrototype">
<attributeGroup ref="descriptor:descriptorAttrs"/>
</extension>
</complexContent>
</complexType>
<element name="bind" type="profile:bindType" substitutionGroup="linking:bind"/>
<!-- extends link element -->
<complexType name="linkType">
<complexContent>
<extension base="linking:linkPrototype">
</extension>
</complexContent>
</complexType>
<element name="link" type="profile:linkType" substitutionGroup="linking:link"/>
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- Connector
-->
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- extends connectorBase element -->
<complexType name="connectorBaseType">
110
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
<complexContent>
<extension base="connectorBase:connectorBasePrototype">
<choice minOccurs="0" maxOccurs="unbounded">
<element ref="profile:importBase"/>
<element ref="profile:causalConnector" />
</choice>
</extension>
</complexContent>
</complexType>
<complexType name="simpleActionType">
<complexContent>
<extension base="connectorCausalExpression:simpleActionPrototype">
<attributeGroup ref="animation:animationAttrs"/>
</extension>
</complexContent>
</complexType>
<element name="connectorBase" type="profile:connectorBaseType" substitutionGroup="connectorBase:connectorBase"/>
<element name="causalConnector" substitutionGroup="causalConnectorFunctionality:causalConnector"/>
<element name="connectorParam" substitutionGroup="causalConnectorFunctionality:connectorParam"/>
<element name="simpleCondition" substitutionGroup="causalConnectorFunctionality:simpleCondition"/>
<element name="compoundCondition" substitutionGroup="causalConnectorFunctionality:compoundCondition"/>
<element name="simpleAction" type="profile:simpleActionType"
substitutionGroup="causalConnectorFunctionality:simpleAction"/>
<element name="compoundAction" substitutionGroup="causalConnectorFunctionality:compoundAction"/>
<element name="assessmentStatement" substitutionGroup="causalConnectorFunctionality:assessmentStatement"/>
<element name="attributeAssessment" substitutionGroup="causalConnectorFunctionality:attributeAssessment"/>
<element name="valueAssessment" substitutionGroup="causalConnectorFunctionality:valueAssessment"/>
<element name="compoundStatement" substitutionGroup="causalConnectorFunctionality:compoundStatement"/>
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- TestRule
-->
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- extends rule element -->
<complexType name="ruleType">
<complexContent>
<extension base="testRule:rulePrototype">
</extension>
</complexContent>
</complexType>
<element name="rule" type="profile:ruleType" substitutionGroup="testRule:rule"/>
<!-- extends compositeRule element -->
<complexType name="compositeRuleType">
<complexContent>
<extension base="testRule:compositeRulePrototype">
</extension>
</complexContent>
</complexType>
<element name="compositeRule" type="profile:compositeRuleType" substitutionGroup="testRule:compositeRule"/>
<!-- extends ruleBase element -->
© ABNT 2007 - Todos los derechos reservados
111
ABNT NBR 15606-2:2007
<complexType name="ruleBaseType">
<complexContent>
<extension base="testRule:ruleBasePrototype">
<choice minOccurs="1" maxOccurs="unbounded">
<element ref="profile:importBase"/>
<element ref="profile:rule"/>
<element ref="profile:compositeRule"/>
</choice>
</extension>
</complexContent>
</complexType>
<element name="ruleBase" type="profile:ruleBaseType" substitutionGroup="testRule:ruleBase"/>
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- TestRuleUse
-->
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- extends bindRule element -->
<complexType name="bindRuleType">
<complexContent>
<extension base="testRuleUse:bindRulePrototype">
</extension>
</complexContent>
</complexType>
<element name="bindRule" type="profile:bindRuleType" substitutionGroup="testRuleUse:bindRule"/>
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- ContentControl
-->
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- extends switch element -->
<!-- switch interface element groups -->
<group name="switchInterfaceElementGroup">
<choice>
<element ref="profile:switchPort"/>
</choice>
</group>
<!-- extends defaultComponent element -->
<complexType name="defaultComponentType">
<complexContent>
<extension base="contentControl:defaultComponentPrototype">
</extension>
</complexContent>
</complexType>
<element name="defaultComponent" type="profile:defaultComponentType"
substitutionGroup="contentControl:defaultComponent"/>
<complexType name="switchType">
<complexContent>
<extension base="contentControl:switchPrototype">
<choice minOccurs="0" maxOccurs="unbounded">
<group ref="profile:switchInterfaceElementGroup"/>
<element ref="profile:bindRule"/>
<element ref="profile:switch"/>
<element ref="profile:media"/>
<element ref="profile:context"/>
</choice>
<attributeGroup ref="entityReuse:entityReuseAttrs"/>
</extension>
</complexContent>
</complexType>
112
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
<element name="switch" type="profile:switchType" substitutionGroup="contentControl:switch"/>
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- DescriptorControl
-->
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- extends defaultDescriptor element -->
<complexType name="defaultDescriptorType">
<complexContent>
<extension base="descriptorControl:defaultDescriptorPrototype">
</extension>
</complexContent>
</complexType>
<element name="defaultDescriptor" type="profile:defaultDescriptorType"
substitutionGroup="descriptorControl:defaultDescriptor"/>
<!-- extends descriptorSwitch element -->
<complexType name="descriptorSwitchType">
<complexContent>
<extension base="descriptorControl:descriptorSwitchPrototype">
<choice minOccurs="0" maxOccurs="unbounded">
<element ref="profile:descriptor"/>
<element ref="profile:bindRule"/>
</choice>
</extension>
</complexContent>
</complexType>
<element name="descriptorSwitch" type="profile:descriptorSwitchType"
substitutionGroup="descriptorControl:descriptorSwitch"/>
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- Timing
-->
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- Import
-->
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<complexType name="importBaseType">
<complexContent>
<extension base="import:importBasePrototype">
</extension>
</complexContent>
</complexType>
<complexType name="importNCLType">
<complexContent>
<extension base="import:importNCLPrototype">
</extension>
</complexContent>
</complexType>
<complexType name="importedDocumentBaseType">
<complexContent>
<extension base="import:importedDocumentBasePrototype">
</extension>
</complexContent>
</complexType>
<element name="importBase" type="profile:importBaseType" substitutionGroup="import:importBase"/>
<element name="importNCL" type="profile:importNCLType" substitutionGroup="import:importNCL"/>
© ABNT 2007 - Todos los derechos reservados
113
ABNT NBR 15606-2:2007
<element name="importedDocumentBase" type="profile:importedDocumentBaseType"
substitutionGroup="import:importedDocumentBase"/>
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- EntityReuse
-->
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- ExtendedEntityReuse
-->
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- KeyNavigation
-->
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- TransitionBase
-->
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- extends transitionBase element -->
<complexType name="transitionBaseType">
<complexContent>
<extension base="transitionBase:transitionBasePrototype">
<choice minOccurs="0" maxOccurs="unbounded">
<element ref="profile:transition"/>
<element ref="profile:importBase"/>
</choice>
</extension>
</complexContent>
</complexType>
<element name="transitionBase" type="profile:transitionBaseType" substitutionGroup="transitionBase:transitionBase"/>
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- Transition -->
<!-- =========================================================== -->
<element name="transition" substitutionGroup="transition:transition"/>
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- Metainformation
-->
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<element name="meta" substitutionGroup="metainformation:meta"/>
<element name="metadata" substitutionGroup="metainformation:metadata"/>
</schema>
10 Objetos procedurales Lua en presentaciones NCL
10.1 Lenguaje Lua - Funciones retiradas de la biblioteca de Lua
El lenguaje de script adoptado por el Ginga-NCL es Lua (elementos <media> del tipo application/x-ginga-NCLua).
La definición completa de Lua se presenta en el Anexo B.
Las funciones a continuación son dependientes de plataforma y fueron retiradas:
a)
en el módulo package: loadlib;
b)
en el módulo io: todas las funciones;
c)
en el módulo os: clock, execute, exit, getenv, remove, rename, tmpname y setlocale;
114
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
d)
en el módulo debug: todas las funciones.
10.2 Modelo de ejecución
El ciclo de vida de un objeto NCLua es controlado por el formateador NCL. El formateador es responsable por
iniciar la ejecución de un objeto NCLua y por mediar la comunicación entre ese objeto y otros objetos en un
documento NCL, como definido en 8.5.
Como con todos los exhibidores de objetos de media, un exhibidor Lua, una vez referido, debe ejecutar los
procedimientos de iniciación del objeto NCL que controlará. Sin embargo, diferentemente de los demás
exhibidores de media, el código de iniciación debe también ser especificado por el autor del objeto NCLua. Los
procedimientos de iniciación se ejecutan una sola vez, para cada instancia, y crean funciones y objetos que se
pueden usar durante la ejecución del objeto NCLua y, en particular, registra uno o más tratadores de eventos para
la comunicación con el formateador NCL.
Después de la iniciación, la ejecución del objeto NCLua se torna orientada a evento, en ambas direcciones. Es
decir, cualquier acción comandada por el formateador NCL es dirigida a los tratadores de evento registrados, y
cualquier notificación de cambio de estado de eventos NCL es enviada como un evento al formateador NCL
(como por ejemplo, el fin de la ejecución del código de procedimiento). El exhibidor Lua estará entonces listo para
ejecutar cualquier intrusión de start o set (ver 8.5).
10.3 Módulos adicionales
10.3.1 Módulos obligatorios
Además de la biblioteca estándar de Lua, los siguientes módulos deben ser obligatoriamente ofrecidos y
automáticamente cargados:
a)
módulo canvas: ofrece una API para dibujar primitivas gráficas y manejar imágenes;
b)
módulo event: permite que aplicaciones NCLua se comuniquen con el middleware a través de eventos
(eventos NCL y de teclas);
c)
módulo settings: exporta una tabla con variables definidas por el autor del documento NCL y variables de
ambiente reservadas en un nudo "application/x-ginga-settings";
d)
módulo persistent: exporta una tabla con variables persistentes, que están disponibles para manipulación
apenas por objetos de procedimiento.
La definición de cada función en los módulos mencionados respeta la siguiente nomenclatura:
funcname (parnameI: partypeI [; optnameI: opttypeI]) -> retname: rettype
10.3.2 Módulo canvas
10.3.2.1
Objeto canvas
Cuando un objeto de media NCLua es iniciado, la región del elemento <media> correspondiente (del tipo
application/x-ginga-NCLua) queda disponible como la variable global canvas para el script Lua. Si el elemento de
<media> no tiene ninguna región especificada (propiedades left, right, Top and bottom), entonces el valor para
canvas debe ser establecido como “nil”.
Ejemplo: para una región definida en un documento NCL como:
<Region iD="luaRegion" width="300" height="100" Top="200" left="20"/>
© ABNT 2007 - Todos los derechos reservados
115
ABNT NBR 15606-2:2007
La variable 'canvas ' en un objeto de media asociado a la región “luaRegion” es conectada a un objeto canvas de
tamaño 300x100, asociada con la región (20,200).
Un canvas ofrece una API gráfica para ser usada por aplicaciones NCLua. A través de ella es posible dibujar
líneas, rectángulos, fuentes, imágenes etc.
Un canvas guarda en su estado atributos bajo los cuales operan las primitivas de dibujo, por ejemplo, si su
atributo de color es azul, una llamada a canvas:drawLine() dibuja una línea azul en el canvas.
Las coordenadas pasadas son siempre relativas al punto más a la izquierda y a la parte superior del canvas (0,0).
10.3.2.2
Constructores
A través de cualquier canvas es posible crear nuevos canvas y combinarlos a través de operaciones de
composición.
canvas:new (image_path: String) -> canvas: object
Argumentos
image_path
Camino de la imagen
Valor de retorno
canvas
Canvas representando la imagen
Descripción
Retorna un nuevo canvas cuyo contenido es la imagen recibida como parámetro.
El nuevo canvas debe obligatoriamente mantener los aspectos de transparencia de la imagen original.
canvas:new (width, height: Number) -> canvas: object
Argumentos
width
Ancho del canvas
height
Altura del canvas
Valores de retorno
canvas
Nuevo canvas
Descripción
Retorna un nuevo canvas con el tamaño recibido.
Inicialmente todos los pixels deben ser transparentes, obligatoriamente.
10.3.2.3
Atributos
Todos los métodos de atributos tienen el código attr y sirven tanto para leer como para alterar un atributo (con
algunas excepciones).
Cuando el método es llamado sin parámetros de entrada el valor corriente del atributo es retornado, en
contrapartida, cuando es llamado con parámetros, ésos deben ser los nuevos valores del atributo.
canvas:attrSize () -> width, height: number
Argumentos
116
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
Valores de retorno
width
Ancho del canvas
height
Altura del canvas
Descripción
Retorna las dimensiones del canvas.
Es importante observar que no se permite alterar las dimensiones de un canvas.
canvas:attrColor (R, G, B, A: Number)
Argumentos
R
Componente rojo del color
G
Componente verde del color
B
Componente azul del color
A
Componente Alpha del color
Descripción
Altera el color del canvas.
Los colores se pasan en RGBA, donde A varia de 0 (totalmente transparente) a 255 (totalmente opaco). Las
primitivas (ver 10.3.3.4) son dibujadas con el color de ese atributo del canvas.
El valor inicial es ‘0,0,0,255’ (negro).
canvas:attrColor (clr_name: string)
Argumentos
clr_name
Nombre del color
Altera el color del canvas.
Los colores pasan a través de una string correspondiendo a uno de los 16 colores NCL predefinidas: 'white',
'aqua', 'lime', 'yellow', 'red', 'fuchsia', 'purple', 'maroon',
'blue', 'navy', 'teal', 'green', 'olive', 'silver', 'gray', 'black'
Para valores en string, el Alpha es opaco (correspondiendo a “A = 255”).
Las primitivas (ver 10.3.3.4) son dibujadas con el color de ese atributo del canvas.
El valor inicial es 'black'.
© ABNT 2007 - Todos los derechos reservados
117
ABNT NBR 15606-2:2007
canvas:attrColor () -> R, G, B, A: number
Valores de retorno
R
Componente rojo del color
G
Componente verde del color
B
Componente azul del color
A
Componente alpha del color
Descripción
Retorna el color del canvas.
canvas:attrFont (face: string; size: number; style: string)
Argumentos
face
size
style
Nombre de la fuente
Tamaño de la fuente
Estilo de la fuente
Descripción
Altera la fuente del canvas.
Las siguientes fuentes deben estar disponibles obligatoriamente: 'Tiresias', 'Verdana'.
El tamaño es en pixels y representa la altura máxima de una línea escrita con la fuente elegida.
Los estilos posibles son: 'bold', 'italic' o 'bold-italic'. El valor nil presupone que ninguno de los estilos será usado.
Cualquier valor pasado no soportado debe obligatoriamente generar un error.
El valor inicial de la fuente es indeterminado.
canvas:attrFont () -> face: string; size: number; style: string
Valores de retorno
face
size
style
Descripción
Nombre de la fuente
Tamaño de la fuente
Estilo de la fuente
Retorna la fuente del canvas.
canvas:attrClip (x, y, width, height: Number)
Argumentos
x
118
Coordenada del área de clipping
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
y
Coordenada del área de clipping
width
Ancho del área de clipping
height
Descripción
Altura del área de clipping
Altera el área de clipping del canvas.
Las primitivas de dibujo (ver 10.3.3.4) y el método canvas:compose() solo operan dentro de esta región de
clipping.
El valor inicial es el canvas entero.
canvas:attrClip () -> x, y, width, height: number
Valores de retorno
x
Coordenada del área de clipping
y
Coordenada del área de clipping
width
Ancho del área de clipping
height
Altura del área de clipping
Descripción
Retorna el área de clipping del canvas.
canvas:attrCrop (x, y, w, h: number)
Argumentos
x
y
Coordenada de la región de crop
Coordenada de la región de crop
w
h
Descripción
Anchura de la región de crop
Altura de la región de crop
Altera la región de crop del canvas.
Solamente la región configurada pasa a ser usada en operaciones de composición.
El valor inicial es el canvas entero.
El canvas principal no puede tener su valor alterado pues es controlado por el formateador NCL.
canvas:attrCrop () -> x, y, w, h: number
Valores de retorno
x
y
w
h
Descripción
© ABNT 2007 - Todos los derechos reservados
Coordenada de la región de crop
Coordenada de la región de crop
Anchura de la región de crop
Altura de la región de crop
119
ABNT NBR 15606-2:2007
Retorna la región de crop del canvas.
canvas:attrFlip (horiz, vert: boolean)
Argumentos
horiz
Si el espejado es horizontal
vert
Si el espejado es vertical
Descripción
Configura el espejado del canvas usado en funciones de composición
El canvas principal no puede tener su valor alterado pues es controlado por el formateador NCL.
canvas:attrFlip () -> horiz, vert: boolean
Argumentos
horiz
Si el espejado es horizontal
vert
Si el espejado es vertical
Descripción
Retorna la configuración de espejado del canvas.
canvas:attrOpacity (opacity: number)
Argumento
opacity
Nuevo valor de opacidad del canvas
Descripción
Altera la opacidad del canvas.
El valor de la opacidad varía entre 0 (transparente) y 255 (opaco).
El canvas principal no puede tener su valor alterado pues es controlado por el formateador NCL.
canvas:attrOpacity () -> opacity: number
Valor de retorno
opacity
Opacidad del canvas
Descripción
Retorna el valor de la opacidad del canvas.
120
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
canvas:attrRotation (degrees: number)
Argumento
degrees
Rotación del canvas en grados
Descripción
Configura el atributo de rotación del canvas, que debe ser múltiplo de 90 grados.
El canvas principal no puede tener su valor alterado pues es controlado por el formateador NCL.
canvas:attrRotation () -> degrees: number
Valor de retorno
degrees
Rotación del canvas en grados
Descripción
Retorna el atributo de rotación del canvas.
canvas:attrScale (w, h: number)
Argumentos
w
Anchura de escalonamiento del canvas
h
Altura de escalonamiento del canvas
Descripción
Escalona el canvas con nueva anchura y altura.
Uno de los valores puede ser true, indicando que la proporción del canvas debe mantenerse.
El atributo de escalonamiento es independiente del atributo de tamaño, o sea, el tamaño del canvas se mantiene.
El canvas principal no puede tener su valor alterado pues es controlado por el formateador NCL.
canvas:attrScale () -> w, h: number
Valor de retorno
w
Anchura de escalonamiento del canvas
h
Altura de escalonamiento del canvas
Descripción
Retorna los valores de escalonamiento del canvas.
10.3.2.4
Primitivas
Todos los métodos siguientes tienen en cuenta los atributos del canvas.
canvas:drawLine (x1, y1, x2, y2: number)
Argumentos
x1
Extremidad 1 de la línea
© ABNT 2007 - Todos los derechos reservados
121
ABNT NBR 15606-2:2007
y1
Extremidad 1 de la línea
x2
y2
Descripción
Extremidad 2 de la línea
Extremidad 2 de la línea
Dibuja una línea con sus extremidades en (x1,y1) y (x2,y2).
canvas:drawRect (mode: string; x, y, width, height: Number)
Argumentos
mode
x
Modo de dibujo
Coordenada del rectángulo
y
Coordenada del rectángulo
width
Ancho del rectángulo
height
Altura del rectángulo
Descripción
Función para dibujo y rellenado de rectángulos.
El parámetro mode puede recibir 'frame' para dibujar apenas el marco del rectángulo o 'fill' para rellenarlo.
canvas:drawRoundRect (mode: string; x, y, width, height, arcWidth, arcHeight: number)
Argumentos
mode
x
Modo de dibujo
Coordenada del rectángulo
y
Coordenada del rectángulo
width
Anchura del rectángulo
height
Altura del rectángulo
arcWidth
Anchura del arco de la esquina redondeada
arcHeight
Altura del arco de la esquina redondeada
Descripción
Función para dibujo y rellenado de rectángulos redondeados.
El parámetro mode puede recibir 'frame' para dibujar apenas el contorno o 'fill' para rellenarlo.
canvas:drawPolygon (mode: string) -> drawer: function
Argumentos
mode
Valores de retorno
f
Descripción
122
Modo de dibujo
Función de dibujo
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
Método para dibujo y rellenado de polígonos.
El parámetro mode recibe el valor 'open', para dibujar el polígono sin conectar el último punto al primero; 'close',
para dibujar el polígono conectando el último punto al primero; o 'fill', para dibujar el polígono enlazando el último
punto al primero y colorear la región interior.
La función canvas:drawPolygon retorna una función anónima "drawer" con la firma:
function (x, y) end
La función retornada recibe las coordenadas del próximo vértice del polígono y retorna a sí mismo con resultado.
Ese procedimiento recurrente facilita la composición:
canvas:drawPolygon('fill')(1,1)(10,1)(10,10)(1,10)()
Al recibir nil la función "drawer" efectúa la operación encadenada. Cualquier llamada subsiguiente debe
obligatoriamente generar un error.
canvas:drawEllipse (mode: string; xc, yc, width, height, ang_start, ang_end: number)
Argumentos
mode
xc
Modo de dibujo
Centro de la elipsis
yc
Centro de la elipsis
width
Ancho de la elipsis
height
Altura de la elipsis
ang_start
Ángulo de inicio
ang_end
Ángulo de fin
Descripción
Dibuja elipsis y otras primitivas análogas tales como círculos, arcos y sectores.
El parámetro mode puede recibir 'arc' para dibujar apenas la circunferencia o 'fill' para rellenado interno.
canvas:drawText (x, y: number; text: string)
Argumentos
x
Coordenada del texto
y
Coordenada del texto
text
Texto a ser dibujado
Descripción
Dibuja el texto pasado en la posición (x,y) del canvas utilizando la fuente configurada en canvas:attrFont().
© ABNT 2007 - Todos los derechos reservados
123
ABNT NBR 15606-2:2007
10.3.2.5
Miscelánea
canvas:clear (x, y, w, h: number)
Argumentos
x
Coordenada del área de clear
y
Coordenada del área de clear
w
Anchura del área de clear
h
Altura del área de clear
Descripción
Limpia el canvas con el color configurado en attrColor.
Caso no sean pasados los parámetros del parea, se asume que se limpiará el canvas entero.
canvas:flush ()
Descripción
Actualiza el canvas después de operaciones de dibujo y composición.
Es suficiente llamarlo una sola vez después de una secuencia de operaciones.
canvas:compose (x, y: number; src: canvas; [ src_x, src_y, src_width, src_height: number ])
Argumentos
x
Posición de la composición
y
Posición de la composición
src
Canvas a ser compuesto
src_x
Posición de la composición en el canvas src
src_y
Posición de la composición en el canvas src
src_width
Ancho de la composición en el canvas src
src_height
Altura de la composición en el canvas src
Descripción
Hace sobre el canvas (canvas de destino), en su posición (x,y), la composición pixel a pixel con src (canvas de
origen).
Los otros parámetros son opcionales e indican qué parte del canvas src componer. Cuando ausentes, es
compuesto el canvas entero.
Esa operación llama la src:flush() automáticamente antes de la composición.
La composición satisface la ecuación:
Cd = Cs*As + Cd*(255 - As)/255
Ad = As*As + Ad*(255 - As)/255
124
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
donde:
Cd = color del canvas de destino (canvas)
Ad = alfa del canvas de destino (canvas)
Cs = color del canvas de origen (src)
As = alfa del canvas de origen (src)
Después de la operación el canvas de destino tiene el resultado de la composición y src no sufre ninguna
alteración.
canvas:pixel (x, y, R, G, B, A: number)
Argumentos
x
y
Posición del pixel
Posición del pixel
R
Componente rojo del color
G
Componente verde del color
B
Componente azul del color
A
Descripción
Componente alpha del color
Altera el color de un pixel del canvas.
canvas:pixel (x, y: number) -> R, G, B, A: number
Argumentos
x
y
Posición del pixel
Posición del pixel
Valores de retorno
R
Componente rojo del color
G
Componente verde del color
B
Componente azul del color
A
Descripción
Componente alpha del color
Retorna el color de un pixel del canvas.
canvas:measureText (text: string) -> dx, dy: number
Argumentos
text
Texto a ser medido
Valores de retorno
© ABNT 2007 - Todos los derechos reservados
125
ABNT NBR 15606-2:2007
dx
Anchura del texto
dy
Descripción
Altura del texto
Retorna las coordenadas limítrofes para el texto pasado, en el caso que el mismo fuese dibujado en la posición
(x,y) del canvas con la fuente configurada en canvas:attrFont().
10.3.3 Módulo event
10.3.3.1
Visión general
Este módulo ofrece una API para tratamiento de eventos. A través del mismo el formateador NCL y una aplicación
NCLua pueden comunicarse de manera asíncrona.
Una aplicación también puede disfrutar de ese mecanismo internamente, a través de eventos de la clase "user".
Probablemente el uso más común de aplicaciones NCLua será tratando eventos: ya sean éstos eventos NCL
(ver 7.2.8) o de interacción con el usuario (por el control remoto, por ejemplo).
Durante su iniciación, antes de volverse orientado a eventos, un script Lua debe obligatoriamente registrar una
función de tratamiento de eventos. Después de la iniciación, cualquier acción tomada por la aplicación es
solamente en respuesta a un evento enviado por el formateador NCL a la función "handler".
=== example.lua ===
...
-- código de iniciación
function handler (evt)
...
-- código tratador
end
event.register(handler) -- registro del tratador en el middleware
=== fin ===
Entre los tipos de eventos que pueden llegar al handler están todos los eventos generados por el formateador
NCL. Un script Lua también es capaz de generar eventos, llamados "espontáneos", con una llamada a la
función event.post(evt).
126
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
10.3.3.2
Funciones
event.post ([dst: string]; evt: event) -> sent: boolean; err_msg: string
Argumentos
dst
Destinatario del evento
evt
Evento a ser posteado
Valores de retorno
sent
Si el evento es enviado con éxito
err_msg
Descripción
Envía el evento pasado.
Mensaje de error en caso de fallo
El parámetro "dst" es el destinatario del evento y puede asumir los valores "in" (envío para la propia
aplicación) y "out" (envío para el formateador NCL). El valor default es ‘out’.
event.timer (time: number, f: function) -> cancel: function
Argumentos
time
Tiempo en milisegundos
f
Función de callback
Valor de retorno
unreg
Función para cancelar el timer
Descripción
Crea un timer que expira después de time (en milisegundos) y entonces llama la función F.
La firma de f es simple, sin recibimiento de parámetros:
function f () end
El valor de 0 milisegundos es válido. En ese caso, event.timer() debe, obligatoriamente, retornar
inmediatamente y f debe ser llamada de inmediato.
event.register ([pos: number]; f: function; [class: string]; […: any])
Argumentos
pos
Posición del registro (opcional)
f
Función de callback
class
Filtro de clase (opcional)
…
Filtro dependiente de la clase (opcional)
Descripción
Registra la función pasada como un listener de eventos, es decir, siempre que ocurra un evento, f será
llamada. La función f es, así, la función de tratamiento de eventos (function “handler”).
El parámetro pos es opcional e indica la posición en que f es registrada. Caso no sea pasada, la función es
registrada en último lugar.
El parámetro class también es opcional y cuando se pasa indica qué clase de eventos debe recibir la función. Si
© ABNT 2007 - Todos los derechos reservados
127
ABNT NBR 15606-2:2007
el pámetro se especifica, pueden definirse otros filtros dependientes de la clase. El valor nil en cualquier
posición indica que el parámetro no se debe filtrar.
La firma de f es:
function f (evt) end -> handled: boolean
Donde evt es el evento que, al ocurrir, activa la función.
La función puede retornar “true”, para señalizar que el evento fue tratado y, por lo tanto, no debe ser enviado a
otros tratadores.
Se recomienda que la función, definida por la aplicación, regrese rápidamente, ya que, mientras esté siendo
ejecutada, ningún otro evento será procesado.
El formateador NCL debe garantizar obligatoriamente que las funciones reciban los eventos en el orden en que
fueron registradas, y si ninguna de las mismas retorna el valor “true”, el formateador NCL debe notificar los otros
tratadores registrados.
event.unregister (f: function)
Argumentos
f
Función de callback
Descripción
Saca del registro la función pasada como un listener, es decir, nuevos eventos dejarán de ser pasados a f.
event.uptime () -> ms: number
Valores de retorno
ms
Tiempo en milisegundos
Descripción
Retorna el número de milisegundos transcurridos desde el inicio de la aplicación.
10.3.3.3
Clases de eventos
La función event.post() y el “handler” registrado en event.register() reciben eventos como parámetros.
Un evento se describe por una tabla Lua normal, donde el campo class es obligatorio e identifica la clase del
evento.
Son definidas las siguientes clases de eventos:
Classe key:
evt = { class='key', type: string, key: string}
* type puede ser 'press' o 'release'.
* key es el valor de la tecla en cuestión
EJEMPLO
NOTA
128
evt = { class='key', type='press', key=”0”}
En la clase key, el filtro dependiente de la clase puede ser type y key, en ese orden.
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
Classe ncl:
Las relaciones entre los nudos de media NCL se basan en eventos. Lua tiene acceso a esos eventos a través de
Classe ncl.
Los eventos pueden actuar en las dos direcciones, es decir, el formateador puede enviar eventos de acción para
alterar el estado del exhibidor Lua, y éste, a su vez, puede disparar eventos de transición para indicar cambios
de estado.
En los eventos, el campo type debe asumir obligatoriamente uno de los tres valores:
'presentation', 'selection' o 'attribution'
Los eventos pueden ser dirigidos a anclas específicas o al nudo como un todo, esto es identificado en el campo
area, que presupone el nudo entero, cuando ausente.
En el caso de un evento generado por el formateador, el campo action debe tener obligatoriamente uno de los
valores:
'start', 'stop', 'abort', 'pause', o 'resume'
Tipo ‘presentation’:
evt = { class='ncl', type='presentation', label='?', action='?' }
Tipo ‘attribution’:
evt = { class='ncl', type='attribution', name='?', action='?', value=’?’ }
Para eventos generados por el exhibidor Lua, el campo "action" debe obligatoriamente asumir uno de los
valores:
'start', 'stop', 'abort', 'pause', o 'resume'
Tipo ‘presentation’:
evt = { class='ncl', type='presentation', label='?', action='start'/'stop'/'abort'/'pause'/'resume' }
Tipo ‘selection’:
evt = { class='ncl', type='selection', label='?', action='stop' }
Tipo ‘attribution’:
evt = { class='ncl', type='attribution', name='?', action=’start’/'stop'/’abort’/’pause’/’resume’, value=’?’ }
NOTA
En la clase ncl, el filtro dependiente de la clase puede ser type, area y action, en ese orden.
Classe edit:
Esta clase espeja los comandos de edición para el Gerenciador de Bases Privadas (ver Sección 9). Sin embargo,
hay una diferencia entre los comandos de edición procedentes de los eventos de flujo DSM-CC y los comandos de
edición realizados por los scripts Lua (objetos NCLua). Los primeros alteran, no sólo la presentación de un
documento NCL, sino también la especificación de un documento NCL. O sea, al final del proceso es generado un
nuevo documento NCL, incorporando todos los resultados de la edición. Por otro lado, los comandos de edición
procedentes de los objetos de media NCLua alteran solamente la presentación del documento NCL. El documento
original es preservado durante todo el proceso de edición.
© ABNT 2007 - Todos los derechos reservados
129
ABNT NBR 15606-2:2007
Así como en las otras clases de evento, un comando de edición es representado por una tabla Lua. Todo evento
debe obligatoriamente cargar el campo command: un string con el nombre del comando de edición. Los otros
campos dependen del tipo de comando, conforme Tabla 56. La única diferencia es con relación al campo que define
los pares de referencia {uri, id} denominado data en la clase edit. El valor del campo acepta, no sólo los pares de
referencia {uri,id} mencionados en la Tabla 56, sino también strings XML con el contenido a ser adicionado.
EJEMPLO
evt = {
command = ‘addNode’,
composited = ‘someId’,
data = ‘<media>…’,
}
Los campos baseId y documentId (cuando son aplicables) son opcionales y asumen por default el identificador de la
base y del documento en el que NCLua está ejecutando.
El evento describiendo el comando de edición también puede recibir una referencia de tiempo como parámetro
opcional time. Este parámetro opcional se puede usar para especificar el momento exacto en que el comando de
edición debe ser ejecutado. Si este parámetro no se suministra en la llamada de función, el comando de edición
debe ser ejecutado inmediatamente. Cuando se suministra, el parámetro puede tener dos tipos de valores distintos,
con diferentes significados. Si es un valor numérico, define la cantidad de tiempo, en segundos, que la ejecución del
comando debe ser postergada. Sin embargo, ese parámetro también puede especificar el momento exacto para la
ejecución del comando, en valores absolutos. Para ello, el parámetro debe obligatoriamente ser una tabla con los
siguientes campos: year (cuatro dígitos), month (1 a 12), day (1 a 31), hour (0 a 23), minute (0 a 59), second (0 a 61)
e isdst (señalizador del horario de verano, un booleano)
Classe tcp:
El uso del canal de interactividad se realiza por medio de esta clase de eventos.
Para el envío o recibimiento de datos tcp, se debe establecer obligatoriamente una conexión inicialmente,
postando un evento en laforma:
Evt = {class=’tcp’, type=’connect’, host=addr, port=number, [timeout=number]}
El resultado de la conexión es retornado en un tratador d eventos pre-registrado para la clase. El evento retornado
tiene la siguiente forma:
Evt = { class=’tcp’, type=’connect’, host=addr, port=number, connection=identifier, error=<err_msg>}
Los campos error y connection son mutuamente exclusivos. Cuando hay un error de comunicación, debe ser
retornado un mensaje en el campo error. Cuando la comunicación es satisfactoria, el identificador de la conexión
es retornado en el campo connection.
Una aplicación NCLua envía datos por un canal de interactividad, enviando eventos en la forma:
evt = { class=’tcp’, type=’data’, connection=identifier, value=string, [timeout=number] }
De forma análoga, una aplicación NCLua recibe datos transportados por un canal de interactividad haciendo uso
de eventos en la forma:
evt = { class=’tcp’, type=’data’, connection=identifier, value=string, error=msg }
Los campos error y value son mutuamente exclusivos. Cuando hay un error de comunicación, es enviado un
mensaje por el campo error. Cuando la comunicación tiene éxito, el mensaje transportado es pasado por el campo
value.
Para cerrar una conexión, se debe postar obligatoriamente el siguiente evento:
130
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
evt = { class=’tcp’, type=’disconnect’, connection=identifier }
NOTA 1 Se recomienda que cuestiones tales como autenticación, sean tratadas en una implementación específica del
middleware.
NOTA 2 En la clase tcp, el filtro dependiente de la clase sólo puede ser connection.
Classe sms:
El compartimento de envío y recibimiento por medio de SMS es muy semejante al definido en la clase tcp.
También como esa clase, la clase sms es opcional en el caso de la implementación Ginga para receptores fullseg.
Una aplicación NCLua envía datos por SMS, enviando eventos en la forma:
evt = { class=’sms’, to=’phone number’, value=string }
De forma análoga, una aplicación NCLua recibe datos transportados por SMS utilizando eventos en la forma:
evt = { class=’sms’, from=’phone number’, value=string }
Se recomienda que cuestiones como autenticación etc., se traten en una implementación específica del
NOTA 1
middleware.
NOTA 2
En la clase sms, el filtro dependiente de la clase sólo puede ser from.
Clase si:
La clase de eventos ‘si’ permite el acceso a un conjunto de informaciones multiplexadas en un flujo de transporte y
transmitidas periódicamente por difusión.
El proceso de adquisición de las informaciones debe ser obligatoriamente realizado en dos pasos:
1) una requisición realizada por una llamada al event.post(), que no bloquea la ejecución del script;
2) un evento, posteriormente repasado a los tratadores de eventos registrados del script NCLua, cuyo campo
data contiene un conjunto de subcampos que depende del tipo de información exigida, y que es
representado por una tabla lua.
NOTA
En la clase si, el filtro dependiente de la clase sólo puede ser type.
Son definidos cuatro tipos de eventos por los siguientes tipos de tablas:
type = ‘services’
La tabla del tipo ‘services’ consiste en un conjunto de vectores. Cada vector posee informaciones relativas a un
servicio multiplexado del flujo de transporte sintonizado.
Cada requisición para una tabla del tipo de evento ‘services’ debe ser obligatoriamente realizada a través de la
siguiente llamada:
event.post('out', { class='si', type='services'[, index=N][, fields={field_1, field_2,…, field_j}]}),
donde:
a) el campo index, si es especificado, indica el índice delo servicio; en caso de que no sea especificado, todos los
servicios deben ser obligatoriamente retornados;
b) el campo fields puede tener como valor cualquier subconjunto de los subcampos definidos para la tabla
retornada en el campo data del evento de respuesta (así, field_i representa uno de los subcampos de la tabla
data). En caso de que el campo fields no sea especificado, todos los subcampos de la tabla retornada en el campo
© ABNT 2007 - Todos los derechos reservados
131
ABNT NBR 15606-2:2007
data deben ser obligatoriamente rellenados.
El evento de respuesta es generado después de que todas las informaciones exigidas hayan sido procesadas por
el middleware (informaciones no transmitidas por difusión dentro de un intervalo máximo de tiempo especificado en
la ABNT NBR 15603-2:2007, Tabla 6, del estándar son retornadas como nulas). La tabla del campo data es
retornada en el evento, como sigue:
evt = {
class = 'si',
type = 'services',
data = {
[i] = { -- cada servicio está en una posición
id
= <number>,
isAvailable
= <boolean>,
isPartialReception
= <boolean>,
parentalControlRating
= <number>,
runningStatus
= <number>,
serviceType
= <number>,
providerName
= <string>,
serviceName
= <string>,
stream = {
[j] = {
pid = <number>,
componentTag = <number>,
type = <number>,
regionSpecType = <number>,
regionSpec
= <string>,
}
}
}
}
Para la obtención de las respuestas a envíos de eventos del tipo ‘services’, se recomienda que los subcampos de
la tabla data se calculen con base en tablas SI y descriptores asociados al servicio [i].
Se recomienda que los valores de los subcampos id y runningStatus de la tabla data se computen conforme los
valores de los campos service_id y running_status, respectivamente, de la tabla SDT (ver ABNT NBR 156032:2007, Tabla 13, que describe el servicio [i].
Se recomienda que sea establecida la misma relación entre los subcampos providerName y serviceName de la
tabla data y los campos service_name y service_provider_name, respectivamente, del descriptor
service_descriptor (conforme la ABNT NBR 15603-2:2007).
Se recomienda que el subcampo parentalControlRating de la tabla data se calcule con el valor del campo rating del
descriptor parentalControlRating, en el cual el campo country_code presente el mismo país referente al valor de la
variable de ambiente (nudo Settings) user.location.
Se recomienda que el subcampo isAvailable de la tabla data se calcule basado en el valor del campo country_code
(con el grupo de países disponibles) del descriptor country_availability_descriptor (ver ABNT NBR 15603-2:2007,
Subsección 8.3.6) relativo al servicio [i]. El valor “true” es atribuido solamente si el campo country_code contiene el
132
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
mismo país referente al valor de la variable de ambiente (nudo Settings) user.location.
Se recomienda que el subcampo isPartualReception de la tabla data se calcule con base en el valor del campo
service_id del descriptor partial_reception_descriptor (ver ABNT NBR 15603-2:2007, Subsección 8.3.32).
Se recomienda que la semántica del subcampo serviceType de la tabla data sea definida por la ABNT NBR 156032:2007, Tabla H.2.
Se recomienda que la semántica del subcampo runningStatus sea definida de acuerdo con la ABNT NBR 156032:2007, Tabla 14.
Se recomienda que el subcampo pid de la tabla stream tenga el valor del campo pid del encabezado del paquete
del flujo elemental [i] (conforme ISO/IEC 13818-1).
Se recomienda que el valor del subcampo componentTag de la tabla stream se obtenga a través del campo
component_tag del descriptor stream_identifier_descriptor (ver ABNT NBR 15603-2:2007, Subsección 8.3.16)
relacionado al flujo elemental [i].
Se recomienda que el subcampo type de la tabla stream tenga la semántica definida en la Tabla 2-34 de la
ISO/IEC 13818-1: 2008, relacionada al flujo elemental [i].
Se recomienda que el subcampo regionSpecType de la tabla stream defina el método de codificación del campo
regionSpec de la misma tabla, conforme la semántica definida en la ABNT NBR 15603-2:2007, Tabla 53.
Se recomienda que el campo regionSpec de la tabla stream defina la región para la cual es designado el flujo
elemental [i].
Se recomienda también que los campos regionSpec y regionSpecType se obtengan a través del descriptor
target_region_descriptor especificado en la ABNT NBR 15603-2:2007.
type = ‘mosaic’
La tabla del tipo ‘mosaic’ consiste en un subconjunto de informaciones para el mosaico que se suministra como
una matriz. La tabla es, sin embargo, opcional.
Cuando se suministra la tabla del tipo ‘mosaic’, la requisición de la tabla debe ser obligatoriamente realizada a
través de la siguiente llamada:
event.post('out', { class='si', type='mosaic'[, fields={field_1, field_2,…, field_j}]}),
donde el campo fields del evento de requisición puede tener como valor cualquier subconjunto de los subcampos
definidos para la tabla retornada en el campo data del evento de respuesta (así, field_i representa uno de los
subcampos de la tabla data, como se especifica a continuación). En el caso de que el campo fields no se
especifique, todos los subcampos de la tabla retornada en el campo data deben ser obligatoriamente rellenados.
El evento de respuesta es generado después de que todas las informaciones exigidas sean procesadas por el
middleware (informaciones no transmitidas por difusión dentro de un intervalo máximo de tiempo especificado en la
ABNT NBR 15603-2:2007, Tabla 6 del estándar, son retornadas como nulas). La tabla del campo data es
retornada en el evento, como sigue:
evt = {
class = 'si',
type = 'mosaic',
data = {
[i] = {
[j] = {
logicalId
= <number>,
© ABNT 2007 - Todos los derechos reservados
133
ABNT NBR 15606-2:2007
presentationInfo = <number>,
id
= <number>,
linkageInfo
= <number>,
bouquetId
= <number>,
networkId
= <number>,
tsId
= <number>,
serviceId
= <number>,
eventId
= <number>,
}
}
}
}
NOTA
Para la obtención de respuestas a envíos de eventos del tipo ‘mosaic’, se recomienda que los subcampos de la tabla
data sean calculados con base en tablas SI y descriptores asociados al mosaico. Se recomienda que los valores máximos de [i]
y [j], así como los valores de los subcampos logicalId, presentationInfo, id, linkageInfo, bouquetId, networkId, tsId, serviceId y
eventId de la tabla data se obtengan a través de los campos number_of_horizontal_elementary_cells,
number_of_vertical_elementary_cells, logical_cell_id, logical_cell_presentation_info, id, cell_linkage_info, bouquet_id,
original_network_id, transport_stream_id, service_id y event_id del descriptor mosaic_descriptor (especificado en la ABNT NBR
15603-2:2007, Subsección 8.3.9), respectivamente.
type = ‘epg’
La tabla del tipo ‘epg’ consiste en un conjunto de vectores. Cada vector posee informaciones relativas a un evento
del contenido transmitido.
Una requisición de la tabla del tipo ‘epg’ debe ser obligatoriamente realizada a través de una de las posibles
llamadas a seguir:
1) event.post('out', { class='si', type='epg', stage=’current’[, fields={field_1, field_2,…, field_j}]})
donde el campo fields del evento de requisición puede tener como valor cualquier subconjunto de los
subcampos definidos para la tabla retornada en el campo data del evento de respuesta (así, field_i representa
uno de los subcampos de la tabla data, como se especifica a continuación). En caso que el campo fields no se
especifique, todos los subcampos de la tabla retornada en el campo data deben ser obligatoriamente
rellenados.
Descripción: obtiene las informaciones del evento corriente de la programación.
2) event.post('out', {class='si', type='epg', stage='next'[, eventId=<number>][, fields={field_1,
field_2,…, field_j}]})
Donde:
a) el campo eventId, cuando es especificado, identifica el evento inmediatamente anterior al evento del que se
quieren las informaciones. Cuando no se especifica indica que las informaciones deseadas son las del evento
siguiente al evento corriente de la programación;
b) el campo fields del evento de requisición puede tener como valor cualquier subconjunto de los subcampos
definidos para la tabla retornada en el campo data del evento de respuesta (así, field_i representa uno de los
subcampos de la tabla data, como se especifica a continuación). En caso que el campo fields no se
especifique, todos los subcampos de la tabla retornada en el campo data deben ser obligatoriamente
rellenados.
Descripción: obtiene las informaciones del evento siguiente al evento identificado en eventId o, en el caso de
que eventId no se especifique, del evento siguiente al evento corriente de la programación.
3) event.post('out', {class='si', type='epg', stage=’schedule’, startTime=<date>, endTime=<date>[,
134
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
fields={field_1, field_2,…, field_j}]})
donde el campo fields del evento de requisición puede tener como valor cualquier subconjunto de los
subcampos definidos para la tabla retornada en el campo data del evento de respuesta (así, field_i representa
uno de los subcampos de la tabla data, como se especifica a continuación). En caso que el campo fields no se
especifique, todos los subcampos de la tabla retornada en el campo data deben ser obligatoriamente
rellenados.
Descripción: obtiene las informaciones de los eventos comprendidos en la banda de tiempo pasada en los
campos startTime y endTime que tienen como valor tablas en formato de <date>.
El evento de respuesta es generado después que todas las informaciones exigidas sean procesadas por el
middleware (informaciones no transmitidas por difusión dentro de un intervalo máximo de tiempo especificado en la
ABNT NBR 15603-2:2007, Tabla 6, del estándar son retornadas como nulas). La tabla del campo data es
retornada en el evento, como sigue:
evt = {
class = 'si',
type = 'epg',
data = {
[i] – {
startTime
= <date>,
endTime
= <date>,
runningStatus
= <number>,
name
= <string>,
originalNetworkId
= <number>,
shortDescription
= <string>,
extendedDescription
= <string>,
copyrightId
= <number>,
copyrightInfo
= <string>,
parentalRating
= <number>,
parentalRatingDescription = <string>,
audioLanguageCode
= <string>,
audioLanguageCode2
= <string>,
dataContentLanguageCode = <string>,
dataContentText
= <string>,
hasInteractivity
= <boolean>,
logoURI
= <string>,
contentDescription
={
[1] = <content_nibble_1>,
[2] = <content_nibble_2>,
[3] = <user_nibble_1>,
[4] = <user_nibble_2> }
},
linkage = {
tsId
= <number>,
networkId = <number>,
serviceId = <number>,
type
= <number>, (table 30, norma 3 vol 2)
data
= <string>,
© ABNT 2007 - Todos los derechos reservados
135
ABNT NBR 15606-2:2007
},
hyperlink = {
type
= <number>,
destinationType = <number>,
tsId
= <number>,
networkId
= <number>,
eventId
= <number>,
componentTag = <number>,
moduleId
= <number>,
serviceId
= <number>,
contentId
= <number>,
url
= <string>,
},
series = {
id
= <number>,
repeatLabel
= <number>,
programPattern = <number>,
episodeNumber = <number>,
lastEpisodeNumber = <number>,
name = <string>,
},
eventGroup = {
type = <number>,
[j] = {
id
= <number>,
tsId
= <number>,
networkId = <number>,
serviceId = <number>,
}
},
componentGroup = {
type = <number>,
[j] = {
id
= <number>,
totalBitRate = <number>,
description = <string>,
caUnit = {
id
= <number>, -- (table 80, norma 3 vol 2)
component = {
[k] = tag (<number>)
}
},
}
}
}
}
136
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
}
Para la obtención de las respuestas a envíos de eventos del tipo ‘epg’, se recomienda que los campos de la tabla
data sean calculados con base en tablas SI y descriptores asociados al evento [i].
Se recomienda que los valores de los campos startTime, endTime, runningStatus y originalNetworkId de la tabla
data se obtengan a través de los campos start_time, (duration + start_time), running_status y original_network_id
de la tabla SI event_information_section (conforme especificado en la ABNT NBR 15603-2:2007, Tabla 15),
respectivamente.
Se recomienda que los valores de los campos name y shortDescription se obtengan a través de los campos
event_name_char y text_char del descriptor short_event_descriptor (conforme especificado en
la ABNT NBR 15603-2:2007, Subsección 8.3.15), respectivamente.
Se recomienda que el valor del campo extendedDescription sea obtenido a través del campo text_char del
descriptor extended_event_descriptor (conforme especificado en la ABNT NBR 15603-2:2007, Subsección 8.3.7).
Se recomienda que los valores de los campos copyrightId y copyrightInfo se obtengan a través de los campos
copyright_identifier y additional_copyright_info del descriptor copyright_descriptor (conforme la la ISO/IEC 138181:2008, Tabla 2-63), respectivamente.
El campo parentalRating de la tabla data tiene la semántica definida en la ABNT NBR 15603-2:2007, Tabla 32, y
se recomienda que su valor sea calculado con base en el campo country_code del descriptor
parental_rating_descriptor y en la variable de ambiente (Settings node) user.location.
El campo parentalRatingDescription de la tabla data tiene la semántica definida en la ABNT NBR 15603-2:2007,
Tabla 33, y se recomienda que su valor se calcule con base en el campo country_code del descriptor
parental_rating_descriptor y en la variable de ambiente (Settings node) user.location.
Se recomienda que los valores de los campos audioLanguageCode y audioLanguageCode2 se obtengan a través
de los campos ISO_639_language_code e ISO_639_language_code2 del descriptor audio_component_descriptor
(conforme ABNT NBR 15603-2:2007, Tabla 48), respectivamente.
Se recomienda que los valores de los campos dataContentLanguageCode y dataContextText se obtengan a través
de los campos ISO_639_language_code y text_char del descriptor data_content_descriptor (conforme ABNT NBR
15603-2:2007, Tabla 54), respectivamente.
El campo hasInteractivity de la tabla data debe tener obligatoriamente el valor true cuando el evento [i] tenga una
aplicación interactiva disponible.
Se recomienda que el valor del campo logoURI de la tabla data posea la localización del logotipo, transmitido por
una tabla CDT (conforme ABNT NBR 15603-2:2007, Subsección 8.3.44).
Se recomienda que los valores de los campos de la tabla contentDescription sean obtenidos a través de los
campos de igual nombre del descriptor content_descriptor (conforme ABNT NBR 15603-2:2007, Subsección 8.3.5).
Se recomienda que los valores de los campos tsId, networkId, serviceId, type y data de la tabla linkage se
obtengan a través de los campos transport_stream_id, original_network_id, original_service_id, description_type y
user_defined del descriptor linkage_descriptor (conforme ABNT NBR 15603-2:2007, Subsección 8.3.40),
respectivamente.
Se recomienda que los valores de los campos type, destinationType, tsId, networkId, eventId, componentTag,
moduleId, contentId y url de la tabla hyperlink se obtengan a través de los campos hyper_linkage_type,
link_destination_type, transport_stream_id, original_network_id, event_id, component_tag, moduleId, content_id y
url_char del descriptor hyperlink_descriptor (conforme ABNT NBR 15603-2:2007, Subsección 8.3.29),
respectivamente.
© ABNT 2007 - Todos los derechos reservados
137
ABNT NBR 15606-2:2007
Se recomienda que los valores de los campos id, repeatLabel, programPattern, episodeNumber,
lastEpisodeNumber y name de la tabla series se obtengan a través de los campos series_id, repeat_label,
program_pattern, episode_number, last_episode_number y series_name_char del descriptor series_descriptor
(conforme ABNT NBR 15603-2:2007, Subsección 8.3.33), respectivamente.
Se recomienda que los valores de los campos type, id, tsId, networkId y serviceId de la tabla eventGroup se
obtengan a través de los campos group_type, event_id, transport_stream_id, original_network_id y service_id del
descriptor event_group_descriptor (conforme ABNT NBR 15603-2:2007, Subsección 8.3.34), respectivamente.
Se recomienda que los valores de los campos type, id, totalBitRate, description, caUnit.id, caUnit.component[k].tag,
tsId, networkId y serviceId de la tabla componentGroup se obtengan a través de los campos
component_group_type, component_group_id, total_bit_rate, text_char, CA_unit_id y component_tag del descriptor
component_group_descriptor (conforme ABNT NBR 15603-2:2007, Subsección 8.3.37), respectivamente.
type=’time’
La tabla del tipo ‘time’ consiste en informaciones sobre la fecha y hora corriente basadas en la UTC, pero en el
horario oficial del país en que se encuentra el receptor.
La requisición de la tabla debe realizarse obligatoriamente a través de la siguiente llamada:
event.post('out', { class='si', type=’time’}),
El evento de respuesta es generado después que la información sobre fecha y hora corriente exigida sea
procesada por el middleware (las informaciones no transmitidas por difusión dentro de un intervalo máximo de
tiempo especificado en la ABNT NBR 15603-2:2007, Tabla 6 del estándar, son retornadas como nulas). La tabla
del campo data es retornada en el evento, como sigue:
evt = {
class = 'si',
type = 'time',
data = {
year
= <number>,
month
= <number>,
day
= <number>,
hours
= <number>,
minutes
= <number>,
seconds
= <number>
}
NOTA
Para la obtención de las respuestas a envíos de eventos del tipo ‘time’, se recomienda que los campos de la tabla
data se calculen con base en la tabla TOT y en el descriptor local_time_offset_descriptor (conforme ABNT NBR 15603-2:2007,
Subsección 7.2.9).
138
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
Classe user:
Utilizando Clase user, las aplicaciones pueden extender sus funcionalidades, creando sus propios eventos. En esa
clase, ningún campo está definido (aparte, del campo class).
NOTA
En la clase user, el filtro dependiente de la clase puede ser type, si se establece el filtro.
10.3.4 Módulo settings
Exporta la tabla settings con variables definidas por el autor del documento NCL y variables de ambiente
reservadas, contenidas en el nudo application/x-ginga-settings.
No se permite atribuir valores a los campos representando variables en los nudos settings. Un error debe ser
generado en el caso que ocurra un intento de atribución. Las propiedades de un nudo settings solo pueden ser
modificadas por medio de eslabones NCL.
La tabla settings particiona sus grupos en varias subtablas, correspondiendo a cada grupo del nudo application/xginga-settings. Por ejemplo, en un objeto NCLua, la variable del nudo settings “system.CPU” es referida como
settings.system.CPU.
Ejemplos de uso:
lang = settings.system.language
age = settings.user.age
val = settings.default.selBorderColor
settings.service.myVar = 10
settings.user.age = 18 --> ERRO!
10.3.5 Módulo persistent
Aplicaciones NCLua pueden grabar datos en un área restringida del middleware y recuperarlos entre ejecuciones.
El exhibidor Lua permite a una aplicación NCLua persistir un valor para ser posteriormente usado por la misma o
por otro objeto de procedimiento. Para ello, el exhibidor define un área reservada, inaccesible a objetos NCL que
no sean de procedimiento. Este área se divide entre los grupos “service”, “channel” y “shared”, con la misma
semántica de los grupos homónimos del nudo NCL settings. No existe ninguna variable predefinida o reservada
en esos grupos, y objetos de procedimiento pueden atribuir valores a esas variables directamente. Se recomienda
que otros lenguajes de procedimiento, Java en particular para los objetos NCLets (<media> elements of type
application/x-ginga-NCLet), ofrezcan una API dando acceso al mismo área.
En éste modulo persistent, Lua ofrece una API para exportar la tabla persistent con las variables definidas en el
área reservada.
El uso de la tabla persistent es semejante al uso de la tabla settings excepto por el hecho de que, en este caso, el
código de procedimiento puede alterar los valores de los campos.
Ejemplos de uso:
persistent.service.total = 10
color = persistent.shared.color
© ABNT 2007 - Todos los derechos reservados
139
ABNT NBR 15606-2:2007
10.4 Lua-API para Ginga-J
10.4.1 Mapeo
Dependiendo de la configuración del middleware, es posible tener acceso en Lua a la misma API suministrada por
el Ginga-J, a fin de tener acceso a algunos recursos del decodificador y facilidades del Ginga. La API para GingaJ suministrada en Lua es opcional, pero cuando es ofrecida debe seguir obligatoriamente la misma especificación
definida para el Ginga-J.
10.4.2 Paquetes
Las jerarquías de los paquetes Java que componen la API del Ginga-J se mapean para jerarquías equivalentes
de los paquetes Lua que tienen un paquete raíz en común, llamado ginga. Más específicamente, un paquete "x"
en la API del Ginga-J se mapea para un paquete Lua ginga.x equivalente. En ese contexto, un paquete Lua
equivalente significa un paquete que contenga clases y subpaquetes equivalentes a los definidos en el paquete
Java.
El conjunto de paquetes Ginga-J que estarán disponibles en el ambiente de ejecución de un script Lua puede ser
restringido por políticas de seguridad. Si un paquete “x” de la API del Ginga-J está disponible en el ambiente Lua,
ginga.x mantendrá una referencia para una tabla Lua con todas las definiciones relacionadas a "x" (clases y
subpaquetes). En caso contrario, ginga.x es una referencia nil. Algunos ejemplos de mapeos de nombre de los
paquetes del Ginga-J para paquetes Lua se presentan en la Tabla 58.
Tabla 58 – Ejemplos de mapeos de nombre entre
los paquetes Ginga-J y paquetes Lua
Paquete Ginga-J
org.sbtvd.net.tuning
org.sbtvd.media
javax.media
org.dvb
org.havi
org.davic
Paquete Lua
ginga.org.sbtvd.net.tuning
ginga.org.sbtvd.media
ginga.javax.media
ginga.org.dvb
ginga.org.havi
ginga.org.davic
10.4.3 Tipos básicos
Los tipos de datos básicos del Java, que se utilizan en la API Ginga-J, se mapean para los tipos de datos básicos
de Lua. Esos mapeos se presentan en la Tabla 59. Además de los tipos primitivos de Java, la tabla también
especifica el mapeo de strings y matrices.
Tabla 59 — Mapeo de tipos de datos básicos
Tipo Java
140
Tipo Lua
Short
number
Int
number
Long
number
Float
number
Double
number
Byte
number
Char
string (with only one character)
Boolean
boolean
Array objects
table
String objects
string
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
10.4.4 Clases
Toda clase Java da API Ginga-J es representada en Lua como una tabla, definida en su respectivo paquete. Por
ejemplo, la clase
org.sbtvd.net.tuning. ChannelManager
se representa en Lua como una entrada ChannelManager en el paquete ginga.org.sbtvd.net.tuning, es decir, esa
clase es accedida a través de
ginga.org.sbtvd.net.tuning.ChannelManager.
Todos los miembros estáticos de una clase Java se mapean para campos de la tabla Lua equivalente. Cada clase
representada en Lua también tiene una operación newInstance, que desempeña el papel de un constructor.
10.4.5 Objetos
Siempre que el método newInstance suministrado por una clase representada en Lua se llama, retorna una nueva
instancia (objeto) de esa clase. El objeto retornado es una tabla Lua que tiene todos los miembros de instancia
especificados por su clase (campos y métodos públicos).
10.4.6 Objetos de callback (observadores)
Muchos métodos definidos en la API Ginga-J esperan recibir un objeto observador (listener) como parámetro.
Esos objetos observadores pueden ser implementados en Lua como tablas que tienen todos los métodos
especificados en la interfaz del observador.
10.4.7 Excepciones
Las excepciones del Java también se mapean para tablas Lua, siguiendo las mismas reglas para mapear objetos
del Java para Lua. Para generar una excepción, se recomienda que un objeto observador implementado en Lua
use la función error suministrada por Lua (ver Anexo B). Para capturar una excepción generada por un método de
la API, se recomienda que el script Lua use la función pcall (ver Anexo B).
11 Puente
11.1 Revisión
El puente de doble mano entre el Ginga-NCL y el Ginga-J se realiza:
 en un sentido, a través de las relaciones del NCL, definidos en los elementos <link> que se refieren a los
elementos <media> que representan los códigos Xlet (tipo application/x-ginga-NCLet) soportados por el
Ginga-J; y a través de los scripts Lua (elementos <media> del tipo application/x-ginga-NCLua) que hacen
referencia a los métodos del Ginga-J;
 en el camino inverso, a través de las funciones del Ginga-J que pueden monitorear cualquier evento NCL y
también pueden comandar alteraciones en elementos y propiedades NCL, a través de relaciones definidas en
elementos <link> o a través de comandos de edición del NCL.
© ABNT 2007 - Todos los derechos reservados
141
ABNT NBR 15606-2:2007
11.2 Puente a través de los elementos NCL <link> y <media>
El Ginga-NCL puede actuar sobre el Ginga-J a través de elementos <link> y a través de elementos <media> del
tipo application/x-ginga-NCLet.
De modo análogo al contenido de media convencional, el NCL permite que el código Xlet sea sincronizado con
otros objetos NCL (de procedimiento o no). Los autores del NCL pueden definir eslabones NCL para iniciar, parar,
pausar, retomar o abortar la ejecución de un código de procedimiento Xlet (representado por un elemento
<media> del tipo application/x-ginga-NCLet) como hacen para contenidos de presentación usual (ver 8.5). Un
player (exhibidor) NCLet (basado en la máquina Java) debe obligatoriamente hacer la interfaz del ambiente de
ejecución de procedimiento con el formateador NCL (ver 8.5).
Un elemento <media> conteniendo un código Java puede definir anclas (a través de elementos <area> y atributos
(a través de elementos <property>). El player debe obligatoriamente controlar la máquina de estado de los
eventos asociados con esos elementos de interfaz.
El código Xlet puede ser asociado a elementos <area>. Si los eslabones externos inician, paran, pausan o
retoman la presentación del ancla, las callBacks en el código Xlet deben ser obligatoriamente disparadas. Por otro
lado, el código Xlet puede comandar el inicio, parada, pausa, reinicio o aborto de esas anclas a través de una API
ofrecida por el lenguaje de procedimiento. Las transiciones causadas por esos comandos se pueden usar como
condiciones de los eslabones NCL para disparar acciones en otros objetos NCL del mismo documento. Así, una
sincronización de dos vías puede ser establecida entre el código Xlet y el resto del documento NCL.
Un elemento <property> definido como hijo del elemento <media> del tipo application/x-ginga-NCLet puede ser
mapeado para un método del código Xlet o para un atributo del código Xlet. Cuando es mapeado para un método
del código, una acción “set” del eslabón aplicada al atributo debe obligatoriamente causar la ejecución del método,
con los valores definidos por la acción del eslabón siendo interpretados como parámetros de entrada del método.
El atributo name del elemento <property> se debe usar obligatoriamente para identificar el método del código
procedural. Cuando el elemento <property> es mapeado para un atributo del código Xlet, la acción “set” debe
obligatoriamente atribuir un valor al atributo.
El elemento <property> puede también ser asociado a un assessment role de un eslabón NCL. En ese caso, el
formateador NCL debe obligatoriamente consultar el valor del atributo, a fin de evaluar la expresión del eslabón.
Si el elemento <property> es mapeado para un atributo del código, el valor del atributo debe ser retornado
obligatoriamente por el player Xlet para el formateador NCL. Si el elemento <property> es mapeado para un
método del código, el método debe ser obligatoriamente llamado y su valor debe ser retornado obligatoriamente
por el player Xlet para el formateador NCL.
11.3 Puente a través de las funciones Lua y métodos del Ginga-J
Dependiendo de la configuración del middleware, es posible tener acceso en Lua a la misma API suministrada
por el Ginga-J, a fin de tener acceso a algunos recursos del decodificador y facilidades del Ginga. La API
suministrada en Lua debe seguir obligatoriamente la misma especificación presentada para el Ginga-J.
El Ginga-J también ofrece una API que permite que el código Xlet consulte cualquier valor de propiedad
predefinido o dinámico del nudo de configuraciones del NCL (elemento <media> del tipo "application/x-gingasettings”).
Además, el Ginga-J ofrece API que suministran un conjunto de métodos para dar soporte a los comandos de
edición del NCL y comandos del Gestor de la Base Privada.
142
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
12 Requisitos de codificación de media y métodos de transmisión referidos en
documentos NCL
12.1 Uso del canal de interactividad
Un formateador NCL debe obligatoriamente ignorar con éxito cualquier método de codificación o transmisión que
no sea soportado por el navegador. Con el objeto de adquirir contenido de datos que sea referido por los
elementos <media> a través de un protocolo de canal interactivo específico, los mecanismos especificados para
el canal de interactividad del SBTVD se deben utilizar obligatoriamente.
12.2 Métodos de codificación y transmisión de video – Datos de video referidos en elementos
<media>
12.2.1 Transmisión de video MPEG-1
12.2.1.1
Transmisión como flujo elemental de video
Para transmitir contenido de video MPEG-1 como un flujo elemental de video, los datos del video se deben
transmitir obligatoriamente como MPEG-2 packetized elementary stream (video PES), con el tipo de flujo
especificado de conformidad con la atribución de tipos de flujos ISO/IEC 13818-1 (valor 0x01 para video ISO/IEC
11172-2).
12.2.1.2
Transmisión en secciones MPEG-2
Para transmitir datos de video MPEG-1 por medio de secciones MPEG-2 específicas (ver atribución de tipos de
flujos para secciones MPEG-2 en ISO/IEC 13818-1), uno de los siguientes métodos de transmisión se debe usar
obligatoriamente:
a)
como un archivo de flujo multiplexado en sistemas MPEG-1 (de acuerdo con la ISO/IEC 11172-1);
b)
como un archivo de flujo elemental de video MPEG-1;
c)
como un archivo de flujo multiplexado en el formato TS especificado en 12.4.
12.2.2 Transmisión de video MPEG-2
12.2.2.1
Transmisión como flujo elemental de video
Para transmitir contenido de video MPEG-2 como un flujo elemental de video, los datos del video se deben
transmitir obligatoriamente como MPEG-2 packetized elementary stream (video PES), con el tipo de flujo
especificado de acuerdo con la atribución de tipos de flujos de acuerdo con ISO/IEC 13818-1 (valor 0x02 para
video de acuerdo con ISO/IEC 13818-2).
12.2.2.2
Transmisión en secciones MPEG-2
Para transmitir datos de video MPEG-2 por medio de secciones MPEG-2 específicas (ver atribución de tipos de
flujospara secciones MPEG-2 en ISO/IEC 13818-1), uno de los métodos de transmisión siguientes se debe usar
obligatoriamente:
a)
Como un archivo de flujo elemental de video MPEG-2;
b)
Como un archivo de flujo multiplexado en el formato TS especificado en 12.4.
© ABNT 2007 - Todos los derechos reservados
143
ABNT NBR 15606-2:2007
12.2.3 Transmisión de video MPEG-4 y H.264|MPEG-4 AVC
12.2.3.1
Transmisión como flujo elemental de video
Para transmitir contenido de video MPEG-4 como un flujo elemental de video, los datos del video se deben
transmitir obligatoriamente como MPEG-2 packetized elementary stream (video PES), con el tipo de flujo
especificado de acuerdo con la atribución de tipos de flujos ISO/IEC 13818-1 (valor 0x10 para video de acuerdo
con H.264|MPEG-4 AVC).
12.2.3.2
Transmisión en secciones MPEG-2
Para transmitir datos de video MPEG-4 ó H.264|MPEG-4 AVC por medio de secciones MPEG-2 específicas
(ver atribución de tipos de flujos para secciones MPEG-2 en ISO/IEC 13818-1), uno de los métodos de
transmisión siguientes se debe usar obligatoriamente:
a)
Como un archivo de flujo elemental de video MPEG-4 (o H.264|MPEG-4 AVC);
b)
Como un archivo de flujo multiplexado en el formato TS especificado en 12.4.
12.3 Métodos de codificación y transmisión de audio – datos de audio referidos en elementos
<media>
12.3.1 Transmisión de audio MPEG-1
12.3.1.1
Transmisión como flujo elemental de audio
Para transmitir contenido de audio MPEG-1 como un flujo elemental de audio, los datos del audio se deben
transmitir obligatoriamente como MPEG-2 packetized elementary stream (audio PES), con el tipo de flujo
especificado de acuerdo con la atribución de tipos de flujos ISO/IEC 13818-1 (valor 0x03 para audio ISO/I EC
11172-3).
12.3.1.2
Transmisión en secciones MPEG-2
Para transmitir datos de audio MPEG-1 por medio de secciones MPEG-2 específicas (ver atribución de tipos de
flujos para secciones MPEG-2 en ISO/IEC 13818-1), uno de los siguientes métodos de transmisión se debe usar
obligatoriamente:
a)
como un archivo de flujo multiplexado en sistemas MPEG-1 (de acuerdo con la ISO/IEC 11172-1);
b)
como un archivo de flujo elemental de audio MPEG-1;
c)
como un archivo de flujo multiplexado en el formato TS especificado en 12.4.
12.3.2 Transmisión de audio MPEG-2
12.3.2.1
Transmisión como flujo elemental de audio
Para transmitir contenido de audio MPEG-2 AAC como un flujo elemental de audio, los datos del audio se deben
transmitir obligatoriamente como MPEG-2 packetized elementary stream (audio PES), con el tipo de flujo
especificado de acuerdo con la atribución de tipos de flujos ISO/IEC 13818-1 (valor 0x0F para audio
ISO/IEC 13818-7).
Para transmitir contenido de audio MPEG-2 BC como un flujo elemental de audio, los datos del audio se deben
transmitir obligatoriamente como MPEG-2 packetized elementary stream (PES), con el tipo de flujo especificado
de acuerdo con la atribución de tipos de flujos ISO/IEC 13818-1 (valor 0x04 para audio ISO/IEC 13818-3).
144
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
12.3.2.2
Transmisión en secciones MPEG-2
Para transmitir datos de audio MPEG-2 por medio de secciones MPEG-2 específicas (ver atribución de tipos de
flujos para secciones MPEG-2 en ISO/IEC 13818-1), uno de los siguientes métodos de transmisión se debe usar
obligatoriamente:
a)
como un archivo de flujo elemental de audio MPEG-2;
b)
como un archivo de flujo multiplexado en el formato TS especificado en 12.4.
12.3.3 Transmisión de audio MPEG-4
12.3.3.1
Transmisión como flujo elemental de audio
Para transmitir contenido de audio MPEG-4 como un flujo elemental de audio, los datos del audio se deben
transmitir obligatoriamente como MPEG-2 packetized elementary stream (audio PES), con el tipo de flujo
especificado en conformidad con la atribución de tipos de flujos ISO/IEC 13818-1 (valor 0x11 para audio
ISO/IEC 14496-3).
12.3.3.2
Transmisión en secciones MPEG-2
Para transmitir datos de audio MPEG-4 por medio de secciones MPEG-2 específicas (ver atribución de tipos de
flujos para secciones MPEG-2 en ISO/IEC 13818-1), uno de los métodos siguientes de transmisión se debe usar
obligatoriamente:
a)
como un archivo de flujo elemental de audio MPEG-4;
b)
como un archivo de flujo multiplexado en el formato TS especificado en 12.4.
12.3.4 Transmisión de audio AC3
12.3.4.1
Transmisión como flujo elemental de audio
Para transmitir contenido de audio AC3 como un flujo elemental de audio, los datos de audio se deben transmitir
obligatoriamente como MPEG-2 packetized elementary stream (audio PES) con el tipo de audio especificado
como 0x81.
12.3.4.2
Transmisión en secciones MPEG-2
Para transmitir datos de audio AC3 por medio de secciones MPEG-2 específicas (ver atribución de tipos de flujos
para secciones MPEG-2 en ISO/IEC 13818-1), uno de los métodos siguientes de transmisión se debe usar
obligatoriamente:
a)
como un archivo de flujo elemental de audio AC3;
b)
como un archivo de flujo multiplexado en el formato TS especificado en 12.4.
12.3.5 Transmisión de audio PCM (AIFF-C)
Se recomienda que el audio AIFF-C PCM se transmita como un archivo a través de secciones MPEG-2
específicas (ver atribución de tipos de flujos para secciones MPEG-2 en ISO/IEC 13818-1).
© ABNT 2007 - Todos los derechos reservados
145
ABNT NBR 15606-2:2007
12.4 Formato TS para transmisión de video/audio MPEG – Especificación de la codificación de
datos
12.4.1 Transmisión de video y audio multiplexados
Para transmitir datos de video MPEG-1/2/4 ó H.264|MPEG-4 AVC junto con datos de audio MPEG-1/2/4 ó AC3 en
archivos multiplexados en secciones MPEG-2 específicas, cada archivo de video/audio multiplexado se codifica
en un formato TS, conforme definido en la ISO/IEC 13818-1.
12.4.2 PSI requerido
Una tabla PAT se debe describir obligatoriamente. Cualquier PAT se debe describir obligatoriamente con el
program_number cuyo valor es diferente de 0 y este valor debe representar obligatoriamente un PID de la PMT.
Los valores disponibles de program_number serán definidos en un reglamento de estándar operativo.
Una tabla PMT se debe describir obligatoriamente. Cualquier descriptor de identificación de flujo que indique un
segundo loop debe contener obligatoriamente un descriptor PMT. En caso contrario, se puede insertar un
descriptor conforme sea necesario.
Se recomienda que los valores disponibles para component_tag y sus reglas de ocurrencia en descriptores ES y
PMT defaults en un segundo loop sean equivalentes a un reglamento operativo estándar dedicado al flujo
principal del tipo de media responsable por la transmisión del flujo en cuestión.
En una implementación en la cual un flujo de transporte se decodifica desde un archivo que fue transmitido con
base en la especificación de la codificación de datos definida en esta sección y se entrega en una interfaz digital
de alta velocidad, una tabla SIT se debe describir obligatoriamente (ver la ABNT NBR 15606-1). En otros casos,
las SIT no son necesarias, salvo especificación explícita en contrario.
Cualquier tabla diferente de PAT, PMT y SIT (por ejemplo: CAT, NIT, SDT, BAT, EIT, RST, TDT, TOT, PCAT,
SDTT y St – ver la ABNT NBR 15601) obligatoriamente no debe ser descrita.
Una tabla PAT debe ocurrir obligatoriamente en un flujo a una frecuencia no menor que una vez a cada 100 ms.
Una tabla PMT debe ocurrir obligatoriamente en un flujo a una frecuencia no menor que una vez cada 100 ms.
Por toda la duración de un archivo de formato TS, las tablas PAT y PMT obligatoriamente no deben ser
modificadas o actualizadas.
12.4.3 Transmisión en secciones MPEG-2
Para transmitir un archivo codificado con la especificación de codificación de datos de acuerdo con 12.6 en
secciones MPEG-2 específicas, la transmisión debe estar de acuerdo obligatoriamente con ABNT NBR 15606-3.
12.4.4 Restricciones en la reproducción
Para, al mismo tiempo, recibir un servicio por difusión y reproducir un archivo TS recibido a través de secciones
MPEG-2 específicas, son necesarios dos sistemas de procesamiento de flujo de transporte separados.
Las restricciones en la integración y coordinación de un contenido/evento recibido por un servicio de difusión con
un archivo TS no son descritas en esta Norma.
12.5 Esquema de codificación y transmisión de imágenes estáticas y gráficos de bitmap
referidos por elementos <media>
12.5.1 Transmisión de MPEG-2 I-frame, MPEG-4 I-VOP y H.264|MPEG-4 AVC I-picture
12.5.1.1
Transmisión en video PES para reproducción lineal
Para transmitir una imagen estática en cuadros MPEG-2 I por medio de un componente video PES, el esquema
de codificación debe obligatoriamente cumplir las convenciones definidas en la ABNT NBR 15606-1.
El componente PES se debe transmitir obligatoriamente como un flujo cuyo valor de tipo es igual a 0x02.
146
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
Para transmitir una imagen estática en MPEG-4 I-VOP por medio de un componente video PES, el esquema de
codificación debe obligatoriamente cumplir las convenciones definidas en la ABNT NBR 15606-1. El componente
PES se debe transmitir obligatoriamente como un flujo cuyo valor de tipo es igual a 0x10.
Para transmitir una imagen estática en H.264|MPEG-4 AVC I-picture por medio de un componente video PES, el
esquema de codificación debe obligatoriamente cumplir las convenciones definidas en la ABNT NBR 15606-1.
El componente PES se debe transmitir obligatoriamente como un flujo cuyo valor de tipo es igual a 0x1B.
12.5.1.2
Transmisión en secciones MPEG-2 para reproducción interactiva
Para transmitir una imagen estática en cuadros MPEG-2 I por medio de secciones MPEG-2, el esquema de
codificación debe obligatoriamente estar de conformidad con la ABNT NBR 15606-1. La imagen estática se debe
transmitir obligatoriamente como un archivo en la sección MPEG-2.
Para transmitir una imagen estática en MPEG4-I-VOP por medio de secciones MPEG-2, el esquema de
codificación debe obligatoriamente estar de conformidad con la ABNT NBR 15606-1. La imagen estática se debe
transmitir obligatoriamente como un archivo en la sección MPEG-2.
Para transmitir una imagen estática en H.264|MPEG-4 AVC I-picture por medio de secciones MPEG-2, el
esquema de codificación debe obligatoriamente estar conforme con las convenciones en la ABNT NBR 15606-1.
La imagen estática se debe transmitir obligatoriamente como un archivo en la sección MPEG-2.
En esos casos, el valor del tipo de flujo de la sección MPEG-2 debe obligatoriamente estar de acuerdo con la
ISO/IEC 13818-1.
12.5.2 Transmisión de imagen estática JPEG
Las imágenes estáticas JPEG se deben transmitir obligatoriamente a través de secciones MPEG-2 específicas
(ver la atribución de tipos de flujos para secciones MPEG-2 en la ISO/IEC 13818-1).
12.5.3 Esquema de codificación y transmisión del bitmap PNG
Para los datos de bitmap PNG que son exhibidos solamente bajo el control de datos CLUT especificados por
separado de esta Norma, los datos de la paleta, dentro de los datos PNG, pueden ser abreviados.
El gráfico de bitmap PNG se debe transmitir obligatoriamente a través de secciones MPEG-2 específicas (ver la
atribución de tipos de flujos para secciones MPEG-2 en la ISO/IEC 13818-1).
12.5.4 Esquema de codificación y transmisión de la animación MNG
Para que los datos de bitmap PNG en el formato de animación MNG que son exhibidos solamente bajo el control
de datos CLUT especificados por separado de esta Norma, los datos de la paleta dentro de los datos PNG
pueden ser omitidos. El gráfico de animación de bitmap MNG se debe transmitir obligatoriamente a través de
secciones MPEG-2 específicas (ver atribución de tipos de flujos para secciones MPEG-2 en la ISO/IEC 13818-1).
12.5.5 Esquema de codificación y transmisión de datos y animación de gráficos GIF
Los datos de gráficos y animaciones GIF se deben transmitir obligatoriamente a través de secciones MPEG-2
específicas (ver atribución de tipos de flujos para secciones MPEG-2 en la ISO/IEC 13818-1).
12.6 Codificación y transmisión de caracteres - archivos de texto externos referidos por
elementos <media>
Un archivo de texto codificado de acuerdo con la ISO 8859-1 se debe transmitir obligatoriamente por medio de
secciones MPEG-2 específicas (ver atribución de tipos de flujos para secciones MPEG-2 en la ISO/IEC 13818-1).
© ABNT 2007 - Todos los derechos reservados
147
ABNT NBR 15606-2:2007
12.7 Transmisión de documentos XML
12.7.1 Transmisión de documentos NCL y otros documentos XML que se utilizan en los comandos de
edición
Para transmitir un documento NCL u otro archivo de documento XML usado en parámetros de Comandos de
Edición NCL, uno de los métodos siguientes de transmisión se debe usar obligatoriamente:
a) por medio de un protocolo de canal de interactividad;
b) por medio de secciones MPEG-2 específicas.
Si un protocolo de canal interactivo se usa para bajar un documento NCL u otro archivo de Documento XML
mencionado en un parámetro del comando de edición addNode, el parámetro uri del comando de edición
addDocument o addNode (ver Sección 9) no puede tener su esquema igual a “x-sbtvd”, y su parámetro
correspondiente id se debe definir obligatoriamente como NULL. El parámetro uri debe especificar
obligatoriamente la localización del documento y el esquema de protocolo usado para transmitir el documento.
Si secciones MPEG-2 específicas fueran usadas, son posibles varias alternativas, como a seguir. La alternativa
elegida por el SBTVD debe obligatoriamente seguirla especificaciónABNT NBR 15606-3.
12.7.2 Transmisión en Secciones MPEG-2
12.7.2.1 1Transporte de comandosde edición usando descriptores de evento de flujo y carrusel de
objetos DSM-CC
En los ambientes de televisión digital es usual la adopción de protocolo DSM-CC para transporte de comandos de
edición en flujos elementales MPEG-2.
Comandos de edición son transportados en descriptores de evento de flujo DSM-CC, que tienen una estructura
muy parecida con la de los descriptores de eventos definidos por la Figura 5, como ilustra la Figura 6.
Sintaxis
StreamEventDescriptor ( ) {
descriptorTag
descriptorLenght
eventId
Reserved
eventNPT
privateDataLenght
commandTag
sequenceNumber
finalFlag
privateDataPayload
FCS
Número de bits
8
8
16
31
33
8
8
7
1
8 a 2008
8
}
Figura 6 – Descriptor de evento de flujo DSM-CC para comandos de edición
El protocolo de carrusel de objetos DSM-CC permite la transmisión cíclica de objetos de eventos y sistemas de
archivos. Los objetos de eventos se utilizan para mapear nombres de eventos de flujo a ids de eventos de flujo, y
son utilizadospara informar al Ginga sobre eventos deflujo DSM-CC que pueden serrecibidos. Los nombres de los
eventospermiten especificar tipos de eventos, ofreciendo mayor nivel de abstracción a las aplicaciones del
middleware. En ese caso, conviene que el Gestor de la Base Privada, así como los objetos de ejecución
148
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
procedural NCL (ejemplo, NCLua, NCLet), sean registrados como observadores de los eventos de flujo con los
cuales actúan, utilizando nombres de evento, en el caso: “nclEditingCommand”.
Además de los objetos de eventos, el protocolo de carrusel de objetos DSM-CC también se utiliza para
transportar archivos organizados en directorios. El demultiplexador DSM-CC es responsable de montar el sistema
de archivo en eldispositivoreceptor.
A fin de transmitir los archivos de Documentos NCL u otros archivos de Documento XML, usados en los
parámetros de comandos de edición, por medio de un carrusel de objetos que carga la especificación XML, un
objeto de eventos debe obligatoriamente ser transmitido, a fin de mapear el nombre “nclEditingCommand” para el
eventId del descriptor de evento de flujo DSM-CC, que debe obligatoriamente cargar el comando de edición NCL
(ver Sección 9).
El campo privateDataPayload del descriptor de evento del flujo debe obligatoriamente cargar un conjunto de
pares de referencia {uri, id}. El parámetro uri del primer par debe obligatoriamente tener el esquema “x-sbtvd” y el
camino absoluto del documento XML (el camino en el servidor de datos). El parámetro id correspondiente en el
par debe obligatoriamente hacer referencia al IOR de especificación del documento XML (carouselId, moduleId,
objectKey; de acuerdo con la ABNT NBR 15606-3 e ISO/IEC 13818-6) en el carrusel de objetos.
Si otros sistemas de archivos necesitan ser transmitidos usando otros carruseles de objeto, con el fin de
completar el comando de edición con contenido de media (como es usual en los comandos addDocument y
addNode), otros pares {uri, id} deben estar presentes obligatoriamente en el comando. En ese caso, el parámetro
uri debe tener obligatoriamente el esquema “x-sbtvd” y el camino local absoluto de la raíz del sistema de archivos
(el camino en el servidor de transmisión de datos) y el respectivo parámetro ior en el par debe obligatoriamente
hacer referencia al IOR (carouselId, moduleId, objectKey; de acuerdo con la ABNT NBR 15606-3 e ISO/IEC
13818-6) de cualquier archivo o directorio hijo de la raíz en el carrusel de objetos (el service gateway del carrusel).
La Figura 7 ilustra un ejemplo de transmisión de documento NCL por medio de un carrusel de objetos. En ese
ejemplo, un proveedor de contenido quiere transmitir un programa interactivo llamado "weatherConditions.ncl"
almacenado en uno de sus servidores de datos (sistema local de archivos, de acuerdo con la Figura 7).
Un carrusel de objetos debe entonces ser generado (dominio de servicio = 1, de acuerdo con la Figura 7)
cargando todo el contenido del programa interactivo (archivo .ncl y todos los archivos de media) y también un
objeto de eventos (moduleId = 2 y objectKey = 2, de acuerdo con la Figura 7), mapeando el nombre
“nclEditingCommand” para el valor de eventId (valor “3” de acuerdo con la Figura 7).
Un descriptor de evento de flujo también se deberá transmitir con el valor de eventId apropiado, en el ejemplo "3",
y el valor “0x05” de commandTag, que indica un comando addDocument (ver Sección 9). El parámetro uri debe
contener el esquema “x-sbtvd” y el camino absoluto del documento NCL (“C:\nclRepository\weather” de acuerdo
con la Figura 7). Finalmente, el IOR del documento NCL en el carrusel de objetos se transporta en el parámetro
xmlDocument (carouselId = 1, moduleId = 1, objectKey = 2 de acuerdo con la Figura 7).
© ABNT 2007 - Todos los derechos reservados
149
ABNT NBR 15606-2:2007
Figura 7 — Ejemplo de una transmisión de documento NCL
12.7.2.2
Transporte de comandos de edición usando estructuras específicas
12.7.2.2.1 Definiciones de las estructuras de datos
Los descriptores de evento (definidos en la sección 9) pueden enviarse en flujo elemental MPEG-2 TS usando
eventos de flujo DSM-CC, como discutido en 12.7.1.1, o usando cualquier protocolo para transmisión de datos sin
solicitación (“pushed data”).
Tres tipos de estructura de datos pueden ser definidos para dar soporte a la transmisión deparámetros de los
comandos de edición NCL: mapa, metadatos y archivos de datos.
Para estructuras de mapa, el campo mappingType identifica el tipo del mapa. Si el valor de mappingType es igual
a “0x01” (“events”), un mapa de eventos es caracterizado. En ese caso, después del campo mappingType, viene
una lista de identificadores de eventos, como definido en la Tabla 60. Pueden definirse otros valores para el
campo mappingType, pero no son relevantes para esta Norma.
Tabla 60 – Lista de identificadores de eventos definidos por la estructura de mapa
Sintaxis
Número de bits
mappingStructure ( ) {
mappingType
8
for (i=1; i<N; i++){
eventId
8
eventNameLength
8
eventName
8 a 255
}
}
150
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
Los mapas del tipo “event” (mapas de eventos) se usan para mapear nombres de eventos en eventos de los
descriptores de evento (ver Figura 5). Los mapas de eventos son usados para indicar qué eventos deben ser
obligatoriamente recibidos. Los nombres de eventos permiten especificar tipos de eventos, ofreciendomayor nivel
de abstracción a las aplicaciones del middleware. En ese caso, conviene que el Gestor de Base Privada, así
como los objetos de ejecución procedural NCL (ejemplo, NCLua, NCLet) sean registrados como observadores de
los eventos de flujo con los cuales operan, utilizando nombres de eventos, en ese caso: “nclEditingCommand”.
Cuando un comando de edición NCL necesita ser enviado, debe crearse obligatoriamente un mapa de eventos,
mapeando la string “nclEditingCommand” en un eventId de un descriptor de evento seleccionado (ver Figura 5).
Uno o más descriptores de evento con el eventId previamente seleccionado son entonces creados y enviados.
Esos descriptores de evento pueden tener sus tiempos de referencia como cero, o pueden tener su ejecución
postergada para un tiempo especificado. El Gestor de Bases Privadas debe registrarse obligatoriamente como
oyente de un evento “nclEditingCommand” para ser notificado de la llegada de ese tipo de evento.
Cada estructura de archivos de datos es, de hecho, un contenido de archivo que compone una aplicación NCL o
un documento XML definiendo una entidad NCL: un archivo conteniendo la especificación XML o un archivo con
contenido de media de la aplicación o del nudo a ser adicionado (video, audio, texto, imagen, ncl, lua etc.).
Una estructura de metadatos es un documento XML, como se define en el esquema a seguir. El esquema define,
para cada dato entregado sin solicitación (pushed file), una asociación entre su localización en el sistema de
transporte (identificación del sistema de transporte (atributo component_tag) y la identificación del archivo en el
sistema de transporte (atributo structureId)) y su identificador de recurso universal (atributo uri).
<!-XML Schema for NCL Section Metadata File
This is NCL
Copyright: 2000-2005 PUC-RIO/LABORATORIO TELEMIDIA, All Rights Reserved.
See http://www.telemidia.puc-rio.br
Public URI: http://www.ncl.org.br/NCLSectionMetadataFile.xsd
Author: TeleMidia Laboratory
Revision: 19/09/2006
Schema for the NCL Section Metadata File namespace.
-->
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:NCLSectionMetadataFile="http://www.ncl.org.br/NCLSectionMetadataFile"
targetNamespace="http:// www.ncl.org.br/NCL3.0/NCLSectionMetadataFile"
elementFormDefault="qualified" attributeFormDefault="unqualified" >
<complexType name="NCLSectionMetadataType">
<sequence>
<sequence>
<element ref="NCLSectionMetadataFile:baseData" minOccurs="0"
maxOccurs="unbounded"/>
</sequence>
<element ref="NCLSectionMetadataFile:pushedRoot" minOccurs="0"
maxOccurs="1"/>
<sequence>
<element ref="NCLSectionMetadataFile:pushedData" minOccurs="0"
maxOccurs="unbounded"/>
</sequence>
</sequence>
<attribute name="name" type="string" use="optional"/>
<attribute name="size" type="positiveInteger" use="optional"/>
</complexType>
<complexType name="baseDataType">
© ABNT 2007 - Todos los derechos reservados
151
ABNT NBR 15606-2:2007
<sequence>
<element ref="NCLSectionMetadataFile:pushedRoot" minOccurs="0"
maxOccurs="1"/>
<sequence>
<element ref="NCLSectionMetadataFile:pushedData"
minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</sequence>
<attribute name="uri" type="anyURI" use="required"/>
</complexType>
<complexType name="pushedRootType">
<attribute name="component_tag" type="positiveInteger"
use="optional"/>
<attribute name="structureId" type="string" use="required"/>
<attribute name="uri" type="anyURI" use="required"/>
<attribute name="size" type="positiveInteger" use="optional"/>
</complexType>
<complexType name="pushedDataType">
<attribute name="component_tag" type="positiveInteger"
use="optional"/>
<attribute name="structureId" type="string" use="required"/>
<attribute name="uri" type="anyURI" use="required"/>
<attribute name="size" type="positiveInteger" use="optional"/>
</complexType
<!-- declare global elements in this module -->
<element name="metadata" type="NCLSectionMetadataFile:NCLSectionMetadataType"/>
<element name="baseData" type="NCLSectionMetadataFile:baseDataType"/>
<element name="pushedRoot" type="NCLSectionMetadataFile:pushedRootType"/>
<element name="pushedData" type="NCLSectionMetadataFile:pushedDataType"/>
</schema>
Para cada archivo de documento NCL u otros archivos de documento XML, usados en los comandos de edición
addDocument o addNode, debe ser definida, por lo menos, una estructura de metadatos. Solamente un archivo
de aplicación NCL o un archivo de documento XML representando un nudo NCL a ser insertado puede ser
definido por estructura de metadatos. Sin embargo, una aplicación NCL (y sus archivos de contenido) o un
documento NCL (y sus archivos de contenido) pueden extenderse por más de una estructura de metadatos. Más
aun, pueden existir estructuras de metadatos sin ninguna aplicación NCL o documento XML descritos en sus
elementos <pushedRoot> y <pushedData>.
Las tres estructuras anteriormente definidas pueden ser transmitidas usando sistemas de transporte diferentes,
como se explica a continuación.
12.7.2.2.2 Transporte en un tipo específico de sección MPEG-2
El uso de un tipo específico de sección MPEG-2 (identificado por un valor específico del campo table_id de una
sección privada MPEG-2), a partir de ahora denominada Sección NCL, permite la transmisión de las tres
estructuras de datos anteriormente definidas: mapas, metadatos y archivos de datos.
Cada Sección NCL contiene los datos de solamente un estructura. Sin embargo, una estructura puede extenderse
por varias Secciones. Las estructuras de datos pueden ser transmitidas en cualquier orden y cuantas veces sea
necesario. El inicio de una estructura de datos es limitado por el campo payload_unit_start_indicator de un
paquete TS. Después de los cuatro bytes del encabezamiento TS, la carga (payload) del paquete TS comienza,
con un campo puntero de un byte indicando el comienzo de una Sección NCL (ver ISO/IEC 13818-1). El
encabezamiento de la Sección NCL es definido entonces como una sección MPEG-2 (ver ISO/IEC 13818-1). El
primer byte de carga (payload) de la Sección NCL identifica el tipo de la estructura transportada (0x01 para
152
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
metadatos; 0x02 para archivos de datos y 0x03 para mapas de eventos). El segundo byte carga un identificador
único de la estructura (structureId) en el flujo elemental de transporte.
NOTA El flujo elemental y el identicador de la estructura son aquellos que son asociados, por la estructura de metadatos, a
través de los atributos component_ta y structureId de los elementos <pushedRoot> y <pushedData>, a localizadores de
archivos (URL).
Después del segundo byte viene una estructura de datos seriada que puede ser mappingStructure (como ilustra
la Tabla 60), o la estructura de metadatos (un documento XML), o una estructura de archivos de datos (un
contenido de archivo seriado). El demultiplexador de Secciones NCL es responsable de montar la estructura de la
aplicación en el dispositivo receptor.
NOTA
Es importante resaltar que las Secciones NCL pueden también transportar las estructuras de datos definidas
encapsuladas en otras estructuras de datos. Por ejemplo, MPE (Multi-protocol Encapsulation) puede usarse. En ese caso,
Secciones NCL serían Secciones MPEG-2 de datagrama. Más aun, todas las estructuras de datos mencionadas pueden
empaquetarse en otro formato de datos de protocolo, como, por ejemplo, paquetes FLUTE.
En el mismo flujo elemental que carga la especificación XML (el archivo del documento NCL o de otro documento
XML usados en los comandos de edición NCL) es recomendable que se transmita un archivo mapa de eventos,
para que sea mapeado el nombre “nclEditingCommand” en el eventId del descriptor de eventos que deberá
obligatoriamente transportar los comandos de edición NCL, como se describe en la Sección 9. El campo
privateDataPayload del descriptor de eventos debe obligatoriamente cargar el par de referencias {uri, id}. Los
parámetros uri tienen siempre el valor “null”. En el caso de los documentos addDocument y addNode, el
parámetro id del primer par debe obligatoriamente identificar el flujo elemental (“component_tag”) y la estructura
de metadatos que éste transporta (“structureId”), que, a su vez, contiene el camino absoluto del documento NCL o
de la especificación del nudo NCL (el camino en el servidor de datos) y la estructura relacionada correspondiente
(“structureId”) transportada en las Seccions NCL del mismo flujo elemental. Si otras estructuras de metadatos
adicionales fueran necesarias para completar los comandos de edición addDocument o addNode command, otros
pares {uri, id} deben obligatoriamente hacerse presentes en el comando. En ese caso, los parámetros uri también
deben tener el valor “null” y los parámetros id correspondientes deben referirse obligatoriamente al
component_tag y al metadato structureId correspondiente.
La Figura 8 ilustra un ejemplo de transmisión de un documento NCL a través de Secciones NCL. En ese ejemplo,
un proveedor de contenido quiere transmitir un programa interactivo llamado “weatherConditions.ncl”, almacenado
en uno de sus servidores de datos (sistema de archivo local en la Figura 8). Un flujo elemental MPEG-2
(component_tag=”0x09”) debe, entonces, ser generado, cargando todo el contenido del programa interactivo (el
archivo ncl y todos los archivos de contenido de media). Tambiés es generado un mapa de eventos
(structureType=”0x03”, structureId=”0x0C”, en la Figura 8), mapeando el nombre “nclEditingCommand” al valor de
eventId (valor “3”, en la Figura 8). Un descriptor de evento también debe ser transmitido con el valor apropiado
para eventId, en el ejemplo el valor “3”, y el valor de commandTag igual a “0x05”, que indica un comando
addDocument (ver Sección 9). El parámetro uri debe tener obligatoriamente el valor “null” y el parámetro id debe
tener obligatoriamente el valor (component_tag= “0x09”, structureId= “0x0B”), como en la Figura 8.
© ABNT 2007 - Todos los derechos reservados
153
ABNT NBR 15606-2:2007
Figura 8 – Ejemplo de transmisión de documento NCL usando Secciones NCL MPEG-2
12.7.2.2.3
Transporte de las estructuras de metadatos como parámetro de comandos de edición
Una alternativa al transporte de estructuras de metadatos directamente en Secciones NCL es tratar estas
estructuras como parámetros de los comandos addDocument y addNode, transportados en el campo
privateDataPayload de los descriptores de evnto.
En ese caso, el conjunto de pares {uri, id} de los comandos addDocument y addNode es sustituido por
parámetros de la estructura de metadatos, que definen un conjunto de pares {“uri”, “component_tag, structureId”}
para cada archivo transmitido sin solicitación (pushed file).
En el ejemplo de la Figura 8, el nuevo transporte sería exactamente el mismo, con excepción del descriptor de
evento. Esos descriptores en vez de tener el par {uri; id} igual al valor {“null”; “0x09, 0x0B”} como parámetro,
tendrían la estructura de metadatos seriada. En la estructura de metadatos, los atributos component-tag de los
elementos <pushedRoot> y <pushedData> deben obligatoriamente, en este caso, ser definidos, toda vez que la
estructura no es transportada más en el mismo flujo elemental que transporta los archivos de la aplicación NCL.
12.7.2.2.4
Transporte de estructuras de metadatos en secciones de metadatos MPEG-2
Otra alternativa es transportar las estructuras de metadatos en secciones de metadatos MPEG-2, transportadas
en flujos MPEG-2 del tipo “0x16”. Como siempre, cada sección de metadatos MPEG-2 puede contener datos de
solamente una estructura de metadatos. Sin embargo, una estructura de metadatos puede extenderse por varias
secciones de metadatos.
La Tabla 61 ilustra la sintaxis de la sección de metadatos para el transporte de estructuras de metadatos, que
deben estar de acuerdo con ISO/IEC 13818-1:2007.
154
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
Tabla 61 – Sintaxis de la sección para el transporte de estructuras de metadatos
Número de
bits
Valor
table_id
8
0x06
section_syntax_indicator
1
1
prívate_indicator
1
1
random_access_indicator
1
1
decoder_config_flag
1
0
metadata_section_length
12
entero
metadata_service_id
8
entero a ser
estandarizado
reserved
8
section_fragment_indication
2
de acuerdo con
la Tabla 62
versión_number
5
entero
current_next_indicator
1
1
section_number
8
entero
last_section_number
8
entero
structureId
8
entero
Sintaxis
Metadata section() {
For (i=1; i< N; i++) {
serialized_metadata_structure_byte
8
}
CRC_32
32
}
Tabla 62 – Indicación de fragmento de sección
Valor
Descripción
11
Una única sección de metadatos cargando una estructura de metadatos completa
10
Primera sección de metadatos de una serie, con datos de una misma estructura de
metadatos
01
Última sección de metadatos de una serie, con datos de una misma estructura de
metadatos
00
Una sección de metadatos de una serie, con datos de una misma estructura de
metadatos, pero que no es la primera ni la última sección
Como anteriormente, en el mismo flujo elemental que transporta la especificación XML (el archivo del documento
NCL u otro archivo XML usados en los comandos de edicón NCL), es recomendable que se transmita un archivo
mapa de eventos con el fin de mapear el nombre “nclEditingCommand” al eventId del descriptor de evento que
carga el comando de edición NCL, comose describe en la Sección 9. El campo privateDataPayload del descriptor
de evento debe obligatoriamente transportar un conjunto de pares de referencia {uri, id}. Los parámetros uri
deben obligatoriamente el valor “null”. En el caso de los comandos addDocument y addNode, el parámetro id del
primer par debe obligatoriamente identificar el flujo elemental (“component_tag”) del tipo= “0x16” y la estructura de
© ABNT 2007 - Todos los derechos reservados
155
ABNT NBR 15606-2:2007
metadatos (“structureId”) que carga el camino absoluto del documento NCL o de la especificación del nudo NCL
(el camino en el servidor de datos). Si otras estructuras de metadatos es usada para relacionar archivos
presentes en el documento NCL o en la especificación del nudo NCL, con el fin de completar los comandos
addDocument o addNode con contenidos de media, otros pares de referencia {uri, id} deben definirse en el
comando. En ese caso, el parámetro uri debe obligatoriamente tener el valor “null” y el parámetro id
correspondiente en el par debe obligatoriamente referir al component_tag y el structureId del metadato
correspondiente.
En el ejemplo de la Figura 8, el nuevo escenario sería similar. Sólo se deben hacer pequeños cambios de forma
que el descriptor de evento refiera al flujo elemental y su sección que carga la estructura de metadatos
(component_tag= “0x08” y structureId= “0x0B”), y que la estructura de metadatos también refiera al flujo elemental
dónde los archivos del documento serán transportados. La Figura 9 ilustra la nueva situación.
Figura 9 – Ejemplo de transmisión de documento NCL usando Secciones de Metadatos MPEG-2
12.7.3 Transmisión de documentos XML externos
Los documentos XML externos referidos por los elementos <media>, como, por ejemplo, un objeto de media
XHTML, se debe transmitir obligatoriamente a través de secciones MPEG-2 específicas (ver la atribució de tipos d
flujo para secciones MPEG-2 en ISO/IEC 13818-1).
13 Seguridad
El modelo de seguridad Ginga es totalmente compatible con el modelo de seguridad SBTVD. Éste trata con las
mismas áreas de seguridad; o sea, autenticación de aplicaciones de difusión, políticas de seguridad para
aplicaciones, seguridad sobre el canal de interacción y gestión de certificados.
La autenticación de aplicaciones Ginga-NCL se debe realizar obligatoriamente del mismo modo para aplicaciones
Ginga-J. Si está firmada, la aplicación debe seguir obligatoriamente la estructura de firma como especificado para
el Ginga-J. Las aplicaciones Ginga-NCL no autenticadas van a operar dentro de un ambiente de caja de arena
(sand box). Las aplicaciones Ginga-NCL autenticadas, asociadas a un archivo de solicitud de autorización,
pueden tener autorizaciones concedidas fuera de la caja de arena.
156
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
Anexo A
(normativo)
Esquemas de los módulos NCL 3.0 que se utilizan en los perfiles TVD
Básico y TVD Avanzado
A.1 Módulo Structure: NCL30Structure.xsd
<!-XML Schema for the NCL modules
This is NCL
Copyright: 2000-2005 PUC-RIO/LABORATORIO TELEMIDIA, All Rights Reserved.
See http://www.telemidia.puc-rio.br
Public URI: http://www.ncl.org.br/NCL3.0/modules/NCL30Structure.xsd
Author: TeleMidia Laboratory
Revision: 19/09/2006
Schema for the Structure module namespace,
-->
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:structure="http://www.ncl.org.br/NCL3.0/Structure"
targetNamespace="http://www.ncl.org.br/NCL3.0/Structure"
elementFormDefault="qualified" attributeFormDefault="unqualified" >
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- define the top-down structure of an NCL language document.
-->
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<complexType name="nclPrototype">
<sequence>
<element ref="structure:head" minOccurs="0" maxOccurs="1"/>
<element ref="structure:body" minOccurs="0" maxOccurs="1"/>
</sequence>
<attribute name="id" type="ID" use="required"/>
<attribute name="title" type="string" use="optional"/>
</complexType>
<complexType name="headPrototype">
</complexType>
<complexType name="bodyPrototype">
<attribute name="id" type="ID" use="optional"/>
</complexType>
<!-- declare global elements in this module -->
<element name="ncl" type="structure:nclPrototype"/>
<element name="head" type="structure:headPrototype"/>
<element name="body" type="structure:bodyPrototype"/>
</schema>
© ABNT 2007 - Todos los derechos reservados
157
ABNT NBR 15606-2:2007
A.2 Módulo Layout: NCL30Layout.xsd
<!-XML Schema for the NCL modules
This is NCL
Copyright: 2000-2005 PUC-RIO/LABORATORIO TELEMIDIA, All Rights Reserved.
See http://www.telemidia.puc-rio.br
Public URI: http://www.ncl.org.br/NCL3.0/modules/NCL30Layout.xsd
Author: TeleMidia Laboratory
Revision: 19/09/2006
Schema for the NCL Layout module namespace.
-->
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:layout="http://www.ncl.org.br/NCL3.0/Layout"
targetNamespace="http://www.ncl.org.br/NCL3.0/Layout"
elementFormDefault="qualified" attributeFormDefault="unqualified" >
<complexType name="regionBasePrototype">
<attribute name="id" type="ID" use="optional"/>
<attribute name="type" type="string" use="optional"/>
<attribute name="device" type="string" use="optional"/>
<attribute name="region" type="string" use="optional"/>
</complexType>
<complexType name="regionPrototype">
<sequence minOccurs="0" maxOccurs="unbounded">
<element ref="layout:region" />
</sequence>
<attribute name="id" type="ID" use="required"/>
<attribute name="title" type="string" use="optional"/>
<attribute name="height" type="string" use="optional"/>
<attribute name="left" type="string" use="optional"/>
<attribute name="right" type="string" use="optional"/>
<attribute name="top" type="string" use="optional"/>
<attribute name="bottom" type="string" use="optional"/>
<attribute name="width" type="string" use="optional"/>
<attribute name="zIndex" type="integer" use="optional"/>
</complexType>
<!-- declare global attributes in this module -->
<!-- define the region attributeGroup -->
<attributeGroup name="regionAttrs">
<attribute name="region" type="string" use="optional"/>
</attributeGroup>
<!-- declare global elements in this module -->
<element name="regionBase" type="layout:regionBasePrototype"/>
<element name="region" type="layout:regionPrototype"/>
</schema>
158
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
A.3 Módulo Media: NCL30Media.xsd
<!-XML Schema for the NCL modules
This is NCL
Copyright: 2000-2005 PUC-RIO/LABORATORIO TELEMIDIA, All Rights Reserved.
See http://www.telemidia.puc-rio.br
Public URI: http://www.ncl.org.br/NCL3.0/modules/NCL30Media.xsd
Author: TeleMidia Laboratory
Revision: 19/09/2006
Schema for the NCL Media module namespace.
-->
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:media="http://www.ncl.org.br/NCL3.0/Media"
targetNamespace="http://www.ncl.org.br/NCL3.0/Media"
elementFormDefault="qualified" attributeFormDefault="unqualified" >
<complexType name="mediaPrototype">
<attribute name="id" type="ID" use="required"/>
<attribute name="type" type="string" use="optional"/>
<attribute name="src" type="anyURI" use="optional"/>
</complexType>
<!-- declare global elements in this module -->
<element name="media" type="media:mediaPrototype"/>
</schema>
© ABNT 2007 - Todos los derechos reservados
159
ABNT NBR 15606-2:2007
A.4 Módulo Context: NCL30Context.xsd
<!-XML Schema for the NCL modules
This is NCL
Copyright: 2000-2005 PUC-RIO/LABORATORIO TELEMIDIA, All Rights Reserved.
See http://www.telemidia.puc-rio.br
Public URI: http://www.ncl.org.br/NCL3.0/modules/NCL30Context.xsd
Author: TeleMidia Laboratory
Revision: 19/09/2006
Schema for the NCL Context module namespace.
-->
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:context="http://www.ncl.org.br/NCL3.0/Context"
targetNamespace="http://www.ncl.org.br/NCL3.0/Context"
elementFormDefault="qualified" attributeFormDefault="unqualified" >
<!-- define the compositeNode element prototype -->
<complexType name="contextPrototype">
<attribute name="id" type="ID" use="required"/>
</complexType>
<!-- declare global elements in this module -->
<element name="context" type="context:contextPrototype"/>
</schema>
160
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
A.5 Módulo MediaContentAnchor: NCL30MediaContentAnchor.xsd
<!-XML Schema for the NCL modules
This is NCL
Copyright: 2000-2005 PUC-RIO/LABORATORIO TELEMIDIA, All Rights Reserved.
See http://www.telemidia.puc-rio.br
Public URI: http://www.ncl.org.br/NCL3.0/modules/NCL30MediaContentAnchor.xsd
Author: TeleMidia Laboratory
Revision: 19/09/2006
Schema for the NCL Media Content Anchor module namespace.
-->
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:mediaAnchor="http://www.ncl.org.br/NCL3.0/MediaContentAnchor"
targetNamespace="http://www.ncl.org.br/NCL3.0/MediaContentAnchor"
elementFormDefault="qualified" attributeFormDefault="unqualified" >
<!-- define the temporalAnchorAttrs attribute group -->
<attributeGroup name="temporalAnchorAttrs">
<attribute name="begin" type="string" use="optional"/>
<attribute name="end" type="string" use="optional"/>
</attributeGroup>
<!-- define the textAnchorAttrs attribute group -->
<attributeGroup name="textAnchorAttrs">
<attribute name="text" type="string" use="optional"/>
<attribute name="position" type="unsignedLong" use="optional"/>
</attributeGroup>
<!-- define the sampleAnchorAttrs attribute group -->
<attributeGroup name="sampleAnchorAttrs">
<attribute name="first" type="unsignedLong" use="optional"/>
<attribute name="last" type="unsignedLong" use="optional"/>
</attributeGroup>
<!-- define the coordsAnchorAttrs attribute group -->
<attributeGroup name="coordsAnchorAttrs">
<attribute name="coords" type="string" use="optional"/>
</attributeGroup>
<!-- define the labelAttrs attribute group -->
<attributeGroup name="labelAttrs">
<attribute name="label" type="string" use="optional"/>
</attributeGroup>
<complexType name="componentAnchorPrototype">
<attribute name="id" type="ID" use="required"/>
<attributeGroup ref="mediaAnchor:coordsAnchorAttrs" />
<attributeGroup ref="mediaAnchor:temporalAnchorAttrs" />
<attributeGroup ref="mediaAnchor:textAnchorAttrs" />
<attributeGroup ref="mediaAnchor:sampleAnchorAttrs" />
<attributeGroup ref="mediaAnchor:labelAttrs" />
</complexType>
<!-- declare global elements in this module -->
<element name="area" type="mediaAnchor:componentAnchorPrototype"/>
</schema>
© ABNT 2007 - Todos los derechos reservados
161
ABNT NBR 15606-2:2007
A.6 Módulo CompositeNodeInterface: NC30CompositeNodeInterface.xsd
<!-XML Schema for the NCL modules
This is NCL
Copyright: 2000-2005 PUC-RIO/LABORATORIO TELEMIDIA, All Rights Reserved.
See http://www.telemidia.puc-rio.br
Public URI: http://www.ncl.org.br/NCL3.0/modules/NCL30CompositeNodeInterface.xsd
Author: TeleMidia Laboratory
Revision: 19/09/2006
Schema for the NCL Composite Node Interface module namespace.
-->
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:compositeInterface="http://www.ncl.org.br/NCL3.0/CompositeNodeInterface"
targetNamespace="http://www.ncl.org.br/NCL3.0/CompositeNodeInterface"
elementFormDefault="qualified" attributeFormDefault="unqualified" >
<complexType name="compositeNodePortPrototype">
<attribute name="id" type="ID" use="required" />
<attribute name="component" type="IDREF" use="required"/>
<attribute name="interface" type="string" use="optional" />
</complexType>
<!-- declare global elements in this module -->
<element name="port" type="compositeInterface:compositeNodePortPrototype" />
</schema>
162
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
A.7 Módulo PropertyAnchor: NCL30PropertyAnchor.xsd
<!-XML Schema for the NCL modules
This is NCL
Copyright: 2000-2005 PUC-RIO/LABORATORIO TELEMIDIA, All Rights Reserved.
See http://www.telemidia.puc-rio.br
Public URI: http://www.ncl.org.br/NCL3.0/modules/NCL30PropertyAnchor.xsd
Author: TeleMidia Laboratory
Revision: 19/09/2006
Schema for the NCL Property Anchor module namespace.
-->
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:propertyAnchor="http://www.ncl.org.br/NCL3.0/PropertyAnchor"
targetNamespace="http://www.ncl.org.br/NCL3.0/PropertyAnchor"
elementFormDefault="qualified" attributeFormDefault="unqualified" >
<complexType name="propertyAnchorPrototype">
<attribute name="name" type="string" use="required" />
<attribute name="value" type="string" use="optional" />
</complexType>
<!-- declare global elements in this module -->
<element name="property" type="propertyAnchor:propertyAnchorPrototype"/>
</schema>
© ABNT 2007 - Todos los derechos reservados
163
ABNT NBR 15606-2:2007
A.8 Módulo SwitchInterface: NCL30SwitchInterface.xsd
<!-XML Schema for the NCL modules
This is NCL
Copyright: 2000-2005 PUC-RIO/LABORATORIO TELEMIDIA, All Rights Reserved.
See http://www.telemidia.puc-rio.br
Public URI: http://www.ncl.org.br/NCL3.0/modules/NCL30SwitchInterface.xsd
Author: TeleMidia Laboratory
Revision: 19/09/2006
Schema for the NCL Switch Interface module namespace.
-->
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:switchInterface="http://www.ncl.org.br/NCL3.0/SwitchInterface"
targetNamespace="http://www.ncl.org.br/NCL3.0/SwitchInterface"
elementFormDefault="qualified" attributeFormDefault="unqualified" >
<complexType name="mappingPrototype">
<attribute name="component" type="IDREF" use="required"/>
<attribute name="interface" type="string" use="optional"/>
</complexType>
<complexType name="switchPortPrototype">
<sequence>
<element ref="switchInterface:mapping" minOccurs="1" maxOccurs="unbounded"/>
</sequence>
<attribute name="id" type="ID" use="required"/>
</complexType>
<!-- declare global elements in this module -->
<element name="mapping" type="switchInterface:mappingPrototype"/>
<element name="switchPort" type="switchInterface:switchPortPrototype" />
</schema>
164
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
A.9 Módulo Descriptor: NCL30Descriptor.xsd
<!-XML Schema for the NCL modules
This is NCL
Copyright: 2000-2005 PUC-RIO/LABORATORIO TELEMIDIA, All Rights Reserved.
See http://www.telemidia.puc-rio.br
Public URI: http://www.ncl.org.br/NCL3.0/modules/NCL30Descriptor.xsd
Author: TeleMidia Laboratory
Revision: 19/09/2006
Schema for the NCL Descriptor module namespace.
-->
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:descriptor="http://www.ncl.org.br/NCL3.0/Descriptor"
targetNamespace="http://www.ncl.org.br/NCL3.0/Descriptor"
elementFormDefault="qualified" attributeFormDefault="unqualified" >
<complexType name="descriptorParamPrototype">
<attribute name="name" type="string" use="required" />
<attribute name="value" type="string" use="required"/>
</complexType>
<complexType name="descriptorPrototype">
<sequence minOccurs="0" maxOccurs="unbounded">
<element ref="descriptor:descriptorParam"/>
</sequence>
<attribute name="id" type="ID" use="required"/>
<attribute name="player" type="string" use="optional"/>
</complexType>
<!-Formatters should support the following descriptorParam names.
* For audio players: soundLevel; balanceLevel; trebleLevel; bassLevel.
* For text players: style, which refers to a style sheet with information for text presentation.
* For visual media players: background, specifying the background color used to fill the area of a region displaying media; scroll,
which allows the specification of how an author would like to configure the scroll in a region; fit, indicating how an object will be
presented (hidden, fill, meet, meetBest, slice); transparency, indicating the degree of transparency of an object presentation (the
value shall be between 0 and 1, or a real value in the range [0,100] ending with the character “%” (e.g. 30%)); visible, indicating
if the presentation is to be seen or hidden; and the object positioning parameters: top, left, bottom, right, width, height, sie and
bounds.
* For players in general: reusePlayer, which determines if a new player shall be instantiated or if a player already instantiated
shall be used; and playerLife, which specifies what will happen to the player instance at the end of the presentation.
-->
<complexType name="descriptorBasePrototype">
<attribute name="id" type="ID" use="optional"/>
</complexType>
<!-- declare global elements in this module -->
<element name="descriptorParam" type="descriptor:descriptorParamPrototype"/>
<element name="descriptor" type="descriptor:descriptorPrototype"/>
<element name="descriptorBase" type="descriptor:descriptorBasePrototype"/>
<!-- declare global attributes in this module -->
<attributeGroup name="descriptorAttrs">
<attribute name="descriptor" type="string" use="optional"/>
</attributeGroup>
</schema>
© ABNT 2007 - Todos los derechos reservados
165
ABNT NBR 15606-2:2007
A.10 Módulo Linking: NCL30Linking.xsd
<!-XML Schema for the NCL modules
This is NCL
Copyright: 2000-2005 PUC-RIO/LABORATORIO TELEMIDIA, All Rights Reserved.
See http://www.telemidia.puc-rio.br
Public URI: http://www.ncl.org.br/NCL3.0/modules/NCL30Linking.xsd
Author: TeleMidia Laboratory
Revision: 19/09/2006
Schema for the NCL Linking module namespace.
-->
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:linking="http://www.ncl.org.br/NCL3.0/Linking"
targetNamespace="http://www.ncl.org.br/NCL3.0/Linking"
elementFormDefault="qualified" attributeFormDefault="unqualified" >
<complexType name="paramPrototype">
<attribute name="name" type="string" use="required"/>
<attribute name="value" type="anySimpleType" use="required"/>
</complexType>
<complexType name="bindPrototype">
<sequence minOccurs="0" maxOccurs="unbounded">
<element ref="linking:bindParam"/>
</sequence>
<attribute name="role" type="string" use="required"/>
<attribute name="component" type="IDREF" use="required"/>
<attribute name="interface" type="string" use="optional"/>
</complexType>
<complexType name="linkPrototype">
<sequence>
<element ref="linking:linkParam" minOccurs="0" maxOccurs="unbounded"/>
<element ref="linking:bind" minOccurs="2" maxOccurs="unbounded"/>
</sequence>
<attribute name="id" type="ID" use="optional"/>
<attribute name="xconnector" type="string" use="required"/>
</complexType>
<!-- declare global elements in this module -->
<element name="linkParam" type="linking:paramPrototype"/>
<element name="bindParam" type="linking:paramPrototype"/>
<element name="bind" type="linking:bindPrototype" />
<element name="link" type="linking:linkPrototype" />
</schema>
166
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
A.11 Módulo ConnectorCommonPart: NCL30ConnectorCommonPart.xsd
<!-XML Schema for the NCL modules
This is NCL
Copyright: 2000-2005 PUC-RIO/LABORATORIO TELEMIDIA, All Rights Reserved.
See http://www.telemidia.puc-rio.br
Public URI: http://www.ncl.org.br/NCL3.0/modules/NCL30ConnectorCommonPart.xsd
Author: TeleMidia Laboratory
Revision: 19/09/2006
Schema for the NCL Connector Common Part module namespace.
-->
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:connectorCommonPart="http://www.ncl.org.br/NCL3.0/ConnectorCommonPart"
targetNamespace="http://www.ncl.org.br/NCL3.0/ConnectorCommonPart"
elementFormDefault="qualified" attributeFormDefault="unqualified" >
<complexType name="parameterPrototype">
<attribute name="name" type="string" use="required"/>
<attribute name="type" type="string" use="optional"/>
</complexType>
<simpleType name="eventPrototype">
<restriction base="string">
<enumeration value="presentation" />
<enumeration value="selection" />
<enumeration value="attribution" />
<enumeration value="composition" />
</restriction>
</simpleType>
<simpleType name="logicalOperatorPrototype">
<restriction base="string">
<enumeration value="and" />
<enumeration value="or" />
</restriction>
</simpleType>
<simpleType name="transitionPrototype">
<restriction base="string">
<enumeration value="starts" />
<enumeration value="stops" />
<enumeration value="pauses" />
<enumeration value="resumes" />
<enumeration value="aborts" />
</restriction>
</simpleType>
</schema>
© ABNT 2007 - Todos los derechos reservados
167
ABNT NBR 15606-2:2007
A.12 Módulo ConnectorAssessmentExpression:
NCL30ConnectorAssessmentExpression.xsd
<!-XML Schema for the NCL modules
This is NCL
Copyright: 2000-2006 PUC-RIO/LABORATORIO TELEMIDIA, All Rights Reserved.
See http://www.telemidia.puc-rio.br
Public URI: http://www.ncl.org.br/NCL3.0/modules/NCL30ConnectorAssessmentExpression.xsd
Author: TeleMidia Laboratory
Revision: 19/09/2006
Schema for the NCL Connector Assessment Expression module namespace.
-->
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:connectorAssessmentExpression="http://www.ncl.org.br/NCL3.0/ConnectorAssessmentExpression"
xmlns:connectorCommonPart="http://www.ncl.org.br/NCL3.0/ConnectorCommonPart"
targetNamespace="http://www.ncl.org.br/NCL3.0/ConnectorAssessmentExpression"
elementFormDefault="qualified" attributeFormDefault="unqualified" >
<!-- import the definitions in the modules namespaces -->
<import namespace="http://www.ncl.org.br/NCL3.0/ConnectorCommonPart"
schemaLocation="http://www.ncl.org.br/NCL3.0/modules/NCL30ConnectorCommonPart.xsd"/>
<simpleType name="comparatorPrototype">
<restriction base="string">
<enumeration value="eq" />
<enumeration value="ne" />
<enumeration value="gt" />
<enumeration value="lt" />
<enumeration value="gte" />
<enumeration value="lte" />
</restriction>
</simpleType>
<simpleType name="attributePrototype">
<restriction base="string">
<enumeration value="repeat" />
<enumeration value="occurrences" />
<enumeration value="state" />
<enumeration value="nodeProperty" />
</restriction>
</simpleType>
<simpleType name="statePrototype">
<restriction base="string">
<enumeration value="sleeping" />
<enumeration value="occurring" />
<enumeration value="paused" />
</restriction>
</simpleType>
<simpleType name="valueUnion">
<union memberTypes="string connectorAssessmentExpression:statePrototype"/>
</simpleType>
<complexType name="assessmentStatementPrototype" >
<sequence>
<element ref="connectorAssessmentExpression:attributeAssessment"/>
<choice>
168
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
<element ref="connectorAssessmentExpression:attributeAssessment"/>
<element ref="connectorAssessmentExpression:valueAssessment"/>
</choice>
</sequence>
<attribute name="comparator" type="connectorAssessmentExpression:comparatorPrototype" use="required"/>
</complexType>
<complexType name="attributeAssessmentPrototype">
<attribute name="role" type="string" use="required"/>
<attribute name="eventType" type="connectorCommonPart:eventPrototype" use="required"/>
<attribute name="key" type="string" use="optional"/>
<attribute name="attributeType" type="connectorAssessmentExpression:attributePrototype" use="optional"/>
<attribute name="offset" type="string" use="optional"/>
</complexType>
<complexType name="valueAssessmentPrototype">
<attribute name="value" type="connectorAssessmentExpression:valueUnion" use="required"/>
</complexType>
<complexType name="compoundStatementPrototype">
<choice minOccurs="1" maxOccurs="unbounded">
<element ref="connectorAssessmentExpression:assessmentStatement" />
<element ref="connectorAssessmentExpression:compoundStatement" />
</choice>
<attribute name="operator" type="connectorCommonPart:logicalOperatorPrototype" use="required"/>
<attribute name="isNegated" type="boolean" use="optional"/>
</complexType>
<!-- declare global elements in this module -->
<element name="assessmentStatement" type="connectorAssessmentExpression:assessmentStatementPrototype" />
<element name="attributeAssessment" type="connectorAssessmentExpression:attributeAssessmentPrototype" />
<element name="valueAssessment" type="connectorAssessmentExpression:valueAssessmentPrototype" />
<element name="compoundStatement" type="connectorAssessmentExpression:compoundStatementPrototype" />
</schema>
© ABNT 2007 - Todos los derechos reservados
169
ABNT NBR 15606-2:2007
A.13 Módulo ConnectorCausalExpression: NCL30ConnectorCausalExpression.xsd
<!-XML Schema for the NCL modules
This is NCL
Copyright: 2000-2006 PUC-RIO/LABORATORIO TELEMIDIA, All Rights Reserved.
See http://www.telemidia.puc-rio.br
Public URI: http://www.ncl.org.br/NCL3.0/modules/NCL30ConnectorCausalExpression.xsd
Author: TeleMidia Laboratory
Revision: 19/09/2006
Schema for the NCL Connector Causal Expression module namespace.
-->
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:connectorCausalExpression="http://www.ncl.org.br/NCL3.0/ConnectorCausalExpression"
xmlns:connectorCommonPart="http://www.ncl.org.br/NCL3.0/ConnectorCommonPart"
targetNamespace="http://www.ncl.org.br/NCL3.0/ConnectorCausalExpression"
elementFormDefault="qualified" attributeFormDefault="unqualified" >
<!-- import the definitions in the modules namespaces -->
<import namespace="http://www.ncl.org.br/NCL3.0/ConnectorCommonPart"
schemaLocation="http://www.ncl.org.br/NCL3.0/modules/NCL30ConnectorCommonPart.xsd"/>
<simpleType name="conditionRoleUnion">
<union memberTypes="string connectorCausalExpression:conditionRolePrototype"/>
</simpleType>
<simpleType name="conditionRolePrototype">
<restriction base="string">
<enumeration value="onBegin" />
<enumeration value="onEnd" />
<enumeration value="onPause" />
<enumeration value="onResume" />
<enumeration value="onAbort" />
</restriction>
</simpleType>
<simpleType name="maxUnion">
<union memberTypes="positiveInteger connectorCausalExpression:unboundedString"/>
</simpleType>
<simpleType name="unboundedString">
<restriction base="string">
<pattern value="unbounded"/>
</restriction>
</simpleType>
<complexType name="simpleConditionPrototype">
<attribute name="role" type="connectorCausalExpression:conditionRoleUnion" use="required"/>
<attribute name="eventType" type="connectorCommonPart:eventPrototype" use="optional"/>
<attribute name="key" type="string" use="optional"/>
<attribute name="transition" type="connectorCommonPart:transitionPrototype" use="optional"/>
<attribute name="delay" type="string" use="optional"/>
<attribute name="min" type="positiveInteger" use="optional"/>
<attribute name="max" type="connectorCausalExpression:maxUnion" use="optional"/>
<attribute name="qualifier" type="connectorCommonPart:logicalOperatorPrototype" use="optional"/>
</complexType>
<complexType name="compoundConditionPrototype">
<attribute name="operator" type="connectorCommonPart:logicalOperatorPrototype" use="required"/>
<attribute name="delay" type="string" use="optional"/>
170
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
</complexType>
<simpleType name="actionRoleUnion">
<union memberTypes="string connectorCausalExpression:actionNamePrototype"/>
</simpleType>
<simpleType name="actionNamePrototype">
<restriction base="string">
<enumeration value="start" />
<enumeration value="stop" />
<enumeration value="pause" />
<enumeration value="resume" />
<enumeration value="abort" />
<enumeration value="set" />
</restriction>
</simpleType>
<simpleType name="actionOperatorPrototype">
<restriction base="string">
<enumeration value="par" />
<enumeration value="seq" />
</restriction>
</simpleType>
<complexType name="simpleActionPrototype">
<attribute name="role" type="connectorCausalExpression:actionRoleUnion" use="required"/>
<attribute name="eventType" type="connectorCommonPart:eventPrototype" use="optional"/>
<attribute name="actionType" type="connectorCausalExpression:actionNamePrototype" use="optional"/>
<attribute name="delay" type="string" use="optional"/>
<attribute name="value" type="string" use="optional"/>
<attribute name="repeat" type="positiveInteger" use="optional"/>
<attribute name="repeatDelay" type="string" use="optional"/>
<attribute name="min" type="positiveInteger" use="optional"/>
<attribute name="max" type="connectorCausalExpression:maxUnion" use="optional"/>
<attribute name="qualifier" type="connectorCausalExpression:actionOperatorPrototype" use="optional"/>
</complexType>
<complexType name="compoundActionPrototype">
<choice minOccurs="2" maxOccurs="unbounded">
<element ref="connectorCausalExpression:simpleAction" />
<element ref="connectorCausalExpression:compoundAction" />
</choice>
<attribute name="operator" type="connectorCausalExpression:actionOperatorPrototype" use="required"/>
<attribute name="delay" type="string" use="optional"/>
</complexType>
<!-- declare global elements in this module -->
<element name="simpleCondition" type="connectorCausalExpression:simpleConditionPrototype" />
<element name="compoundCondition" type="connectorCausalExpression:compoundConditionPrototype" />
<element name="simpleAction" type="connectorCausalExpression:simpleActionPrototype" />
<element name="compoundAction" type="connectorCausalExpression:compoundActionPrototype" />
</schema>
© ABNT 2007 - Todos los derechos reservados
171
ABNT NBR 15606-2:2007
A.14 Módulo CausalConnector: NCL30CausalConnector.xsd
<!-XML Schema for the NCL modules
This is NCL
Copyright: 2000-2006 PUC-RIO/LABORATORIO TELEMIDIA, All Rights Reserved.
See http://www.telemidia.puc-rio.br
Public URI: http://www.ncl.org.br/NCL3.0/modules/NCL30CausalConnector.xsd
Author: TeleMidia Laboratory
Revision: 19/09/2006
Schema for the NCL Causal Connector module namespace.
-->
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:causalConnector="http://www.ncl.org.br/NCL3.0/CausalConnector"
targetNamespace="http://www.ncl.org.br/NCL3.0/CausalConnector"
elementFormDefault="qualified" attributeFormDefault="unqualified" >
<complexType name="causalConnectorPrototype">
<attribute name="id" type="ID" use="required"/>
</complexType>
<!-- declare global elements in this module -->
<element name="causalConnector" type="causalConnector:causalConnectorPrototype"/>
</schema>
172
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
A.15 Módulo ConnectorBase: NCL30ConnectorBase.xsd
<!-XML Schema for the NCL modules
This is NCL
Copyright: 2000-2006 PUC-RIO/LABORATORIO TELEMIDIA, All Rights Reserved.
See http://www.telemidia.puc-rio.br
Public URI: http://www.ncl.org.br/NCL3.0/modules/NCL30ConnectorBase.xsd
Author: TeleMidia Laboratory
Revision: 19/09/2006
Schema for the NCL Connector Base module namespace.
-->
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:connectorBase="http://www.ncl.org.br/NCL3.0/ConnectorBase"
targetNamespace="http://www.ncl.org.br/NCL3.0/ConnectorBase"
elementFormDefault="qualified" attributeFormDefault="unqualified" >
<complexType name="connectorBasePrototype">
<attribute name="id" type="ID" use="optional"/>
</complexType>
<!-- declare global elements in this module -->
<element name="connectorBase" type="connectorBase:connectorBasePrototype"/>
</schema>
© ABNT 2007 - Todos los derechos reservados
173
ABNT NBR 15606-2:2007
A.16 NCL30CausalConnectorFunctionality.xsd
<!-XML Schema for the NCL modules
This is NCL
Copyright: 2000-2005 LABORATORIO TELEMIDIA, All Rights Reserved.
See http://www.telemidia.puc-rio.br
Public URI: http://www.ncl.org.br/NCL3.0/modules/
NCL30CausalConnectorFunctionality.xsd
Author: TeleMidia Laboratory
Revision: 19/09/2006
Schema for the NCL CausalConnectorFunctionality module namespace.
-->
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:connectorCommonPart="http://www.ncl.org.br/NCL3.0/
ConnectorCommonPart"
xmlns:connectorAssessmentExpression="http://www.ncl.org.br/NCL3.0/
ConnectorAssessmentExpression"
xmlns:connectorCausalExpression="http://www.ncl.org.br/NCL3.0/
ConnectorCausalExpression"
xmlns:causalConnector="http://www.ncl.org.br/NCL3.0/
CausalConnector"
xmlns:causalConnectorFunctionality="http://www.ncl.org.br/NCL3.0/
CausalConnectorFunctionality"
targetNamespace="http://www.ncl.org.br/NCL3.0/
CausalConnectorFunctionality"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<!-- import the definitions in the modules namespaces -->
<import namespace="http://www.ncl.org.br/NCL3.0/ConnectorCommonPart"
schemaLocation="http://www.ncl.org.br/NCL3.0/modules/
NCL30ConnectorCommonPart.xsd"/>
<import namespace="http://www.ncl.org.br/NCL3.0/ConnectorAssessmentExpression"
schemaLocation="http://www.ncl.org.br/NCL3.0/modules/
NCL30ConnectorAssessmentExpression.xsd"/>
<import namespace="http://www.ncl.org.br/NCL3.0/ConnectorCausalExpression"
schemaLocation="http://www.ncl.org.br/NCL3.0/modules/
NCL30ConnectorCausalExpression.xsd"/>
<import namespace="http://www.ncl.org.br/NCL3.0/CausalConnector"
schemaLocation="http://www.ncl.org.br/NCL3.0/modules/
NCL30CausalConnector.xsd"/>
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<!-- CausalConnectorFunctionality
-->
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<element name="connectorParam" type="connectorCommonPart:parameterPrototype"/>
<!-- extends causalConnector element -->
<complexType name="causalConnectorType">
<complexContent>
<extension base="causalConnector:causalConnectorPrototype">
<sequence>
<element ref="causalConnectorFunctionality:connectorParam" minOccurs="0" maxOccurs="unbounded"/>
<choice>
<element ref="causalConnectorFunctionality:simpleCondition" />
<element ref="causalConnectorFunctionality:compoundCondition" />
</choice>
174
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
<choice>
<element ref="causalConnectorFunctionality:simpleAction" />
<element ref="causalConnectorFunctionality:compoundAction" />
</choice>
</sequence>
</extension>
</complexContent>
</complexType>
<!-- extends compoundCondition element -->
<complexType name="compoundConditionType">
<complexContent>
<extension base="connectorCausalExpression:compoundConditionPrototype">
<sequence>
<choice>
<element ref="causalConnectorFunctionality:simpleCondition" />
<element ref="causalConnectorFunctionality:compoundCondition" />
</choice>
<choice minOccurs="1" maxOccurs="unbounded">
<element ref="causalConnectorFunctionality:simpleCondition" />
<element ref="causalConnectorFunctionality:compoundCondition" />
<element ref="causalConnectorFunctionality:assessmentStatement" />
<element ref="causalConnectorFunctionality:compoundStatement" />
</choice>
</sequence>
</extension>
</complexContent>
</complexType>
<element name="causalConnector" type="causalConnectorFunctionality:causalConnectorType"
substitutionGroup="causalConnector:causalConnector"/>
<element name="simpleCondition" substitutionGroup="connectorCausalExpression:simpleCondition"/>
<element name="compoundCondition" type="causalConnectorFunctionality:compoundConditionType"
substitutionGroup="connectorCausalExpression:compoundCondition"/>
<element name="simpleAction" substitutionGroup="connectorCausalExpression:simpleAction"/>
<element name="compoundAction" substitutionGroup="connectorCausalExpression:compoundAction"/>
<element name="assessmentStatement" substitutionGroup="connectorAssessmentExpression:assessmentStatement"/>
<element name="attributeAssessment" substitutionGroup="connectorAssessmentExpression:attributeAssessment"/>
<element name="valueAssessment" substitutionGroup="connectorAssessmentExpression:valueAssessment"/>
<element name="compoundStatement" substitutionGroup="connectorAssessmentExpression:compoundStatement"/>
</schema>
© ABNT 2007 - Todos los derechos reservados
175
ABNT NBR 15606-2:2007
A.17 Módulo TestRule: NCL30TestRule.xsd
<!-XML Schema for the NCL modules
This is NCL
Copyright: 2000-2005 PUC-RIO/LABORATORIO TELEMIDIA, All Rights Reserved.
See http://www.telemidia.puc-rio.br
Public URI: http://www.ncl.org.br/NCL3.0/modules/NCL30TestRule.xsd
Author: TeleMidia Laboratory
Revision: 19/09/2006
Schema for the NCL TestRule module namespace.
-->
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:testRule="http://www.ncl.org.br/NCL3.0/TestRule"
targetNamespace="http://www.ncl.org.br/NCL3.0/TestRule"
elementFormDefault="qualified" attributeFormDefault="unqualified" >
<complexType name="rulePrototype">
<attribute name="id" type="ID" use="required"/>
<attribute name="var" type="string" use="required"/>
<attribute name="value" type="string" use="required"/>
<attribute name="comparator" use="required">
<simpleType>
<restriction base="string">
<enumeration value="eq"/>
<enumeration value="ne"/>
<enumeration value="gt"/>
<enumeration value="gte"/>
<enumeration value="lt"/>
<enumeration value="lte"/>
</restriction>
</simpleType>
</attribute>
</complexType>
<complexType name="compositeRulePrototype">
<choice minOccurs="2" maxOccurs="unbounded">
<element ref="testRule:rule"/>
<element ref="testRule:compositeRule"/>
</choice>
<attribute name="id" type="ID" use="required"/>
<attribute name="operator" use="required">
<simpleType>
<restriction base="string">
<enumeration value="and"/>
<enumeration value="or"/>
</restriction>
</simpleType>
</attribute>
</complexType>
<complexType name="ruleBasePrototype">
<attribute name="id" type="ID" use="optional"/>
</complexType>
<!-- declare global elements in this module -->
<element name="rule" type="testRule:rulePrototype"/>
<element name="compositeRule" type="testRule:compositeRulePrototype"/>
<element name="ruleBase" type="testRule:ruleBasePrototype"/>
</schema>
176
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
A.18 Módulo TestRuleUse: NCL30TestRuleUse.xsd
<!-XML Schema for the NCL modules
This is NCL
Copyright: 2000-2005 PUC-RIO/LABORATORIO TELEMIDIA, All Rights Reserved.
See http://www.telemidia.puc-rio.br
Public URI: http://www.ncl.org.br/NCL3.0/modules/NCL30TestRuleUse.xsd
Author: TeleMidia Laboratory
Revision: 19/09/2006
Schema for the NCL TestRuleUse module namespace.
-->
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:testRule="http://www.ncl.org.br/NCL3.0/TestRuleUse"
targetNamespace="http://www.ncl.org.br/NCL3.0/TestRuleUse"
elementFormDefault="qualified" attributeFormDefault="unqualified" >
<complexType name="bindRulePrototype">
<attribute name="constituent" type="IDREF" use="required" />
<attribute name="rule" type="string" use="required" />
</complexType>
<!-- declare global elements in this module -->
<element name="bindRule" type="testRule:bindRulePrototype"/>
</schema>
© ABNT 2007 - Todos los derechos reservados
177
ABNT NBR 15606-2:2007
A.19 Módulo ContentControl: NCL30ContentControl.xsd
<!-XML Schema for the NCL modules
This is NCL
Copyright: 2000-2005 LABORATORIO TELEMIDIA, All Rights Reserved.
See http://www.telemidia.puc-rio.br
Public URI: http://www.ncl.org.br/NCL3.0/modules/NCL30ContentControl.xsd
Author: TeleMidia Laboratory
Revision: 19/09/2006
Schema for the NCL ContentControl module namespace.
-->
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:contentControl="http://www.ncl.org.br/NCL3.0/ContentControl"
targetNamespace="http://www.ncl.org.br/NCL3.0/ContentControl"
elementFormDefault="qualified" attributeFormDefault="unqualified" >
<complexType name="defaultComponentPrototype">
<attribute name="component" type="IDREF" use="required" />
</complexType>
<!-- define the switch element prototype -->
<complexType name="switchPrototype">
<choice>
<element ref="contentControl:defaultComponent" minOccurs="0" maxOccurs="1"/>
</choice>
<attribute name="id" type="ID" use="required"/>
</complexType>
<!-- declare global elements in this module -->
<element name="defaultComponent" type="contentControl:defaultComponentPrototype"/>
<element name="switch" type="contentControl:switchPrototype"/>
</schema>
178
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
A.20 Módulo DescriptorControl: NCL30DescriptorControl.xsd
<!-XML Schema for the NCL modules
This is NCL
Copyright: 2000-2005 LABORATORIO TELEMIDIA, All Rights Reserved.
See http://www.telemidia.puc-rio.br
Public URI: http://www.ncl.org.br/NCL3.0/modules/NCL30DescriptorControl.xsd
Author: TeleMidia Laboratory
Revision: 19/06/2006
Schema for the NCL DescriptorControl module namespace.
-->
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:descriptorControl="http://www.ncl.org.br/NCL3.0/DescriptorControl"
targetNamespace="http://www.ncl.org.br/NCL3.0/DescriptorControl"
elementFormDefault="qualified" attributeFormDefault="unqualified" >
<complexType name="defaultDescriptorPrototype">
<attribute name="descriptor" type="IDREF" use="required" />
</complexType>
<!-- define the descriptor switch element prototype -->
<complexType name="descriptorSwitchPrototype">
<choice>
<element ref="descriptorControl:defaultDescriptor" minOccurs="0" maxOccurs="1"/>
</choice>
<attribute name="id" type="ID" use="required”/>
</complexType>
<!-- declare global elements in this module -->
<element name="defaultDescriptor" type="descriptorControl:defaultDescriptorPrototype"/>
<element name="descriptorSwitch" type="descriptorControl:descriptorSwitchPrototype"/>
</schema>
© ABNT 2007 - Todos los derechos reservados
179
ABNT NBR 15606-2:2007
A.21 Módulo Timing: NCL30Timing.xsd
<!-XML Schema for the NCL modules
This is NCL
Copyright: 2000-2005 PUC-RIO/LABORATORIO TELEMIDIA, All Rights Reserved.
See http://www.telemidia.puc-rio.br
Public URI: http://www.ncl.org.br/NCL3.0/modules/NCL30Timing.xsd
Author: TeleMidia Laboratory
Revision: 19/09/2006
Schema for the NCL Timing module namespace.
-->
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:timing="http://www.ncl.org.br/NCL3.0/Timing"
targetNamespace="http://www.ncl.org.br/NCL3.0/Timing"
elementFormDefault="qualified" attributeFormDefault="unqualified" >
<!-- declare global attributes in this module -->
<!-- define the explicitDur attribute group -->
<attributeGroup name="explicitDurAttrs">
<attribute name="explicitDur" type="string" use="optional"/>
</attributeGroup>
<!-- define the freeze attribute group -->
<attributeGroup name="freezeAttrs">
<attribute name="freeze" type="boolean" use="optional"/>
</attributeGroup>
</schema>
180
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
A.22 Módulo Import: NCL30Import.xsd
<!-XML Schema for the NCL modules
This is NCL
Copyright: 2000-2005 PUC-RIO/LABORATORIO TELEMIDIA, All Rights Reserved.
See http://www.telemidia.puc-rio.br
Public URI: http://www.ncl.org.br/NCL3.0/modules/NCL30Import.xsd
Author: TeleMidia Laboratory
Revision: 19/09/2006
Schema for the NCL Import module namespace.
-->
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:import="http://www.ncl.org.br/NCL3.0/Import"
targetNamespace="http://www.ncl.org.br/NCL3.0/Import"
elementFormDefault="qualified" attributeFormDefault="unqualified" >
<complexType name="importBasePrototype">
<attribute name="alias" type="ID" use="required"/>
<attribute name="region" type="IDREF" use="optional"/>
<attribute name="documentURI" type="anyURI" use="required"/>
</complexType>
<complexType name="importNCLPrototype">
<attribute name="alias" type="ID" use="required"/>
<attribute name="documentURI" type="anyURI" use="required"/>
</complexType>
<complexType name="importedDocumentBasePrototype">
<sequence minOccurs="1" maxOccurs="unbounded">
<element ref="import:importNCL" />
</sequence>
<attribute name="id" type="ID" use="optional" />
</complexType>
<!-- declare global elements in this module -->
<element name="importBase" type="import:importBasePrototype"/>
<element name="importNCL" type="import:importNCLPrototype"/>
<element name="importedDocumentBase" type="import:importedDocumentBasePrototype"/>
</schema>
© ABNT 2007 - Todos los derechos reservados
181
ABNT NBR 15606-2:2007
A.23 Módulo EntityReuse: NCL30EntityReuse.xsd
<!-XML Schema for the NCL modules
This is NCL
Copyright: 2000-2005 PUC-RIO/LABORATORIO TELEMIDIA, All Rights Reserved.
See http://www.telemidia.puc-rio.br
Public URI: http://www.ncl.org.br/NCL3.0/modules/NCL30EntityReuse.xsd
Author: TeleMidia Laboratory
Revision: 19/09/2006
Schema for the NCL EntityReuse module namespace.
-->
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:entityReuse="http://www.ncl.org.br/NCL3.0/EntityReuse"
targetNamespace="http://www.ncl.org.br/NCL3.0/EntityReuse"
elementFormDefault="qualified" attributeFormDefault="unqualified" >
<attributeGroup name="entityReuseAttrs">
<attribute name="refer" type="string" use="optional"/>
</attributeGroup>
</schema>
182
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
A.24 Módulo ExtendedEntityReuse: NCL30ExtendedEntityReuse.xsd
<!-XML Schema for the NCL modules
This is NCL
Copyright: 2000-2005 PUC-RIO/LABORATORIO TELEMIDIA, All Rights Reserved.
See http://www.telemidia.puc-rio.br
Public URI: http://www.ncl.org.br/NCL3.0/modules/NCL30ExtendedEntityReuse.xsd
Author: TeleMidia Laboratory
Revision: 19/09/2006
Schema for the NCL ExtendedEntityReuse module namespace.
-->
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:extendedEntityReuse="http://www.ncl.org.br/NCL3.0/ExtendedEntityReuse"
targetNamespace="http://www.ncl.org.br/NCL3.0/ExtendedEntityReuse"
elementFormDefault="qualified" attributeFormDefault="unqualified" >
<attributeGroup name="extendedEntityReuseAttrs">
<attribute name="instance" type="string" use="optional"/>
</attributeGroup>
</schema>
© ABNT 2007 - Todos los derechos reservados
183
ABNT NBR 15606-2:2007
A.25 Módulo KeyNavigation: NCL30KeyNavigation.xsd
<!-XML Schema for the NCL modules
This is NCL
Copyright: 2000-2005 PUC-RIO/LABORATORIO TELEMIDIA, All Rights Reserved.
See http://www.telemidia.puc-rio.br
Public URI: http://www.ncl.org.br/NCL3.0/modules/NCL30KeyNavigation.xsd
Author: TeleMidia Laboratory
Revision: 19/09/2006
Schema for the NCL KeyNavigation module namespace.
-->
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:keyNavigation="http://www.ncl.org.br/NCL3.0/KeyNavigation"
targetNamespace="http://www.ncl.org.br/NCL3.0/KeyNavigation"
elementFormDefault="qualified" attributeFormDefault="unqualified" >
<simpleType name="colorPrototype">
<restriction base="string">
<enumeration value="white" />
<enumeration value="black" />
<enumeration value="silver" />
<enumeration value="gray" />
<enumeration value="red" />
<enumeration value="maroon" />
<enumeration value="fuchsia" />
<enumeration value="purple" />
<enumeration value="lime" />
<enumeration value="green" />
<enumeration value="yellow" />
<enumeration value="olive" />
<enumeration value="blue" />
<enumeration value="navy" />
<enumeration value="aqua" />
<enumeration value="teal" />
</restriction>
</simpleType>
<!-- declare global attributes in this module -->
<!-- define the keyNavigation attribute group -->
<attributeGroup name="keyNavigationAttrs">
<attribute name="moveLeft" type="positiveInteger" use="optional"/>
<attribute name="moveRight" type="positiveInteger" use="optional"/>
<attribute name="moveUp" type="positiveInteger" use="optional"/>
<attribute name="moveDown" type="positiveInteger" use="optional"/>
<attribute name="focusIndex" type="positiveInteger" use="optional"/>
<attribute name="focusBorderColor" type="keyNavigation:colorPrototype" use="optional"/>
<attribute name="focusBorderWidth" type="string" use="optional"/>
<attribute name="focusBorderTransparency" type="string" use="optional"/>
<attribute name="focusScr" type="string" use="optional"/>
<attribute name="focusSelScr" type="string" use="optional"/>
<attribute name="selBorderColor" type="keyNavigation:colorPrototype" use="optional"/>
</attributeGroup>
</schema>
184
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
A.26 Módulo TransitionBase: NCL30TransitionBase.xsd
<!-XML Schema for the NCL modules
This is NCL
Copyright: 2000-2006 PUC-RIO/LABORATORIO TELEMIDIA, All Rights Reserved.
See http://www.telemidia.puc-rio.br
Public URI: http://www.ncl.org.br/NCL3.0/modules/NCL30TransitionBase.xsd
Author: TeleMidia Laboratory
Revision: 19/09/2006
Schema for the NCL Transition Base module namespace.
-->
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:transitionBase="http://www.ncl.org.br/NCL3.0/TransitionBase"
targetNamespace="http://www.ncl.org.br/NCL3.0/TransitionBase"
elementFormDefault="qualified" attributeFormDefault="unqualified" >
<complexType name="transitionBasePrototype">
<attribute name="id" type="ID" use="optional"/>
</complexType>
<!-- declare global elements in this module -->
<element name="transitionBase" type="transitionBase:transitionBasePrototype"/>
</schema>
© ABNT 2007 - Todos los derechos reservados
185
ABNT NBR 15606-2:2007
A.27 Módulo Animation: NCL30Animation.xsd
<!-XML Schema for the NCL modules
This is NCL
Copyright: 2000-2005 PUC-RIO/LABORATORIO TELEMIDIA, All Rights Reserved.
See http://www.telemidia.puc-rio.br
Public URI: http://www.ncl.org.br/NCL3.0/modules/NCL30Animation.xsd
Author: TeleMidia Laboratory
Revision: 19/09/2006
Schema for the NCL Timing module namespace.
-->
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:animation="http://www.ncl.org.br/NCL3.0/Animation"
targetNamespace="http://www.ncl.org.br/NCL3.0/Animation"
elementFormDefault="qualified" attributeFormDefault="unqualified" >
<!-- declare global attributes in this module -->
<!-- define the animation attribute group -->
<attributeGroup name="animationAttrs">
<attribute name="duration" type="string" use="optional"/>
<attribute name="by" type="string" use="optional"/>
</attributeGroup>
</schema>
A.28 Transition module: NCL30Transition.xsd
<!-XML Schema for the NCL modules
This is NCL
Copyright: 2000-2006 PUC-RIO/LABORATORIO TELEMIDIA, All Rights Reserved.
See http://www.telemidia.puc-rio.br
Public URI: http://www.ncl.org.br/NCL3.0/modules/NCL30Transition.xsd
Author: TeleMidia Laboratory
Revision: 19/09/2006
Schema for the NCL Transition module namespace.
-->
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:transition="http://www.ncl.org.br/NCL3.0/Transition"
targetNamespace="http://www.ncl.org.br/NCL3.0/Transition"
elementFormDefault="qualified" attributeFormDefault="unqualified" >
<!-- declare global attributes in this module -->
<!-- define the type attribute prototype -->
<simpleType name="typePrototype">
<restriction base="string">
<enumeration value="in"/>
<enumeration value="barWipe"/>
186
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
<enumeration value="boxWipe"/>
<enumeration value="fourBoxWipe"/>
<enumeration value="barnDoorWipe"/>
<enumeration value="diagonalWipe"/>
<enumeration value="bowTieWipe"/>
<enumeration value="miscDiagonalWipe"/>
<enumeration value="veeWipe"/>
<enumeration value="barnVeeWipe"/>
<enumeration value="zigZagWipe"/>
<enumeration value="barnZigZagWipe"/>
<enumeration value="irisWipe"/>
<enumeration value="triangleWipe"/>
<enumeration value="arrowHeadWipe"/>
<enumeration value="pentagonWipe"/>
<enumeration value="hexagonWipe"/>
<enumeration value="ellipseWipe"/>
<enumeration value="eyeWipe"/>
<enumeration value="roundRectWipe"/>
<enumeration value="starWipe"/>
<enumeration value="miscShapeWipe"/>
<enumeration value="clockWipe"/>
<enumeration value="pinWheelWipe"/>
<enumeration value="singleSweepWipe"/>
<enumeration value="fanWipe"/>
<enumeration value="doubleFanWipe"/>
<enumeration value="doubleSweepWipe"/>
<enumeration value="saloonDoorWipe"/>
<enumeration value="windshieldWipe"/>
<enumeration value="snakeWipe"/>
<enumeration value="spiralWipe"/>
<enumeration value="parallelSnakesWipe"/>
<enumeration value="boxSnakesWipe"/>
<enumeration value="waterfallWipe"/>
<enumeration value="pushWipe"/>
<enumeration value="slideWipe"/>
<enumeration value="fade"/>
<enumeration value="audioFade"/>
<enumeration value="audioVisualFade"/>
</restriction>
</simpleType>
<!-- define subType attribute prototype-->
<simpleType name="subTypePrototype">
<restriction base="string">
<enumeration value="bottom"/>
<enumeration value="bottomCenter"/>
<enumeration value="bottomLeft"/>
<enumeration value="bottomLeftClockwise"/>
<enumeration value="bottomLeftCounterClockwise"/>
<enumeration value="bottomLeftDiagonal"/>
<enumeration value="bottomRight"/>
<enumeration value="bottomRightClockwise"/>
<enumeration value="bottomRightCounterClockwise"/>
<enumeration value="bottomRightDiagonal"/>
<enumeration value="centerRight"/>
<enumeration value="centerTop"/>
<enumeration value="circle"/>
<enumeration value="clockwiseBottom"/>
<enumeration value="clockwiseBottomRight"/>
© ABNT 2007 - Todos los derechos reservados
187
ABNT NBR 15606-2:2007
<enumeration value="clockwiseLeft"/>
<enumeration value="clockwiseNine"/>
<enumeration value="clockwiseRight"/>
<enumeration value="clockwiseSix"/>
<enumeration value="clockwiseThree"/>
<enumeration value="clockwiseTop"/>
<enumeration value="clockwiseTopLeft"/>
<enumeration value="clockwiseTwelve"/>
<enumeration value="cornersIn"/>
<enumeration value="cornersOut"/>
<enumeration value="counterClockwiseBottomLeft"/>
<enumeration value="counterClockwiseTopRight"/>
<enumeration value="crossfade"/>
<enumeration value="diagonalBottomLeft"/>
<enumeration value="diagonalBottomLeftOpposite"/>
<enumeration value="diagonalTopLeft"/>
<enumeration value="diagonalTopLeftOpposite"/>
<enumeration value="diamond"/>
<enumeration value="doubleBarnDoor"/>
<enumeration value="doubleDiamond"/>
<enumeration value="down"/>
<enumeration value="fadeFromColor"/>
<enumeration value="fadeToColor"/>
<enumeration value="fanInHorizontal"/>
<enumeration value="fanInVertical"/>
<enumeration value="fanOutHorizontal"/>
<enumeration value="fanOutVertical"/>
<enumeration value="fivePoint"/>
<enumeration value="fourBlade"/>
<enumeration value="fourBoxHorizontal"/>
<enumeration value="fourBoxVertical"/>
<enumeration value="fourPoint"/>
<enumeration value="fromBottom"/>
<enumeration value="fromLeft"/>
<enumeration value="fromRight"/>
<enumeration value="fromTop"/>
<enumeration value="heart"/>
<enumeration value="horizontal"/>
<enumeration value="horizontalLeft"/>
<enumeration value="horizontalLeftSame"/>
<enumeration value="horizontalRight"/>
<enumeration value="horizontalRightSame"/>
<enumeration value="horizontalTopLeftOpposite"/>
<enumeration value="horizontalTopRightOpposite"/>
<enumeration value="keyhole"/>
<enumeration value="left"/>
<enumeration value="leftCenter"/>
<enumeration value="leftToRight"/>
<enumeration value="oppositeHorizontal"/>
<enumeration value="oppositeVertical"/>
<enumeration value="parallelDiagonal"/>
<enumeration value="parallelDiagonalBottomLeft"/>
<enumeration value="parallelDiagonalTopLeft"/>
<enumeration value="parallelVertical"/>
<enumeration value="rectangle"/>
<enumeration value="right"/>
<enumeration value="rightCenter"/>
<enumeration value="sixPoint"/>
<enumeration value="top"/>
188
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
<enumeration value="topCenter"/>
<enumeration value="topLeft"/>
<enumeration value="topLeftClockwise"/>
<enumeration value="topLeftCounterClockwise"/>
<enumeration value="topLeftDiagonal"/>
<enumeration value="topLeftHorizontal"/>
<enumeration value="topLeftVertical"/>
<enumeration value="topRight"/>
<enumeration value="topRightClockwise"/>
<enumeration value="topRightCounterClockwise"/>
<enumeration value="topRightDiagonal"/>
<enumeration value="topToBottom"/>
<enumeration value="twoBladeHorizontal"/>
<enumeration value="twoBladeVertical"/>
<enumeration value="twoBoxBottom"/>
<enumeration value="twoBoxLeft"/>
<enumeration value="twoBoxRight"/>
<enumeration value="twoBoxTop"/>
<enumeration value="up"/>
<enumeration value="vertical"/>
<enumeration value="verticalBottomLeftOpposite"/>
<enumeration value="verticalBottomSame"/>
<enumeration value="verticalLeft"/>
<enumeration value="verticalRight"/>
<enumeration value="verticalTopLeftOpposite"/>
<enumeration value="verticalTopSame"/>
</restriction>
</simpleType>
<attributeGroup name="transAttrs">
<attribute name="transIn" type="string" use="optional"/>
<attribute name="transOut" type="string" use="optional"/>
</attributeGroup>
<!-- define the transition attribute group -->
<attributeGroup name="transitionAttrs">
<attribute name="type" type="transition:typePrototype" use="required"/>
<attribute name="subtype" type="transition:subTypePrototype" use="optional"/>
<attribute name="fadecolor" type="string" use="optional" default="black"/>
<attribute name="dur" type="string" use="optional"/>
<attribute name="startProgress" use="optional" default="0.0">
<simpleType>
<restriction base="decimal">
<minInclusive value="0.0"/>
<maxInclusive value="1.0"/>
</restriction>
</simpleType>
</attribute>
<attribute name="endProgress" use="optional" default="1.0">
<simpleType>
<restriction base="decimal">
<minInclusive value="0.0"/>
<maxInclusive value="1.0"/>
</restriction>
</simpleType>
</attribute>
<attribute name="direction" use="optional" default="forward">
<simpleType>
<restriction base="string">
© ABNT 2007 - Todos los derechos reservados
189
ABNT NBR 15606-2:2007
<enumeration value="forward"/>
<enumeration value="reverse"/>
</restriction>
</simpleType>
</attribute>
</attributeGroup>
<!-- define the transition-modifier attribute group -->
<attributeGroup name="transitionModifierAttrs">
<attribute name="horzRepeat" type="decimal" use="optional" default="1.0"/>
<attribute name="vertRepeat" type="decimal" use="optional" default="1.0"/>
<attribute name="borderWidth" type="nonNegativeInteger" use="optional" default="0"/>
<attribute name="borderColor" type="string" use="optional" default="black"/>
</attributeGroup>
<complexType name="transitionPrototype">
<attributeGroup ref="transition:transitionAttrs"/>
<attributeGroup ref="transition:transitionModifierAttrs"/>
</complexType>
<!-- declare global element in this module -->
<element name="transition" type="transition:transitionPrototype"/>
</schema>
A.29 Metainformation module: NCL30Metainformation.xsd
<!-XML Schema for the NCL modules
This is NCL
Copyright: 2000-2005 PUC-RIO/LABORATORIO TELEMIDIA, All Rights Reserved.
See http://www.telemidia.puc-rio.br
Public URI: http://www.ncl.org.br/NCL3.0/modules/NCL30Metainformation.xsd
Author: TeleMidia Laboratory
Revision: 19/09/2006
Schema for the NCL Metainformation module namespace.
-->
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:metainformation="http://www.ncl.org.br/NCL3.0/Metainformation"
targetNamespace="http://www.ncl.org.br/NCL3.0/Metainformation"
elementFormDefault="qualified" attributeFormDefault="unqualified" >
<complexType name="metaPrototype">
<attribute name="name" type="string" use="required"/>
<attribute name="content" type="string" use="required"/>
</complexType>
<complexType name="metadataPrototype">
<sequence>
<any minOccurs="0"/>
</sequence>
</complexType>
190
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
<!-- declare global elements in this module -->
<element name="meta" type="metainformation:metaPrototype"/>
<!-- declare global elements in this module -->
<element name="metadata" type="metainformation:metadataPrototype"/>
</schema>
© ABNT 2007 - Todos los derechos reservados
191
ABNT NBR 15606-2:2007
Anexo B
(informativo)
Manual de referencia de Lua 5.1
B.1 Introducción
NOTA
Este Anexo presenta la especificación del lenguaje de programación Lua, versión 5.1. Este contenido es una
traducción del libro de Roberto Ierusalimschy, Luiz Henrique de Figueiredo y Waldemar Celes, Lua 5.1 Reference Manual
(Lua.org, agosto de 2006. ISBN 85-903798-3-3) y se imprime nuevamente aquí con aprobación de los autores. El libro también
está disponible en línea, en inglés, en <http://www.lua.org/manual/5.1/>.
Lua es un lenguaje de programación de extensión proyectada para dar soporte a la programación procedural en
general y que ofrece facilidades para la descripción de datos. El lenguaje también ofrece un buen soporte para
programación orientada a objetos, programación funcional y programación orientada a datos. Lua fue planeada
para ser utilizada por cualquier aplicación que necesite un lenguaje de script ligero y poderoso. Lua es
implementada como una biblioteca, grabación en C limpio (es decir, en el subconjunto común de ANSI C y C++).
Por ser un lenguaje de extensión, Lua no posee la noción de un programa principal: éste solamente funciona
incorporado en un programa cliente anfitrión, llamado programa hospedero o simplemente hospedero. Ese
programa hospedero puede invocar funciones para ejecutar un pedazo de código Lua, puede escribir y leer
variables Lua y puede registrar funciones C para ser llamadas por el código Lua. A través del uso de funciones C,
Lua puede ser extendida para tratar de manera apropiada una amplia variedad de dominios, permitiendo así la
creación de lenguajes de programación personalizados que comparten un núcleo sintáctico. La distribución Lua
incluye un ejemplo de un programa hospedero llamado Lua, el cual usa la biblioteca de Lua para ofrecer un
interpretador de línea de comando Lua completo.
Lua es un software libre y, como es usual, se suministra sin garantías, como se indica en su licencia. La
implementación descrita en esta Norma, así como artículos técnicos sobre Lua, están disponibles en el sitio web
oficial de Lua, www.lua.org.
B.2 El Lenguaje
B.2.1 Notación utilizada
Las construcciones del lenguaje serán explicadas usando la notación BNF extendida usual, en la cual {a} significa
0 o más aes y [a] significa una a opcional. No terminales se muestran como non-terminal, palabras clave se
muestran como kword y otros símbolos terminales se muestran como `=´. La sintaxis completa de Lua está
descrita en B.8.
B.2.2 Convenciones léxicas
En Lua, Nomes (también llamados identificadores) pueden ser cualquier cadena de letras, dígitos y subrayados
que no empiecen con un dígito. Esta definición está de acuerdo con la definición de nombres en la mayoría de los
lenguajes (la definición de letras depende de cuál es el idioma (locale): Cualquier carácter considerado alfabético
por el idioma corriente se puede usar como un identificador). Identificadores se usan para nombrar variables y
campos de tablas.
Las siguientes palabras clave son reservadas y no se pueden utilizar como nombres:
and
end
in
repeat
192
break
false
local
return
do
for
nil
then
else
function
not
true
elseif
if
or
until
while
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
Lua es un lenguaje que diferencia minúsculas de mayúsculas: and es una palabra reservada, pero And y AND
son dos nombres válidos diferentes. Como convención, nombres que empiezan con un subrayado seguido por
letras mayúsculas (tales como _VERSION) son reservados para variables globales internas usadas por Lua.
Las siguientes cadenas denotan otros ítems léxicos:
+
==
(
;
~=
)
:
*
<=
{
,
/
>=
}
.
%
<
[
..
^
>
]
...
Cadenas de caracteres literales pueden ser delimitadas a través del uso de comillas simples o comillas dobles,
y pueden contener las siguientes secuencias de escape en el estilo de C: '\a' (campanilla), '\b' (backspace),
\f' (alimentación de formulario), '\n' (quiebra de línea), '\r' (retorno de carro), '\t' (tabulación horizontal), '\v'
(tabulación vertical), '\\' (barra invertida), '\"' (citación [comilla doble]) y '\'' (apóstrofo [comilla simple]). Además de
ello, una barra invertida seguida por una quiebra de línea real da como resultado una quiebra de línea en la
cadena de caracteres. Un carácter en una cadena de caracteres también se puede especificar por su valor
numérico usando la secuencia de escape \ddd, donde ddd es una secuencia de hasta tres dígitos decimales.
Si un carácter numérico representado como una secuencia de escape es seguido por un dígito, la secuencia de
escape debe poseer exactamente tres dígitos. Cadenas de caracteres en Lua pueden contener cualquier valor de
8 bits, incluyendo ceros dentro de las mismas, los cuales se pueden especificar como '\0'.
Para colocar una comilla doble (simple), una quiebra de línea, una barra invertida o insertar un cero dentro de una
cadena de caracteres literal delimitada por comillas dobles (simple) se debe usar una secuencia de escape.
Cualquier otro carácter se puede insertar directamente dentro de la cadena literal (algunos caracteres de control
pueden causar problemas para el sistema de archivos, pero Lua no tiene ningún problema con relación a ellos).
Cadenas literales largas también pueden ser definidas usando un formato largo delimitado por corchetes largos.
Se definió una apertura de corchete largo de nivel n como un abre corchete seguido por n señales de igual
seguido por otro abre corchete. De esa forma, una apertura de corchete largo de nivel 0 es escrita como [[, una
apertura de corchete largo de nivel 1 es escrita como [=[ y así sucesivamente. Un cierre de corchete largo se
define de manera análoga; por ejemplo, un cierre de corchete largo de nivel 4 se escribe como ]====].
Una cadena de caracteres larga empieza con una apertura de corchete largo de cualquier nivel y termina en el
primer cierre de corchete largo del mismo nivel. Literales expresados de esta forma pueden extenderse por varias
líneas, no interpretan ninguna secuencia de escape e ignoran corchetes largos de cualquier otro nivel.
Estos literales pueden contener cualquier cosa, excepto un cierre de corchete largo de nivel igual al de la apertura.
Por conveniencia, cuando una apertura de corchete largo es inmediatamente seguida por una quiebra de línea,
la quiebra de línea no es incluida en la cadena de caracteres. Como ejemplo, en un sistema usando ASCII
(en el cual ‘a’ se codifica como 97, quiebra de línea se codifica como 10 y '1' se codifica como 49), los cinco
literales siguientes denotan la misma cadena:
a = 'alo\n123"'
a = "alo\n123\""
a = '\97lo\10\04923"'
a = [[alo
123"]]
a = [==[
alo
123"]==]
Una constante numérica puede ser escrita con una parte decimal opcional y con un exponente decimal opcional.
Lua también acepta constantes hexadecimales enteras, a través del uso del código 0x. Ejemplos de constantes
numéricas válidas son:
3
3.0
3.1416
314.16e-2
© ABNT 2007 - Todos los derechos reservados
0.31416E1
0xff
0x56
193
ABNT NBR 15606-2:2007
Un comentario empieza con un guión doble (--) en cualquier lugar, siempre que sea fuera de una cadena de
caracteres. Si el texto inmediatamente después de -- no es una apertura de corchete largo, el comentario es un
comentario corto, el cual se extiende hasta el fin de la línea. En caso contrario, es un comentario largo, que se
extiende hasta el cierre de corchete largo correspondiente. Comentarios largos se usan frecuentemente para
desactivar código temporariamente.
B.2.3 Valores y tipos
B.2.3.1
Tipos básicos
Lua es un lenguaje dinámicamente tipado. Esto significa que variables no poseen tipos; solamente valores
poseen tipos. No existe definición de tipos en el lenguaje. Todos los valores transportan su propio tipo.
Todos los valores en Lua son valores de primera clase. Esto significa que todos los valores pueden ser
almacenados en variables, pasados como argumentos para otras funciones y retornados como resultados.
Existen ocho tipos básicos en Lua: nil, boolean, number, string, function, userdata, thread y table. Nil es el tipo del
valor nil, cuya propiedad principal es ser diferente de cualquier otro valor; generalmente representa la ausencia
de un valor útil. Boolean es el tipo de los valores false y true. Tanto nil como false tornan una condición falsa;
cualquier otro valor torna la condición verdadera. Number representa números reales (punto flotante de precisión
doble). Es fácil construir interpretadores Lua que usen otra representación interna para números, tales como
precisión simple de punto flotante o enteros largos; ver el archivo luaconf.h. El tipo string representa cadenas de
caracteres. En Lua, cadenas de caracteres pueden contener cualquier carácter de 8 bits, incluyendo ceros ('\0')
dentro de la misma (ver B.2.2).
Lua puede llamar (y manejar) funciones escritas en Lua y funciones escritas en C (ver B.2.6.9).
El tipo userdata permite que datos C arbitrarios puedan ser almacenados en variables Lua. Este tipo corresponde
a un bloque de memoria y no tiene operaciones predefinidas en Lua, excepto atribución y prueba de identidad.
Sin embargo, a través del uso de metatables, el programador puede definir operaciones para valores userdata
(ver B.2.9). Valores userdata no pueden ser creados o modificados en Lua, solamente a través de la API C. Esto
garantiza la integridad de los datos que pertenecen al programa hospedero.
El tipo thread representa flujos de ejecución independientes y se utiliza para implementar co-rutinas (ver B.2.12).
No confundir el tipo thread de Lua con procesos ligeros del sistema operativo. Lua da soporte a co-rutinas en
todos los sistemas, incluso en aquéllos que no dan soporte a procesos ligeros.
El tipo table implementa arrays asociativos, es decir, arrays que pueden ser indexados no apenas por números,
sino por cualquier valor (excepto nil). Tablas pueden ser heterogéneas; es decir, pueden contener valores de
todos los tipos (excepto nil). Tablas son el único mecanismo de estructuración de datos en Lua; se pueden usar
para representar arrays comunes, tablas de símbolos, conjuntos, registros, grafos, árboles, etc. Para representar
registros, Lua usa el nombre del campo como un índice. El lenguaje da soporte a esta representación ofreciendo
a.name como un azúcar sintáctico para a["name"]. Existen varias formas convenientes de crear tablas en Lua (ver
B.2.6.8).
De la misma forma que los índices, el valor de un campo de la tabla puede poseer cualquier tipo (excepto nil). En
particular, dado que funciones son valores de primera clase, campos de tabla pueden contener funciones. Por lo
tanto, tablas pueden también poseer métodos (ver B.2.6.10).
Valores del tipo table, function, thread y userdata (completo) son objetos: Variables no contienen realmente estos
valores, solamente referencias a ellos. Atribución, paso de parámetro y retorno de funciones siempre manejan
informes para tales valores; estas operaciones no significan ninguna especie de copia.
La función type retorna una cadena de caracteres describiendo el tipo de un cierto valor.
194
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
B.2.3.2
Coerción
Lua provee conversión automática entre valores del tipo string y del tipo number en tiempo de ejecución.
Cualquier operación aritmética aplicada a una cadena de caracteres intenta convertir esta cadena en un número,
siguiendo las reglas de conversión usuales. De forma análoga, siempre que un número se utiliza donde una
cadena de caracteres es esperada, el número es convertido para una cadena, en un formato razonable. Para un
control completo sobre cómo números son convertidos en cadenas, usar la función format de la biblioteca string
(ver string.format).
B.2.4 Variables
Variables son lugares que se utilizan para almacenar valores.
Existen tres tipos de variables en Lua: Variables globales, variables locales y campos de tablas.
Un nombre simple puede denotar una variable global o una variable local (o un parámetro formal de una función,
que es un caso particular de variable local):
var ::= Nombre
Nombre denota identificadores, como definido en B.2.2.
Se presupone que toda variable es una variable global a menos que sea explícitamente declarada como una
variable local (ver B.2.5.8). Variables locales poseen alcance léxico: Variables locales pueden ser libremente
accedidas por funciones definidas dentro de su alcance (ver B.2.7).
Antes que la variable reciba su primera atribución, su valor es nil.
Corchetes se usan para indexar una tabla:
var ::= expprefijo `[´ exp `]´
La semántica de accesos a variables globales y a campos de tablas puede ser alterada a través del uso de
meta-tablas. Un acceso a una variable indexada t[i] es equivalente a una llamada gettable_event(t,i)
(ver B.2.9 para una descripción completa de la función gettable_event. Esta función no es definida ni puede ser
llamada en Lua. Se utiliza aquí solamente para fines didácticos).
La sintaxis var.Nome es sólo un azúcar sintáctico para var["Nombre"]:
var : := expprefijo `.´ Nombre
Todas las variables globales son mantenidas como campos en tablas Lua comunes, llamadas de tablas de
ambiente o simplemente de ambientes (ver B.2.10). Cada función tiene su propia referencia para un ambiente, de
forma que todas las variables globales dentro de una función se referirán a esta tabla de ambiente. Cuando una
función es creada, hereda el ambiente de la función que la creó. Para obtener la tabla de ambiente de una función
Lua, se debe llamar a getfenv. Para cambiar la tabla de ambiente, se debe llamar a setfenv (la única manera de
tratar el ambiente de funciones C es a través de la biblioteca de depuración; ver B.5.11).
Un acceso a una variable global x es equivalente a _env.x, que a su vez es equivalente a
gettable_event (_env, "x")
donde _env es el ambiente de la función corriente (ver B.2.9 para una descripción completa de la función
gettable_event. Esta función no es definida ni puede ser llamada en Lua. De modo análogo, la variable _env no
es definida en Lua. Fueron usadas aquí solamente para fines didácticos).
© ABNT 2007 - Todos los derechos reservados
195
ABNT NBR 15606-2:2007
B.2.5 Comandos
B.2.5.1
Conceptos básicos
Lua ofrece un conjunto casi convencional de comandos, análogo al conjunto de comandos disponibles en Pascal
o C. Este conjunto incluye atribución, estructuras de control, llamadas de funciones y declaraciones de variables.
B.2.5.2
Trechos
La unidad de ejecución de Lua se llama trecho. Un trecho es simplemente una secuencia de comandos, los cuales
se ejecutan en forma secuencial. Cada comando puede opcionalmente ser seguido por un punto y coma:
trecho ::= {comando [ `;´]}
No existen comandos vacíos y por lo tanto la construcción ';;' no es válida.
Lua trata un trecho como el cuerpo de una función anónima con un número variable de argumentos (ver B.2.6.10).
De esta forma, trechos pueden definir variables locales, recibir argumentos y retornar valores.
Un trecho puede ser almacenado en un archivo o en una cadena de caracteres dentro del programa hospedero.
Cuando un trecho se ejecuta, es primero pre-compilado en instrucciones para una máquina virtual y después el
código compilado es ejecutado por un interpretador para la máquina virtual.
Los trechos también pueden ser pre-compilados en una forma binaria; ver el programa luac para más detalles.
Programas en forma de código fuente y en forma de un archivo fuente ya compilado son intercambiables; Lua
automáticamente determina cual es el tipo del archivo y actúa de conformidad con el mismo.
B.2.5.3
Bloques
Un bloque es una lista de comandos; sintéticamente, un bloque es la misma cosa que un trecho:
bloque : := trecho
Un bloque puede ser explícitamente delimitado para producir un único comando:
comando : := do bloque end
Bloques explícitos son útiles para controlar el alcance de declaraciones de variables. Bloques explícitos son
también usados a veces para agregar un comando return o break en medio de otro bloque (ver B.2.5.5).
B.2.5.4
Atribución
Lua permite atribución múltiple. En virtud de ello, la sintaxis para atribución define una lista de variables del lado
izquierdo y una lista de expresiones del lado derecho. Los elementos en ambos lados son separados por comas:
comando ::= listavar `=´ listaexp
listavar ::= var { `,´ var}
listaexp ::= exp { `,´ exp}
196
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
Expresiones son discutidas en B.2.6.
Antes de que la atribución sea realizada, la lista de valores es ajustada a la longitud de la lista de variables. Si hay
más valores de lo necesario, los valores en exceso se descartan. Si hay menos valores de lo necesario, la lista es
extendida con tantos nil's como sean necesarios. Si la lista de expresiones termina con una llamada de función,
entonces todos los valores retornados por esta llamada entran en la lista de valores, antes de ser realizado el
ajuste (excepto cuando la llamada es delimitada por paréntesis; ver B.2.6).
Un comando de atribución primero evalúa todas sus expresiones y solamente después se realiza la atribución. De
esta forma, el código
i = 3
i, a[ i] = i+1, 20
atribuye 20 a a[3], sin afectar a[4] porque el I en a[i] es evaluado (a 3) antes de recibir el valor 4. De modo
análogo, la línea
x, y = y, x
cambia los valores de x e y.
La semántica de atribuciones para variables globales y campos de tablas puede ser alterada a través del uso de
meta-tablas. Una atribución para una variable indexada t[i] = Val es equivalente a settable_event(t,i,val) (ver B.2.9
para una descripción completa de la función settable_event. Esta función no es definida ni puede ser llamada en
Lua. Fue usada aquí solamente para fines didácticos).
Una atribución a una variable global x = val es equivalente a la atribución _env.x = val, que a su vez es
equivalente a
settable_event(_env, "x", val)
donde _env es el ambiente de la función siendo ejecutada (la variable _env no es definida en Lua. Fue usada
aquí solamente para fines didácticos).
B.2.5.5
Estructuras de control
Las estructuras de control if, while y repeat poseen el significado usual y la sintaxis familiar:
comando : := while exp do bloque end
comando : := repeat bloque until exp
comando ::= if exp then bloque {elseif exp then bloque} [else bloque] end
Lua también posee un comando for, el cual posee dos variaciones (ver B.2.5.6).
La expresión de la condición de una estructura de control puede retornar cualquier valor. Tanto false como nil
son considerados un valor falso. Todos los valores diferentes de nil y false son considerados como verdaderos
(en particular, el número 0 y la cadena de caracteres vacía también son considerados valores verdaderos).
En el lazo repeat–until, el bloque más interno no termina en la palabra clave until, sino solamente después de la
condición. De esta forma, la condición puede hacer referencia a variables locales declaradas dentro del bloque del
lazo.
© ABNT 2007 - Todos los derechos reservados
197
ABNT NBR 15606-2:2007
El comando return se utiliza para retornar valores de una función o de un trecho (que sólo es una función).
Funciones y trechos pueden retornar más de un valor, de modo que la sintaxis para el comando return es
comando : := return [ listaexp]
El comando break se utiliza para terminar la ejecución de un lazo while, repeat o for, saltando para el próximo
comando después del lazo:
comando : := break
Un break termina la ejecución del lazo más interno.
Los comandos return y break solamente pueden ser escritos como el último comando de un bloque. Si es
realmente necesario tener un return o break en medio de un bloque, entonces se puede usar un bloque interno
explícito, como en las expresiones idiomáticas del return end y del break end, pues ahora tanto el return como el
break son los últimos comandos en sus respectivos bloques (internos).
B.2.5.6
Comando for
El comando for posee dos variaciones: una numérica y otra genérica.
El lazo for numérico repite un bloque de código mientras una variable de control varía de acuerdo con una
progresión aritmética. Posee la siguiente sintaxis:
comando ::= for nombre `=´ exp `,´ exp [ `,´ exp] do bloque end
El bloque es repetido para nombre empezando con el valor de la primera exp, hasta que pase el valor de la
segunda exp a través de pasos seguidos, siendo que a cada paso el valor de la tercera exp es sumado a nombre.
De forma más precisa, un comando for como
for v = e1, e2, e3 do block end
es equivalente al código:
do
local var, limit, step = tonumber(e1), tonumber(e2), tonumber(e3)
if not (var and limit and step) then error() end
while (step > 0 and var <= limit) or (step <=0 and var >= limit) do
local v = var
block
var = var + step
end
end
Observar lo siguiente:
 todas las tres expresiones de control son evaluadas una única vez, antes del inicio del lazo. Deben
obligatoriamente producir números;
 var, limit y step son variables invisibles. Los nombres fueron utilizados aquí solamente para fines didácticos;
 si la tercera expresión (el paso) está ausente, entonces se utiliza un paso de tamaño 1;
 es posible usar break para salir de un lazo for;
198
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
 la variable de lazo v es local al lazo; no es posible usar el valor de esta variable después del fin del for o
después del for haber sido interrumpido por el uso de un break. Si es necesario el valor de esta variable,
debe atribuirlo a otra variable antes de interrumpir o salir del lazo.
El comando for genérico funciona utilizando funciones, llamadas repetidoras. A cada repetición, la función
repetidora es llamada para producir un nuevo valor, parando cuando este nuevo valor es nil. El lazo for genérico
posee la siguiente sintaxis:
comando : := For listadenombres in listaexp do bloque end
listadenombres ::= Nombre { `,´ Nombre}
Un comando for como
for var_1, ···, var_n in explist do block end
es equivalente al código:
do
local f, s, var = explist
while true do
local var_1, ···, var_n = f(s, var) var = var _1
if var == nil then break end
block
end
end
Observar lo siguiente:
 explist es evaluada solamente una vez. Sus resultados son una función repetidora, un estado y un valor inicial
para la primera variable repetidora;
 f, s y var son variables invisibles. Los nombres fueron utilizados aquí solamente para fines didácticos;
 es posible usar break para salir de un lazo for;
 las variables de lazo var_i son locales al lazo; no es posible usar los valores de las mismas después de la
terminación de for. Si se necesitan estos valores, deben atribuirse a otras variables antes de interrumpir el
lazo o salir del mismo.
B.2.5.7
Llamadas de función como comandos
Para permitir posibles efectos colaterales, se pueden ejecutar funciones como comandos:
comando ::= llamadadefuncion
En este caso, todos los valores retornados por la función se descartan. Llamadas de función son explicadas en
B.2.6.9.
© ABNT 2007 - Todos los derechos reservados
199
ABNT NBR 15606-2:2007
B.2.5.8
Declaraciones locales
Variables locales pueden ser declaradas en cualquier lugar dentro de un bloque. La declaración puede incluir una
atribución inicial:
comando ::= local listadenombres [`=´ listaexp]
Caso ocurra una atribución inicial, su semántica es la misma de una atribución múltiple (ver B.2.5.4). En caso
contrario, todas las variables son inicializadas con nil.
Un trecho también es un bloque (ver B.2.5.2) y por lo tanto variables locales pueden ser declaradas en un trecho
fuera de cualquier bloque explícito. El alcance de una variable declarada de esta forma se extiende hasta el fin del
trecho.
Las reglas de visibilidad para variables locales son explicadas en B.2.7.
B.2.6 Expresiones
B.2.6.1
Expresiones básicas
Las expresiones básicas en Lua son las siguientes:
exp : := expprefijo
exp ::= nil | false | true
exp : := Numero
exp : := Cadena
exp : := funcion
exp ::= constructortabla
exp ::= `...´
exp : := exp opbin exp
exp : := opunaria exp
expprefixo ::= var | llamadadefuncion | `(´ exp `)´
Números y cadenas literales se explican en B.2.2; variables se explican en B.2.4; definiciones de funciones se
explican en B.6.10; llamadas funciones se explican en B.2.6.9; constructores de tablas se explican en B.2.6.8.
Expresiones vararg, denotadas por tres puntos ('...'), solamente se pueden usar cuando están inmediatamente
dentro de una función que posee un número variable de argumentos; se explican en B.2.6. 10.
Operadores binarios comprenden operadores aritméticos (ver B.2.6.2), operadores relacionales (ver B.2.6.3),
operadores lógicos (ver B.2.6.4) y el operador de concatenación (ver B.2.6.5). Operadores unarios comprenden el
menos unario (ver B.2.6.2), el not unario (ver B.2.6.4) y el operador de tamaño unario (ver B.2.6.6).
Tanto llamadas de funciones como expresiones vararg pueden dar como resultado múltiples valores. Si la
expresión se utiliza como un comando (ver B.2.5.7) (lo que solamente es posible para llamadas de funciones),
entonces su lista de retorno es ajustada para cero elementos, descartando, por tanto, todos los valores
retornados. Si la expresión se utiliza como el último (o el único) elemento de una lista de expresiones, entonces
no se realiza ningún ajuste (a menos que la llamada sea delimitada por paréntesis). En todos los demás contextos,
Lua ajusta la lista de resultados para un elemento, descartando todos los valores excepto el primero.
200
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
Siguen algunos ejemplos:
f()
g(f(), x)
g(x, f())
a,b,c = f(), x
a,b = ...
a,b,c = x, f()
a,b,c = f()
return f()
return ...
return x,y,f()
{f()}
{...}
{f(), nil}
----------------
adjusted to 0 results
f() is adjusted to 1 result
g gets x plus all values returned by f()
f() is adjusted to 1 result (c gets nil)
a gets the first vararg parameter,
b gets the second (both a and b may get nil if
there is no corresponding vararg parameter)
f() is adjusted to 2 results
f() is adjusted to 3 results
returns all values returned by f()
returns all received vararg parameters
returns x, y, and all values returned by f()
creates a list with all values returned by f()
creates a list with all vararg parameters
f() is adjusted to 1 result
Una expresión delimitada por paréntesis siempre da como resultado un único valor. De esa forma, (f(x,y,z)) es
siempre un único valor, aunque f regrese múltiples valores (el valor de (f(x,y,z)) es el primer valor retornado por f,
o nil si f no retorna ningún valor).
B.2.6.2
Operadores aritméticos
Lua provee los operadores aritméticos usuales: Los operadores binarios + (adición), - (substracción), *
(multiplicación), / (división), % (módulo) y ^ (exponenciación); y el operador unario - (negación). Si los operandos
son números o cadenas de caracteres que pueden ser convertidas para números (ver B.2.3.2), entonces todas
las operaciones poseen su significado usual. La exponenciación funciona para cualquier exponente. Por ejemplo,
x^(-0.5) calcula el inverso de la raíz cuadrada de X. Módulo se define como
a % b == a - math.floor(a/b)*b
Es decir, es el resto de una división redondeada en dirección a menos infinito.
B.2.6.3
Operadores relacionales
Los operadores relacionales en Lua son:
==
~=
<
>
<=
>=
Estos operadores siempre tienen como resultado false o true.
La igualdad (==) primero compara el tipo de sus operandos. Si los tipos son diferentes, entonces el resultado es
false. En caso contrario, los valores de los operandos son comparados. Números y cadenas de caracteres son
comparados de manera usual. Objetos (valores del tipo table, userdata, thread y function) son comparados por
referencia: Dos objetos son considerados iguales solamente si son el mismo objeto. Siempre que un nuevo objeto
es creado (un valor con tipo table, userdata, thread o function) este nuevo objeto es diferente a cualquier otro
objeto que existía anteriormente.
Es posible alterar la manera como Lua compara los tipos table y userdata a través del uso del meta-método "eq"
(ver B.2.9).
© ABNT 2007 - Todos los derechos reservados
201
ABNT NBR 15606-2:2007
Las reglas de conversión en B.2.3.2 no se aplican a comparaciones de igualdad. Por lo tanto, "0"==0 es evaluado
como false y t[0] y t["0"] denotan posiciones diferentes en una tabla.
El operador ~= es exactamente la negación de la igualdad (==).
Los operadores de orden trabajan de la siguiente forma. Si ambos argumentos son números, entonces son
comparados como tales. En caso contrario, si ambos argumentos son cadenas de caracteres, entonces sus
valores son comparados de acuerdo con la elección de idioma actual. En caso contrario, Lua intenta llamar el
meta-método "lt" o el meta-método "le" (ver B.2.9).
B.2.6.4
Operadores lógicos
Los operadores lógicos en Lua son and, or y not. Así como las estructuras de control (ver B.2.5.5), todos los
operadores lógicos consideran false y nil como falso y cualquier cosa diferente como verdadero.
El operador de negación not siempre retorna false o true. El operador de conjunción and retorna su primer
argumento si este valor es false o nil; en caso contrario, and retorna su segundo argumento. El operador de
disyunción or retorna su primer argumento si el valor de este es diferente de nil y de false; en caso contrario, or
retorna su segundo argumento. Tanto and como or usan evaluación de cortocircuito; es decir, el segundo
operando es evaluado solamente cuando es necesario. Siguen algunos ejemplos:
10 or 20
10 or error()
nil or "a"
nil and 10
false and error()
false and nil
false or nil
10 and 20
-->
-->
-->
-->
-->
-->
-->
-->
10
10
"a"
nil
false
false
nil
20
En este Norma, --> indica el resultado de la expresión precedente.
B.2.6.5
Concatenación
El operador de concatenación de cadenas de caracteres en Lua es denotado por dos puntos ('..'). Si ambos
operandos son cadenas de caracteres o números, entonces son convertidos en cadenas de caracteres de
acuerdo con las reglas mencionadas en B.2.3.2. En caso contrario, el meta-método "concat" es llamado
(ver B.2.9).
B.2.6.6
El operador de tamaño
El operador de tamaño es denotado por el operador unario #. El tamaño de una cadena de caracteres es su
número de bytes (es decir, el significado usual de tamaño de una cadena cuando cada carácter ocupa un byte).
El tamaño de una tabla t es definido como cualquier índice entero n tal que t[n] no es nil y t[n+1] es nil; además
de ello, si t[1] es nil, n puede ser cero. Para un array común, con todos los valores diferentes de nil yendo de 1
hasta un dato n, su tamaño es exactamente aquél n, el índice de su último valor. Si el array posee "agujeros"
(es decir, valores nil entre otros dos valores diferentes de nil), entonces #t puede ser cualquiera de los índices
que inmediatamente preceda un valor nil (es decir, puede considerar cualquier valor nil como el fin del array).
202
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
B.2.6.7
Precedencia
La precedencia de operadores en Lua sigue la tabla abajo, de la menor prioridad a la mayor:
or
and
<
..
+
*
not
>
<=
>=
~=
/
#
%
- (unary)
==
Como es usual, se pueden usar paréntesis para alterar las precedencias de una expresión. Los operadores de
concatenación ('..') y de exponenciación ('^') son asociativos a la derecha. Todos los demás operadores binarios
son asociativos a la izquierda.
B.2.6.8
Constructores de tablas
Constructores de tablas son expresiones que crean tablas. Siempre que un constructor es evaluado, es creada
una nueva tabla. Constructores se pueden usar para crear tablas vacías o para crear una tabla e inicializar
algunos de sus campos. La sintaxis general de constructores es
constructortabla ::= `{´ [listadecampos] `}´
listadecampos : := campo { separadordecampos campo} [ separadordecampos]
campo ::= `[´ exp `]´ `=´ exp | Nombre `=´ exp | exp
separadordecampos ::= `,´ | `;´
Cada campo de la forma [exp1] = exp2 agrega a la nueva tabla una entrada cuya clave es exp1 y cuyo valor es
exp2. Un campo de la forma Nombre = exp es equivalente a ["Nombre"] = exp. Finalmente, campos de la forma
exp son equivalentes a [i] = exp, donde i representa números enteros consecutivos, empezando con 1. Campos
en los otros formatos no afectan este conteo. Por ejemplo,
a = { [ f(1)] = g; "x", "y"; x = 1, f(x), [30] = 23; 45 }
Es equivalente a
do
local t = {}
t[f(1)] = g
t[1] = "x"
t[2] = "y"
t.x = 1
t[3] = f(x)
t[30] = 23
t[4] = 45
a = t
end
© ABNT 2007 - Todos los derechos reservados
-----
primera exp
segunda exp
t["x"] = 1
tercera exp
-- cuarta exp
203
ABNT NBR 15606-2:2007
Si el último campo en la lista posee la forma exp y la expresión es una llamada de función o una expresión con
un número variable de argumentos, entonces todos los valores retornados por la expresión entran en la lista
consecutivamente (ver B.2.6.9). Para evitar esto, colocar paréntesis alrededor de la llamada de función (o de la
expresión con número variable de argumentos) (ver B.2.6.1).
La lista de campos puede tener un separador más al final, como una conveniencia para código generado
automáticamente.
B.2.6.9
Llamadas de función
Una llamada de función en Lua tiene la siguiente sintaxis:
llamadadefuncion ::= expprefijo args
En una llamada de función, el primer expprefixo y args son evaluados. Si el valor de expprefixo posee tipo
function, entonces esta función es llamada con los argumentos suministrados. En caso contrario, el meta-método
"call" de expprefixo es llamado, teniendo como primer parámetro el valor de expprefixo, seguido por los
argumentos originales de la llamada (ver B.2.9).
La forma
llamadadefuncion ::= expprefijo `:´ Nombre args
se puede usar para llamar "métodos". Una llamada v:nombre(args) es un azúcar sintáctico para v.nombre(v,args),
con la diferencia de que v es evaluado solamente una vez.
Argumentos poseen la siguiente sintaxis:
args ::= `(´ [ listaexp] `) ´
args ::= constructordetabla
args ::= Cadena
Todas las expresiones suministradas como argumento son evaluadas antes de la llamada. Una llamada de la
forma f{campos} es un azúcar sintáctico para f({campos}); es decir, la lista de argumentos consiste solamente
en una tabla nueva. Una llamada de la forma f'cadena' (o f"cadena" o f[[cadena]]) es un azúcar sintáctico para
f('cadena'); es decir, la lista de argumentos consiste solamente en una cadena de caracteres literal.
Una excepción con relación a la sintaxis de formato libre de Lua es que no es posible colocar una quiebra de línea
antes del '(' en una llamada de función. Esta restricción evita algunas ambigüedades en el lenguaje.
Si se escribiese
a = f
(g) .x(a)
Lua podría ver esto como un comando único, a = f(g).x(a). Por lo tanto, si se desean dos comandos, se debe
obligatoriamente colocar un punto y coma entre ellos. Si realmente se desea llamar a f, se debe remover la
quiebra de línea antes de (g).
204
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
Una llamada de la forma return llamadadefuncion se denomina llamada final. Lua implementa llamadas finales
propias (o recursos finales propios): En una llamada final, la función llamada reutiliza la entrada en la pila de la
función que la llamó. Por lo tanto, no hay límite en el número de llamadas finales anidadas que un programa
puede ejecutar. Sin embargo, una llamada final apaga cualquier información de depuración sobre la función
llamadora. Una llamada final solamente ocurre con una sintaxis particular, donde el return posee una única
llamada de función como argumento; esta sintaxis hace que la llamada de función retorne exactamente los
valores de retorno de la función llamada. De esa forma, ninguno de los ejemplos a continuación son llamadas
finales:
return (f(_x)) -return 2 * f(x)
return x, f(x) -f(x); return
return x or f(x)
el número de resultados es ajustado para 1
resultados adicionales
-- resultados desechados
-- el número de resultados es ajustado para 1
B.2.6.10 Definiciones de funciones
La sintaxis para la definición de una función es
función ::= function cuerpodelafuncion
función ::= `(´ [listapar] `)´ bloque end
El siguiente azúcar sintáctico simplifica definiciones de funciones:
comando ::= Function nombredelafuncion cuerpodelafuncion
comando ::= Local function Nombre cuerpodelafuncion
nombredelafuncion ::= Nombre {`.´ Nombre} [`:´ Nombre]
El comando
function f () b o d y end
es traducido para
f = function () b o d y end
El comando
function t.a.b.c.f () b o d y end
es traducido para
t.a.b.c.f = function () b o d y end
El comando
local function f () b o d y end
es traducido para
local f; f = function () b o d y end
y no para
local f = function () b o d y end
© ABNT 2007 - Todos los derechos reservados
205
ABNT NBR 15606-2:2007
Esto solamente hace diferencia cuando el cuerpo de la función contiene una referencia para f.
Una definición de función es una expresión ejecutable, cuyo valor tiene tipo function. Cuando Lua pre-compila un
trecho, todos los cuerpos de las funciones del trecho son pre-compilados también. Entonces, siempre que Lua
ejecuta la definición de una función, la función es instanciada (o cerrada). Esta instancia de la función (o cierre) es
el valor final de la expresión. Instancias diferentes de la misma función pueden referirse a diferentes variables
locales externas y pueden tener diferentes tablas de ambiente.
Parámetros se comportan como variables locales que son inicializadas con los valores de los argumentos:
listapar ::= listadenombres [`,´ `...´] | `...´
Cuando una función es llamada, la lista de argumentos es ajustada para el tamaño de la lista de parámetros, a no
ser que la función sea de variedad variable o vararg, lo que se indica por tres puntos ('...') al final de su lista de
parámetros. Una función vararg no ajusta su lista de argumentos; en vez de eso, recolecta todos los argumentos
extras y los suministra a la función a través de una expresión vararg, la cual también es representada como tres
puntos. El valor de esta expresión es una lista de todos los argumentos extras corrientes, análogo a una función
con múltiples valores de retorno. Si una expresión vararg se utiliza dentro de otra expresión o en medio de una
lista de expresiones, entonces su lista de valores de retorno es ajustada para un elemento. Si la expresión se
utiliza como el último elemento de una lista de expresiones, entonces ningún ajuste se realiza (a menos que la
llamada sea delimitada por paréntesis).
Como un ejemplo, considere las siguientes definiciones:
function
function
function
f(a b) end
g(a b, ...) end
r()
return 1,2,3
En este caso, se tiene el siguiente mapeo de argumentos para parámetros y para las expresiones vararg:
LLAMADA
PARÁMETROS
f(3)
f(3, 4)
f(3, 4, 5)
f(r(), 10)
f (r ())
a=3
a=3
a=3
a=1
a=1
b=nil
b=4
b=4
b=10
b=2
g(3)
a=3
,
a=3
a=3
a=5
b=nil,
...
--> (nada)
b=4,
b=4,
b=1,
...
...
...
--> (nada)
--> 5 8
--> 2 3
g(3, 4)
g(3, 4, 5,8)
g(5, r ())
Resultados son retornados usando el comando return (ver B.2.5.5). Si el control alcanza el fin de una función sin
encontrar un comando return, entonces la función retorna sin ningún resultado.
La sintaxis de dos puntos se utiliza para definir métodos, es decir, funciones que poseen un parámetro extra
implícito self. De esta forma, el comando
function t.a.b.c:f ( p a r a m s ) b o d y end
Es un azúcar sintáctico para
t.a.b.c.f = function (self, p a r a m s ) b o d y end
206
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
B.2.7 Reglas de visibilidad
Lua es un lenguaje con alcance léxico. El alcance de las variables empieza en el primer comando después de su
declaración y va hasta el fin del bloque más interno que incluye la declaración. Considerar el siguiente ejemplo:
x = 10
-- variable global
do
-- bloque nuevo
local x = x
-- nuevo 'x', con valor 10
print(x)
--> 10
x = x+1
do
-- otro bloque
local x = x+1
-- otro 'x'
print(x)
--> 12
end
print(x)
--> 11
end
print(x)
--> 10 (o x global)
En una declaración como local x = x, la nueva x siendo declarada no está en el alcance aún y por lo tanto la
segunda x se refiere a una variable externa.
Debido a las reglas de alcance léxico, variables locales pueden ser libremente accedidas por funciones definidas
dentro de su alcance. Una variable local usada por una función más interna se denomina upvalue o variable local
externa, dentro de la función más interna.
Cada ejecución de un comando local define noticias variables locales. Considerar el ejemplo a continuación:
a = {}
local x = 20
for i=1,10 do
local y = 0
a[ i] = function () y=y+1; return x+y end
en d
El lazo crea diez cierres (es decir, diez instancias de la función anónima). Cada uno de estos cierres usa una
variable y diferente, mientras todos ellos comparten la misma variable X.
B.2.8 Tratamiento de errores
Dado que Lua es un lenguaje incorporado de extensión, todas las acciones de Lua empiezan a partir de código C
en el programa hospedero que llama una función de la biblioteca de Lua (ver lua_pcall). Siempre que un error
ocurre durante la compilación o ejecución, el control retorna para C, que puede tomar las medidas apropiadas
(tales como imprimir un mensaje de error).
El código Lua puede explícitamente generar un error a través de una llamada a la función error. Si es necesario
capturar errores en Lua, se puede usar la función pcall.
B.2.9 Metatablas
Todo valor en Lua puede tener una meta-tabla. Ésta meta-tabla es una tabla Lua común que define el
comportamiento del valor original con relación a ciertas operaciones especiales. Es posible alterar varios aspectos
del comportamiento de operaciones sobre un valor especificando campos específicos en la meta-tabla del valor.
Por ejemplo, cuando un valor no numérico es el operando de una adición, Lua verifica si existe una función
asociada con el campo "__add" en la meta-tabla del valor. Si la función existe, Lua llama esta función para
realizar la adición.
© ABNT 2007 - Todos los derechos reservados
207
ABNT NBR 15606-2:2007
Las claves son llamadas en una meta-tabla de eventos y los valores de meta-métodos. En el ejemplo anterior, el
evento es "add" y el meta-método es la función que realiza la adición.
Es posible obtener la meta-tabla de cualquier valor usando la función getmetatable.
Se puede alterar la meta-tabla de tablas a través de la función setmetatable. No se puede cambiar la meta-tabla
de otros tipos de Lua (a menos que sea utilizada la biblioteca de depuración); para hacer esto se debe usar
obligatoriamente la API C.
Tablas y objetos del tipo userdata completos poseen meta-tablas individuales (aunque múltiples tablas y objetos
userdata puedan compartir sus meta-tablas); valores de todos los otros tipos comparten una única meta-tabla por
tipo. Siendo así, hay solamente una meta-tabla para todos los números, una para todas las cadenas de
caracteres, etc.
Una meta-tabla puede controlar cómo un objeto se comporta en operaciones aritméticas, comparaciones con
relación a la orden, concatenación, operación de tamaño e indexación. Una meta-tabla también puede definir una
función a ser llamada cuando un objeto userdata es recolectado por el colector de basura. Para cada una de
estas operaciones Lua asocia una clave específica llamada un evento. Cuando Lua realiza una de estas
operaciones sobre un valor, Lua verifica si este valor posee una meta-tabla con el evento correspondiente. Si éste
es el caso, el valor asociado a esa clave (el meta-método) controla cómo Lua va a realizar la operación.
Metatablas controlan las operaciones listadas a continuación. Cada operación se identifica por su nombre
correspondiente. La clave para cada operación es una cadena de caracteres empezando con el nombre de la
operación siendo precedido por dos subrayados, '__'; por ejemplo, la clave para la operación "add" es la cadena
"__add". La semántica de estas operaciones se explica mejor por medio de una función Lua que describe cómo el
interpretador ejecuta la operación.
El código Lua mostrado en esta sección es meramente ilustrativo; el comportamiento real está codificado en el
interpretador y es mucho más eficiente que esta simulación. Todas las funciones usadas en estas descripciones
(rawget, tonumber etc.) son presentadas en B.5.2. En particular, para recobrar el meta-método de un objeto
determinado, se usa la siguiente expresión:
metatable (obj)[ event]
Esto debe ser leído como
rawget(getmetatable(obj) or {} , event)
Es decir, el acceso a un meta-método no invoca otros meta-métodos y el acceso a objetos que no poseen
metatablas no falla (simplemente da como resultado nil).
208
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007

"add": la operación +.
La función getbinhandler abajo define como Lua elige un tratador para una operación binaria. Primero, Lua
intenta el primer operando. Si este tipo no define un tratador para la operación, entonces Lua intenta el segundo
operando.
function getbinhandler (op1, op2, event)
return metatable(op1)[ event] or metatable(op2)[ event]
end
Usando esa función, el comportamiento del op1 + op2 es
function add_event (op1, op2)
local o1, o2 = tonumber(op1), tonumber(op2)
if o1 and o2 then
-- ¿ambos operandos son numéricos?
return o1 + o2
-- `+' aquí está el `add' primigenio
else
-- por lo menos uno de los operandos no es numérico
local h = getbinhandler(op1, op2, "__add")
if h then
-- llama al tratador pasando ambos operandos
return h(op1, op2)
else
-- sin tratador disponible: comportamiento estándar
error("...")
end
end
end

sub": la operación -. Comportamiento análogo al de la operación “add”.

"mul": la operación *. Comportamiento análogo al de la operación “add”.

"div": la operación /. Comportamiento análogo al de la operación “add”.

"mod": la operación %. Comportamiento análogo a la operación “add”, con la operación o1 floor(o1/o2)*o2 como operación primitiva.

"pow": la operación ^ (exponenciación). Comportamiento análogo al de la operación “add”, con la función
pow (proveniente de la biblioteca matemática del C) como operación primitiva.

"unm": la operación unaria -.
function unm _event (op)
local o = tonumber(op)
if el then
-- ¿operando es numérico?
return –o
-- `'aquí es el `unm' primigenio
else
-- el operando no es numérico
-- intenta encontrar un tratador para el operando local h = metatable(op).__unm
if h then
-- llama el tratador pasando el operando
return h(op)
else
-- sin tratador disponible: comportamiento estándar
error("...")
end
end
end
© ABNT 2007 - Todos los derechos reservados
209
ABNT NBR 15606-2:2007

"concat": la operación .. (concatenación).
function concat_event (op1, op2)
if (type(op1) == "string" or type(op1) == "number") and
(type(op2) == "string" or type(op2) == "number") then
return op1 .. op2 -- concatenacion de strings primitiva
else
local h = getbinhandler(op1, op2, "__concat")
if h then
return h(op1, op2)
else
error("...")
end
end
end

"len": la operación #.
function len_event (op)
if type(op) == "string" then
return strlen(op)
-- tamaño de string primitivo
elseif type(op) == "table" then
return #op
-- tamaño de tabla primitivo
else
local h = metatable(op).__len
if h then
-- llama el tratador pasando el operando
return h(op)
else -- sin tratador disponible: Comportamiento
estándar
error("...")
end
end
end
Ver B.2.6.6 para obtener una descripción de la longitud de una tabla.
 "eq": la operación ==. La función getcomphandler define como Lua elige un meta-método para
comparación de operadores. Un meta-método solo es seleccionado cuando ambos objetos en comparación
tienen el mismo tipo y el mismo meta-método para la operación seleccionada.
function getcomphandler (op1, op2, event)
if type(op1) ~= type(op2) then return nil end
local mm1 = metatable(op1)[ event] local mm2 = metatable(op2)[ event]
if mm1 == mm2 then return mm1 else return nil end
end
El evento “eq” se define como:
function eq_event (op1, op2)
if type(op1) ~= type(op2) then -- different types?
return false
-- different objects
end
if op1 == op2 then
-- primitive equal?
return true
-- objects are equal
end
-- try metamethod
local h = getcomphandler(op1, op2, "__eq")
if h then
210
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
return h(op1, op2)
else
return false
end
end
a ~= b es equivalente a not (a = = b).

"lt": la operación <.
function lt_event (op1, op2)
if type(op1) == "number" and type(op2) == "number" then
return op1 < op2 -- comparación numérica
elseif type(op1)=="string" and type(op2)=="string" then
return op1 < op2 -- comparación lexicográfica
else
local h = getcomphandler(op1, op2, "__lt")
if h then
return h(op1, op2)
else
error("...");
end
end
end
a > b es equivalente a b < a.

"le": la operación <=.
function le_event (op1, op2)
if type(op1) == "number" and type(op2) == "number" then
return op1 <= op2
-- comparación numérica
elseif type(op1)=="string" and type(op2)=="string" then
return op1 <= op2
-- comparación lexicográfica
else
local h = getcomphandler(op1, op2, "__le")
if h then
return h(op1, op2)
else
h = getcomphandler(op1, op2, "__lt")
if h then
return not h(op2, op1)
else
error("...");
end
end
end
end
a >= b es equivalente a b <= a. En la ausencia de un meta-método “le”, Lua intenta el “lt”, asumiendo que a <=
b es equivalente a not (b < a).
© ABNT 2007 - Todos los derechos reservados
211
ABNT NBR 15606-2:2007
 "index": acceso de indexación table[key].
function gettable_event (table, key)
local h
if type(table) == "table" then
local v = rawget(table, key)
if v ~= nil then return v end
h = metatable(table).__index
if h == nil then return nil end
else
h = metatable(table).__index
if h == nil then
error("...");
end
end
if type(h) == "function" then
return h(table, key)
-- llama el tratador
else return h[key]
-- o repita la operación
end
end
 "newindex": atribución indexada table[key] = value
function settable_event (table, key, value)
local h
if type(table) == "table" then
local v = rawget(table, key)
if v ~= nil then rawset(table, key, value); return
h = metatable(table).__newindex
if h == nil then rawset(table, key, value); return
else
h = metatable(table).__newindex
if h == nil then
error("...");
end
end
if type(h) == "function" then
return h(table, key,value)
-- llama el
else h[key] = value
-- o repita
end
end

end
end
tratador
la operación
"call": llamado cuando Lua llama un valor.
function function_event (func, ...)
if type(func) == "function" then
return func(...) -- llamada primitiva
else
local h = metatable(func).__call
if h then
return h(func, ...)
else
error("...")
end
end
end
212
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
B.2.10 Ambientes
Además de meta-tablas, objetos del tipo thread, function y userdata poseen otra tabla asociada a ellos,
denominada su ambiente. Así como meta-tablas, ambientes son tablas normales y varios objetos pueden
compartir el mismo ambiente.
Ambientes asociados con objetos del tipo userdata no poseen significado para Lua. Es sólo una conveniencia
para programadores asociar una tabla a un objeto userdata.
Ambientes asociados con flujos de ejecución (threads) son llamados ambientes globales. Se usan como el
ambiente estándar por sus flujos de ejecución y funciones no anidadas creadas por el flujo de ejecución (a través
de loadfile, loadstring o load) y pueden ser directamente accedidos por el código C (ver B.3.4).
Ambientes asociados con funciones C pueden ser directamente accedidos por el código C (ver B.3.4). Se usan
como el ambiente estándar para otras funciones C creadas por la función.
Ambientes asociados con funciones Lua se usan para resolver todos los accesos a variables globales dentro de la
función (ver B.2.4). Se usan como el ambiente estándar para otras funciones Lua creadas por la función.
Es posible alterar el ambiente de una función Lua o del flujo de ejecución que está siendo ejecutado actualmente
llamando a setfenv. Es posible obtener el ambiente de una función Lua o del flujo de ejecución siendo ejecutado
actualmente llamando a getfenv. Para tratar el ambiente de otros objetos (userdata, funciones C, otros flujos de
ejecución) se debe usar obligatoriamente la API C.
B.2.11 Recolecta de basura
B.2.11.1 Conceptos básicos
Lua realiza gestión automática de la memoria. Esto significa que no es necesario preocuparse con la asignación
de memoria para nuevos objetos ni con la liberación de memoria cuando los objetos ya no son necesarios. Lua
administra la memoria automáticamente ejecutando un colector de basura de vez en cuando para recolectar todos
los objetos muertos (es decir, aquellos objetos que han dejado de ser accesibles desde Lua). Todos los objetos
en Lua están sujetos a la gestión automática de memoria: tablas, userdata, funciones, flujos de ejecución y
cadenas de caracteres.
Lua implementa un colector de basura “marcar y limpiar” (Mark-and-sweep) incremental. El colector usa dos
números para controlar su ciclo de Recolecta de basura: La pausa del colector de basura y el multiplicador de
paso del colector de basura.
La pausa del colector de basura controla cuánto tiempo el colector espera antes de iniciar un nuevo ciclo. Los
valores mayores hacen que el colector sea menos agresivo. Los valores menores que 1 significan que el colector
no esperará para iniciar un nuevo ciclo. Un valor de 2 significa que el colector esperará hasta que la memoria total
en uso se duplique antes de iniciar un nuevo ciclo.
El multiplicador de paso controla la velocidad relativa del colector con relación a la asignación de memoria. Los
valores mayores tornan al colector más agresivo pero también aumentan el tamaño de cada paso incremental.
Los valores menores que 1 hacen que el colector sea muy lento y puede ocurrir que el colector nunca termine un
ciclo. El valor estándar, 2, significa que el colector se ejecuta a una velocidad que es "dos veces" la velocidad de
asignación de memoria.
Es posible alterar estos números a través de llamadas a las funciones lua_gc en C o collectgarbage en Lua.
Ambas reciben valores en puntos porcentuales como argumentos (de modo que un argumento cuyo valor es 100
significa un valor real de 1). Con estas funciones también se puede controlar el colector directamente (por ejemplo,
pararlo y reiniciarlo).
© ABNT 2007 - Todos los derechos reservados
213
ABNT NBR 15606-2:2007
B.2.11.2 Meta-métodos de Recolecta de basura
Usando la API C, se puede configurar los meta-métodos del colector de basura para objetos userdata (ver B.2.9).
Éstos meta-métodos también se denominan finalizadores. Los finalizadores permiten que se coordine la Recolecta
de basura de Lua con la gestión de recursos externos (tales como el cierre de archivos, conexiones de red o de
bancos de datos o la liberación de su propia memoria).
Los objetos userdata con un campo __gc en su meta-tablas no son colectados inmediatamente por el colector de
basura. En vez de eso, Lua los coloca en esa lista. Después que la recolecta se realiza, Lua hace el equivalente
de la siguiente función para cada objeto userdata en una lista:
function gc_event (userdata)
local h = metatable(userdata) .__gc
if h then
h (userdata)
end
end
Al final del ciclo de recolecta de basura, los finalizadores para los objetos userdata son llamados en el orden
inverso al de su creación, entre aquellos colectados en ese ciclo. Es decir, el primer finalizador a ser llamado es
asociado con el objeto userdata que fue creado por último en el programa. El userdata solo es efectivamente
liberado en el próximo ciclo de Recolecta de basura.
B.2.11.3 Tablas débiles
Una tabla débil es una tabla cuyos elementos son informes débiles. Una referencia débil es ignorada por el
colector de basura. En otras palabras, si los únicos informes para un objeto son informes débiles, entonces el
colector de basura colectará este objeto.
Una tabla débil puede tener claves débiles, valores débiles o ambos. Una tabla con claves débiles permite la
recolecta de sus claves pero impide la recolecta de sus valores. Una tabla con claves débiles y valores débiles
permite la recolecta tanto de las claves como de los valores. En cualquier caso, si la clave es colectada o el valor
es colectado, el par entero es borrado de la tabla. La fragilidad de una tabla es controlada por el campo __mode
de su meta-tabla. Si el campo __mode es una cadena de caracteres conteniendo el carácter 'k', las claves de la
tabla son débiles. Si __mode contiene 'v', los valores en la tabla son débiles.
Después de usar una tabla como una meta-tabla, no se debe alterar el valor de su campo __mode. En caso
contrario, el comportamiento débil de las tablas controladas por ésta meta-tabla es indefinido.
B.2.12 Co-rutinas
Lua ofrece soporte a co-rutinas, también conocidas como flujos de ejecución (threads) colaborativos. Una corutina en Lua representa un flujo de ejecución independiente. Al contrario de procesos ligeros en sistemas que
dan soporte a múltiples flujos de ejecución, una co-rutina solamente suspende su ejecución a través de una
llamada explícita a una función de cesión.
Es posible crear una co-rutina con una llamada a la coroutine.create. Su único argumento es una función que es
la función principal de la co-rutina. La función create solamente crea una nueva co-rutina y retorna una referencia
para la misma (un objeto del tipo thread); no inicia la ejecución de la co-rutina.
Cuando la función coroutine.resume es llamada por primera vez, recibiendo como su primer argumento el objeto
del tipo thread retornado por coroutine.create, la co-rutina inicia su ejecución, en la primera línea de su función
principal. Después que la co-rutina empieza a ser ejecutada, continúa ejecutando hasta terminar o ceder.
Una función puede terminar su ejecución de dos formas: Normalmente, cuando su función principal retorna
(explícita o implícitamente, después de la última instrucción); y de manera anormal, si ocurre un error no protegido
en el primer caso, coroutine.resume retorna true más cualquier valor retornado por la función principal de la corutina. En el caso de ocurrir errores, coroutine.resume retorna false más un mensaje de error.
214
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
Una co-rutina cede la ejecución a través de una llamada a la función coroutine.yield. Cuando una co-rutina cede,
la coroutine.resume correspondiente retorna inmediatamente, incluso si la cesión ocurrió dentro de una llamada
de función anidada (es decir, no ocurrió dentro de la función principal, sino en una función llamada directa o
indirectamente por la función principal). En el caso de una cesión, coroutine.resume también retorna true, más
cualquier valor pasado para coroutine.yield. La próxima vez que se reinicie la ejecución de la misma co-rutina,
continúa su ejecución desde el punto donde cedió, con la llamada para coroutine.yield retornando cualesquiera
argumentos extras pasados para coroutine.resume.
Como coroutine.create, la función coroutine.wrap también crea una co-rutina, pero en vez de retornar la propia corutina, retorna una función que, cuando es llamada, retoma la ejecución de la co-rutina. Cualesquiera argumentos
pasados para esta función van como argumentos extras para coroutine.resume. Coroutine.wrap retorna todos los
valores retornados por coroutine.resume, excepto el primero (el código booleano de error). Diferentemente de
coroutine.resume, coroutine.wrap no captura errores; cualquier error es propagado para el llamador.
Como un ejemplo, considerar el siguiente código:
function foo (a)
print("foo", a)
return coroutine . yield (2* a)
end
co = coroutine.create(function (a,b)
print("co-body", a, b)
local r = foo(a+1)
print ("co-body", r)
local r, s = coroutine.yield(a+b, a-b)
print("co-body", r, s)
return b, "end"
end)
print("main",
print("main",
print("main",
print("main",
coroutine.resume(co,
coroutine.resume(co,
coroutine.resume(co,
coroutine.resume(co,
1, 10))
"r"))
"x", "y"))
"x", "y"))
Cuando se ejecuta este código, produce el siguiente resultado:
co-body
foo
main
co-body
main
co-body
main
main
1
2
true
r
true
x
true
false
10
4
11
-9
y
10
end
cannot resume dead coroutine
© ABNT 2007 - Todos los derechos reservados
215
ABNT NBR 15606-2:2007
B.3 Interfaz de programación de la aplicación (API)
B.3.1 Conceptos básicos
Todas las funciones de la API, así como los tipos y constantes relacionados, están declarados en el archivo de
encabezamiento lua.h.
Incluso cuando se usa el término "función", cualquier operación en la API puede, de forma alternativa, ser provista
como una macro. Tales macros usan cada uno de sus argumentos exactamente una vez (con excepción del
primer argumento, que es siempre un estado Lua) y por lo tanto no generan cualquier efecto colateral oculto.
Como en la mayoría de las bibliotecas C, las funciones de la API Lua no verifican la validez o la consistencia de
sus argumentos. Sin embargo, es posible alterar este comportamiento compilando Lua con una definición
apropiada para la macro luai_apicheck, en el archivo luaconf.h.
B.3.2 Pila
Lua usa una pila virtual para pasar y recibir valores de C. Cada elemento en esta pila representa un valor Lua (nil,
un número, una cadena de caracteres etc.).
Siempre que Lua llama C, la función llamada recibe una nueva pila, que es independiente de pilas anteriores y de
pilas de funciones C que aún estén activas. Esta pila contiene inicialmente cualesquiera argumentos para la
función C y es donde la función C apila sus resultados para ser retornados al llamador (ver lua_CFunction).
Por conveniencia, la mayoría de las operaciones de consulta en la API no sigue una disciplina estricta de pila. En
vez de eso, pueden referirse a cualquier elemento en la pila usando un índice. Un índice positivo representa una
posición absoluta en la pila (empezando por 1); un índice negativo representa una posición relativa a la parte
superior de la pila. De manera más específica, si la pila posee n elementos, entonces el índice 1 representa el
primer elemento (es decir, el elemento que fue apilado en la pila primero) y el índice n representa el último
elemento; el índice -1 también representa el último elemento (es decir, el elemento en la parte superior) y el índice
-n representa el primer elemento. Se dice que un índice es válido si está entre 1 y la parte superior de la pila (es
decir, si 1 ~ abs(índice) ~ tope).
B.3.3 Tamaño de la pila
Cuando se interactúa con la API de Lua, se es responsable por asegurar consistencia. En particular, se es
responsable por controlar un reventón de la pila. Se puede usar la función lua_checkstack para aumentar el
tamaño de la pila.
Siempre que Lua llama a C, asegura que por lo menos LUA_MINSTACK posiciones en la pila están disponibles.
LUA_MINSTACK es definida como 20, entonces generalmente no es necesario preocuparse con el espacio de la
pila a menos que su código posea lazos apilando elementos en la pila.
La mayoría de las funciones de consulta acepta como índices cualquier valor dentro del espacio de la pila
disponible, es decir, índices hasta el tamaño máximo de la pila que se configuró a través de la función
lua_checkstack. Tales índices son llamados índices aceptables. Más formalmente, definido un índice aceptable de
la siguiente forma:
(índice < 0 && abs(índice) <= tope) ||
(índice > 0 && índice <= espaciodelapila)
Observar que 0 nunca es un índice aceptable.
216
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
B.3.4 Pseudo-índices
A menos que se diga lo contrario, cualquier función que acepta índices válidos también puede ser llamada con
pseudo-índices, que representan algunos valores Lua que son accesibles para el código C pero que no están en
la pila. Pseudo-índices se usan para acceder al ambiente del flujo de ejecución, el ambiente de la función, el
registro y los upvalues de la función C (ver B.3.5).
El ambiente del flujo de ejecución (donde las variables globales existen) está siempre en el pseudo-índice
LUA_GLOBALSINDEX. El ambiente de la función C funcionando está siempre en el pseudo-índice
LUA_ENVIRONINDEX.
Para acceder y alterar el valor de variables globales, se puede usar operaciones de tablas usuales sobre una
tabla de ambiente. Por ejemplo, para acceder al valor de una variable global, hacer
lua _getfield(L, LUA _GLOBALSINDEX, varname);
B.3.5 Cierres C
Cuando una función C es creada, es posible asociar algunos valores a la misma, creando entonces un cierre C;
estos valores son llamados up values y son accesibles para la función siempre que es llamada (ver
lua_pushcclosure).
Siempre que una función C es llamada, sus upvalues son posicionados en pseudo-índices específicos. Estos
pseudo-índices son generados por la macro lua_upvalueindex. El primer valor asociado con una función está en la
posición lua_upvalueindex(1), y así sucesivamente. Cualquier acceso a lua_upvalueindex(n), donde n es mayor
que el número de upvalues de la función actual, produce un índice aceptable (aunque inválido).
B.3.6 Registro
Lua provee un registro, una tabla predefinida que puede ser usada por cualquier código C para almacenar
cualquier valor Lua que el código C necesite almacenar. Esta tabla está siempre localizada en el pseudo-índice
LUA_REGISTRYINDEX. Cualquier biblioteca de C puede almacenar datos en esta tabla, pero debe tener cuidado
para elegir claves diferentes de aquellas usadas por otras bibliotecas, para evitar colisiones. Típicamente, se debe
usar como clave una cadena de caracteres conteniendo el nombre de su biblioteca o un objeto del tipo userdata
ligero con la dirección de un objeto C en su código.
Las claves enteras en el registro son usadas por el mecanismo de referencia, implementado por la biblioteca
auxiliar, y por lo tanto no deben ser usadas para otros propósitos.
B.3.7 Tratamiento de errores en C
Internamente, Lua usa el mecanismo de longjmp de C para tratar errores (se puede también utilizar excepciones
si se utiliza; ver el archivo luaconf.h.) Cuando Lua encuentra cualquier error (tales como errores de asignación de
memoria, errores de tipo, errores de sintaxis y errores de tiempo de ejecución) dispara un error; es decir, hace un
desvío largo. Un ambiente protegido usa setjmp para establecer un punto de recuperación; cualquier error desvía
el flujo de ejecución para el punto de recuperación activado más reciente.
La mayoría de las funciones en la API puede disparar un error, por ejemplo debido a un error de asignación de
memoria. La documentación para cada función indica si puede disparar errores.
Dentro de una función C se puede disparar un error llamando lua_error.
© ABNT 2007 - Todos los derechos reservados
217
ABNT NBR 15606-2:2007
B.3.8 Funciones y tipos
Todas las funciones y tipos de la API C se listan a continuación en orden alfabético. Cada función tiene un
indicador como éste: [-o, +p, x]
El primer campo, o, representa cuántos elementos la función desapila de la pila. El segundo campo, p, indica
cuántos elementos la función apila en la pila (cualquier función siempre apila sus resultados después de desapilar
sus argumentos). Un campo en la forma x|y significa que la función puede apilar (o desapilar) x o y elementos,
dependiendo de la situación; una marca de interrogación '?' significa que no se puede saber cuántos elementos
desapila/apila la función mirando solamente sus argumentos (por ejemplo, el número de elementos puede
depender de lo que está en la pila). El tercer campo, x, dice si la función puede disparar errores: '-' Significa que la
función nunca dispara cualquier error; 'm' significa que la función puede disparar un error solamente debido a la
falta de memoria; 'y' significa que la función puede disparar otros tipos de error; 'v' significa que la función puede
disparar un error intencional.
lua_Alloc
typedef void * (*lua _Alloc) (void *ud, void *ptr, size _t osize, size _t nsize);
El tipo de la función de asignación de memoria usada por los estados Lua. La función de asignación debe
proveer una funcionalidad análoga a la de realloc, pero no exactamente la misma. Sus argumentos son ud, un
indicador opaco pasado para lua_newstate; ptr, un indicador para el bloque siendo asignado/reasignado/liberado;
osize, el tamaño original del bloque; y nsize, el nuevo tamaño del bloque. Ptr es NULL si, y solamente si, osize es
cero. Cuando nsize es cero, la función de asignación debe retornar NULL; si osize es diferente de cero, el bloque
de memoria indicado por ptr debe ser liberado. Cuando nsize no es cero, la función de asignación retorna NULL
si, y solamente si, no puede asignar el tamaño del bloque requerido. Cuando nsize no es cero y osize es cero, la
función de asignación debe comportarse como malloc. Cuando nsize y osize no son cero, la función de
asignación se comporta como realloc. Lua presupone que la función de asignación nunca falla cuando osize >=
nsize.
Sigue una implementación simple para la función de asignación. Se utiliza en la biblioteca auxiliar por
luaL_newstate.
static void *l _alloc (void *ud, void *ptr, size _t osize, size _t nsize) {
(void)ud;
/* not used */
(void) osize;
/* not used */
if (nsize == 0) {
free(ptr); /* ANSI requires that free(NULL) has no effect */
return NULL;
}
else
/* ANSI requires that realloc(NULL, size) == malloc(size) */
return realloc(ptr, nsize);
}
Este código presupone que free(NULL) no posee ningún efecto y que realloc(NULL, size) es equivalente a
malloc(size). ANSI C garantiza esos dos comportamientos.
218
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
lua_atpanic
lua_CFunction lua_atpanic (lua_State *L, lua_CFunction panicf);
Establece una nueva función de pánico y retorna la función de pánico antigua.
Si un error ocurre fuera de cualquier ambiente protegido, Lua llama una función de pánico y entonces llama
exit(EXIT_FAILURE), terminando entonces la aplicación hospedera. Su función de pánico puede evitar esta salida
en el caso que nunca retorne (por ejemplo, haciendo un desvío largo).
La función de pánico puede acceder al mensaje de error en la parte superior de la pila.
lua_call
void lua_call (lua_State *L, int nargs, int nresults);
Llama una función.
Para llamar una función se debe usar el siguiente protocolo: Primero, la función a ser llamada es apilada en la
pila; a continuación, los argumentos de la función son apilados en orden directo; es decir, el primer argumento es
apilado primero. Por último se llama lua_call; nargs es el número de argumentos que se amontonó en la pila.
Todos los argumentos y el valor de la función son desapilados de la pila cuando la función es llamada. Los
resultados de la función son apilados en la pila cuando la función retorna. El número de resultados es ajustado
para nresults, a menos que nresults sea LUA_MULTRET. En este caso, todos los resultados de la función son
apilados. Lua cuida para que los valores retornados quepan dentro del espacio de la pila. Los resultados de la
función son apilados en la pila en orden directo (el primer resultado es apilado primero), de modo que después de
la llamada el último resultado está en la parte superior de la pila.
Cualquier error dentro de la función llamada es propagado hacia arriba (con un longjmp).
El siguiente ejemplo muestra como el programa hospedero puede hacer el equivalente a este código Lua:
a = f("how", t.x, 14)
Sigue el mismo código en C:
lua_getfield(L, LUA_GLOBALSINDEX, "f");
/* función a ser llamada
*/
lua_pushstring(L, "how");
/* primer argumento
*/
lua_getfield(L, LUA_GLOBALSINDEX, "t");
/* tabla a ser indexada
*/
lua_getfield(L, -1, "x");
/* apila el resultado de t.x (2º arg)
*/
lua_remove(L, -2);
/* remueve 't' de la pila */
lua_pushinteger(L, 14);
/* 3er. argumento */
lua_call(L, 3, 1);
/* llama 'f' con 3 argumentos y 1 resultado
*/
lua_setfield(L, LUA_GLOBALSINDEX, "a");
/* establece ‘a’ global
*/
El código anterior es "equilibrado": al final, la pila está de regreso a su configuración original. Esto se considera
una buena práctica de programación.
© ABNT 2007 - Todos los derechos reservados
219
ABNT NBR 15606-2:2007
lua_C Function
typedef int (*lua _CFunction) (lua _State *L);
El tipo para funciones C.
Con el objeto de comunicarse apropiadamente con Lua, una función C debe usar el siguiente protocolo, el cual
define el modo cómo se pasan los parámetros y resultados: Una función C recibe sus argumentos de Lua en su
pila en orden directo (el primer argumento es apilado primero). Por lo tanto, cuando la función empieza,
lua_gettop(L) retorna el número de argumentos recibidos por la función. El primer argumento (si hay) está en el
índice 1 y su último argumento está en el índice lua_gettop(L). Para retornar valores para Lua, una función C sólo
los apila en la pila, en orden directo (el primer resultado se apila primero) y retorna el número de resultados.
Cualquier otro valor en la pila debajo de los resultados será debidamente desechado por Lua. Como una función
Lua, una función C llamada por Lua también puede retornar muchos resultados.
Como un ejemplo, la siguiente función recibe un número variable de argumentos numéricos y retorna el promedio
y la suma de ellos:
static int foo (lua_State *L) {
int n = lua_gettop(L);
/* number of arguments */
lua_Number sum = 0;
int i;
for (i = 1; i <= n; i++) {
if (!lua_isnumber(L, i)) {
lua_pushstring(L,"incorrect argument to function `average'");
lua_error(L);
}
sum += lua_tonumber(L, i);
}
lua_pushnumber(L, sum/n);
/* first result */
lua_pushnumber(L, sum);
/* second result */
return 2;
/* number of results */
}
lua_checkstack
int lua_checkstack (lua_State *L, int extra);
Garantiza que existen por lo menos posiciones extra disponibles en la pila. La función retorna falso si no puede
aumentar el tamaño de la pila para el tamaño deseado. Esta función nunca comprime la pila; si la pila ya es mayor
que el nuevo tamaño, no tendrá su tamaño modificado.
lua_close
void lua _close (lua _State *L);
Destruye todos los objetos en el estado Lua suministrado (llamando los meta-métodos de recolecta de basura
correspondientes, en caso de haberlos) y libera toda la memoria dinámica usada por ese estado. En varias
plataformas, puede no ser necesario llamar esta función, porque todos los recursos son naturalmente liberados
cuando el programa hospedero muere. Por otro lado, programas que se quedan funcionando por mucho tiempo,
como un daemon o un servidor Web, pueden necesitar liberar estados tan pronto no sean necesarios, para evitar
un crecimiento excesivo del uso de la memoria.
220
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
lua_concat
void lua _concat (lua _State *L, int n);
Concatena los n valores en la parte superior de la pila, los desapila y deja el resultado en la parte superior de la pila.
Si n es 1, el resultado es el único valor en la pila (es decir, la función no hace nada); si n es 0, el resultado es la
cadena de caracteres vacía. La concatenación se realiza de acuerdo con la semántica usual de Lua (ver B.2.6.5).
lua_cpcall
int lua _cpcall (lua _State *L, lua _CFunction func, void *ud);
Llama la función C func en modo protegido. func empieza solamente con un único elemento en su pila, el objeto
userdata ligero conteniendo ud. En caso de errores, lua_cpcall retorna el mismo código de error de
lua_pcall, más el objeto de error en la parte superior de la pila; en caso contrario, retorna cero y no cambia la
pila. Todos los valores retornados por func se descartan.
lua_createtable
void lua _createtable (lua _State *L, int narr, int nrec);
Crea una nueva tabla vacía y la apila en la parte superior de la pila. La nueva tabla posee espacio pre-asignado
para narr elementos array y nrec elementos no array. Esta pre-asignación es útil cuando se sabe exactamente
cuántos elementos va a tener la tabla. En caso contrario se puede usar la función lua_newtable.
lua_dump
int lua_dump (lua_State *L, lua_Writer writer, void *data);
Descarga una función como un trecho de código binario. Recibe una función Lua en la parte superior de la pila y
produce un trecho de código binario que, si se carga nuevamente, da como resultado una función equivalente a
aquella que fue descargada. Para producir partes del trecho de código, lua_dump llama la función writer (ver
lua_Writer) con el argumento fecha suministrado para escribirlos.
El valor retornado es el código de error retornado por la última llamada a la función writer; 0 significa que no
ocurrieron errores.
Esta función no desapila la función Lua de la pila.
lua_equal
int lua_equal (lua_State *L, int index1, int index2);
Retorna 1 si los dos valores en los índices aceptables index1 e index2 son iguales, siguiendo la semántica del
operador == de Lua (es decir, puede llamar meta-métodos). En caso contrario retorna 0. También retorna 0 si
cualquiera de los índices no es válido.
lua_error
int lua _error (lua _State *L);
Genera un error Lua. El mensaje de error (que puede ser de hecho un valor Lua de cualquier tipo) debe estar en la
parte superior de la pila. Esta función hace un desvío largo y por lo tanto nunca retorna. (ver luaL_error ).
© ABNT 2007 - Todos los derechos reservados
221
ABNT NBR 15606-2:2007
lua_gc
int lua_gc (lua_State *L, int what, int data);
Controla el colector de basura
Esa función ejecuta varias tareas, de acuerdo con el valor del parámetro what:

LUA_GCSTOP: interrumpe el colector de basura.

LUA_GCRESTART: reinicia el colector de basura.

LUA_GCCOLLECT: realiza un ciclo completo de Recolecta de basura.

LUA_GCCOUNT: retorna la cantidad de memoria (en Kbytes) que está siendo usada habitualmente
por Lua.

LUA_GCCOUNTB: retorna el resto de la división de la cantidad de bytes de memoria usada
habitualmente por Lua por 1024.

LUA_GCSTEP: realiza un paso incremental de recolecta de basura. El "tamaño" del paso es
controlado por data (valores mayores significan más pasos) de manera no especificada. Si se
desea controlar el tamaño del paso, se debe ajustar de manera experimental el valor de data. La
función retorna 1 si el paso finalizó un ciclo de recolecta de basura.

LUA_GCSETPAUSE: establece data/100 como el nuevo valor para la pausa del colector (ver
B.2.11). La función retorna el valor anterior de la pausa.

LUA_GCSETSTEPMUL: establece data/100 como el nuevo valor para el multiplicador de paso
del colector (ver B.2.11). La función retorna el valor anterior del multiplicador de paso.
lua_getallocf
lua_Alloc lua_getallocf (lua_State *L, void **ud);
Retorna la función de asignación de memoria de un dato estado. Si ud no es NULL, Lua almacena en *ud el
indicador opaco pasado para lua_newstate.
lua_getfenv
void lua_getfenv (lua_State *L, int index);
Coloca en la pila la tabla de ambiente del valor en el índice suministrado.
lua_getfield
void lua _getfield (lua _State *L, int index, const char *k);
Coloca en la pila el valor t[k], donde t es el valor en el índice válido suministrado. Como en Lua, esta función
puede disparar un meta-método para el evento "index" (ver B.2.9).
lua_getglobal
void lua _getglobal (lua _State *L, const char *name);
Coloca en la pila el valor de la global name. Esta función es definida como una macro:
#define lua_getglobal(L, s) lua_getfield(L, LUA_GLOBALSINDEX, s)
222
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
lua_getmetatable
int lua _getmetatable (lua _State *L, int index);
Coloca en la pila la meta-tabla del valor en el índice aceptable suministrado. Si el índice no es válido o si el valor
no posee una meta-tabla, la función retorna 0 y no coloca nada en la pila.
lua_gettable
void lua _gettable (lua _State *L, int index);
Coloca en la pila el valor t[k], donde t es el valor en el índice válido suministrado y k es el valor en la parte superior
de la pila.
Esta función desapila la clave 'k' (colocando el resultado en su lugar). Como en Lua, esta función puede disparar
un meta-método para el evento "index" (ver B.2.9).
lua_gettop
int lua _gettop (lua _State *L);
Retorna el índice del elemento en la parte superior de la pila. Visto que los índices empiezan en 1, este resultado
es igual al número de elementos en la pila (y por lo tanto 0 significa una pila vacía).
lua_insert
void lua_insert (lua_State *L, int index);
Mueve el elemento en la parte superior para el índice válido suministrado, desplazando los elementos arriba de
este índice para abrir espacio. Esta función no puede ser llamada con un pseudo-índice, porque un pseudo-índice
no es una posición real de la pila.
lua_Integer
typedef ptrdiff _t lua _Integer;
El tipo usado por la API Lua para representar valores enteros.
El tipo estándar es un ptrdiff_t, que es comúnmente el mayor tipo entero con señal que la máquina maneja
"cómodamente".
lua_isboolean
int lua _isboolean (lua _State *L, int index);
Retorna 1 si el valor en el índice aceptable suministrado posee tipo booleano y 0 en caso contrario.
© ABNT 2007 - Todos los derechos reservados
223
ABNT NBR 15606-2:2007
lua_iscfunction
int lua _iscfunction (lua _State *L, int index);
Retorna 1 si el valor en el índice aceptable suministrado es una función C y 0 en caso contrario.
lua_isfunction
int lua _isfunction (lua _State *L, int index);
Retorna 1 si el valor en el índice aceptable suministrado es una función (C o Lua) y 0 en caso contrario.
lua_isl ig htuserdata
int lua_islightuserdata (lua_State *L, int index);
Retorna 1 si el valor en el índice aceptable suministrado es un objeto userdata ligero y 0 en caso contrario.
lua_isnil
int lua _isnil (lua _State *L, int index);
Retorna 1 si el valor en el índice aceptable suministrado es nil y 0 en caso contrario.
lua_isnone
int lua _isnone (lua _State *L, int index);
Retorna 1 si el índice aceptable suministrado no es válido (es decir, si se refiere a un elemento fuera del espacio
de la pila corriente) y 0 en caso contrario.
lua_isnoneornil
int lua _isnoneornil (lua _State *L, int index);
Retorna 1 si el índice aceptable suministrado no es válido (es decir, si se refiere a un elemento fuera del espacio
de la pila corriente) o si el valor en este índice es nil y 0 en caso contrario.
lua_isnumber
int lua_isnumber (lua_State *L, int index);
Retorna 1 si el valor en el índice aceptable suministrado es un número o una cadena de caracteres que puede ser
convertida para un número y 0 en caso contrario.
224
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
lua_isstring
int lua _isstring (lua _State *L, int index);
Retorna 1 si el valor en el índice aceptable suministrado es una cadena de caracteres o un número (lo cual
siempre puede ser convertido para una cadena) y 0 en caso contrario.
lua_istable
int lua _istable (lua _State *L, int index);
Retorna 1 si el valor en el índice aceptable suministrado es una tabla y 0 en caso contrario.
lua_isthread
int lua_isthread (lua_State *L, int index);
Retorna 1 si el valor en el índice aceptable suministrado es del tipo thread y 0 en caso contrario.
lua_isuserdata
int lua _isuserdata (lua _State *L, int index);
Retorna 1 si el valor en el índice aceptable suministrado es un objeto userdata (completo o ligero) y 0 en caso
contrario.
lua_lessthan
int lua _lessthan (lua _State *L, int index1, int index2);
Retorna 1 si el valor en el índice aceptable index1 es menor que el valor en el índice aceptable index2, siguiendo
la semántica del operador < de Lua (es decir, puede llamar meta-métodos). En caso contrario retorna 0. También
retorna 0 si cualquiera de los índices no es válido.
lua_load
int lua_load (lua_State *L, lua_Reader reader, void *data, const char *chunkname);
Carga un trecho de código Lua. Si no ocurre ningún error, lua_load apila el trecho compilado como una función
Lua en la parte superior de la pila. En caso contrario, apila un mensaje de error. Los valores de retorno de
lua_load son:

0 --- sin errores;

LUA_ERRSYNTAX --- error de sintaxis durante la pre-compilación.

LUA_ERRMEM --- error de asignación de memoria.
Esta función solamente carga un trecho; no lo ejecuta.
© ABNT 2007 - Todos los derechos reservados
225
ABNT NBR 15606-2:2007
Lua_load automáticamente detecta si el trecho está en forma de texto o en la forma binaria y lo carga de manera
correcta (ver el programa luac).
La función lua_load usa una función reader suministrada por el usuario para leer el trecho de código (ver
lua_Reader). El argumento fecha es un valor opaco pasado para la función de lectura.
El argumento chunkname da un nombre al trecho, el cual se utiliza para mensajes de error y en informaciones de
depuración (ver B.3.9).
lua_newstate
lua _State *lua _newstate (lua _Alloc f, void *ud);
Crea un estado nuevo independiente. Retorna NULL si no puede crear el estado (debido a la falta de memoria). El
argumento f es la función de asignación; Lua hace toda la asignación de memoria para este estado a través de
esta función. El segundo argumento, ud, es un indicador opaco que Lua simplemente pasa para la función de
asignación a cada llamada.
lua_newtable
void lua _newtable (lua _State *L);
Crea una nueva tabla vacía y la coloca en la pila. Es equivalente a lua_createtable(L, 0, 0).
lua_newthread
lua _State *lua _newthread (lua _State *L);
Crea un nuevo objeto del tipo thread, lo coloca en la pila y retorna un indicador para un lua_State que representa
este nuevo flujo de ejecución. El nuevo flujo de ejecución retornado por esta función comparte todos los objetos
globales (tales como tablas) con el estado original, pero posee una pila de ejecución independiente.
No hay una función explícita para terminar o destruir un flujo de ejecución. Objetos del tipo thread están sujetos a
la Recolecta de basura, así como cualquier otro objeto de Lua.
lua_newuserdata
void *lua _newuserdata (lua _State *L, size _t size);
Esta función asigna un nuevo bloque de memoria con el tamaño suministrado, coloca en la pila un nuevo objeto
userdata completo con la dirección del bloque y retorna esta dirección.
Objetos userdata representan valores C en Lua. Un userdata completo representa un bloque de memoria. Es un
objeto (así como una tabla): Se debe crear, puede tener su propia meta-tabla y se puede detectar cuando él está
siendo colectado. Un objeto userdata completo solamente es igual al mismo (usando la igualdad primitiva, sin el
uso de meta-métodos).
Cuando Lua colecta un userdata completo con un meta-método gc, Lua llama el meta-método y marca el userdata
como finalizado. Cuando este userdata es colectado nuevamente entonces Lua libera su memoria
correspondiente.
226
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
lua_next
int lua _next (lua _State *L, int index);
Desapila una clave de la pila y apila un par clave-valor de la tabla en el índice suministrado (el "próximo" par
después de la clave suministrada). Si no hay más elementos en la tabla, entonces lua_next retorna 0 (y no apila
nada).
Un recorrido típico se parece con éste:
/* table is in the stack at index `t' */
lua_pushnil(L); /* first key */
while (lua_next(L, t) != 0) {
/* `key' is at index -2 and `value' at index -1 */
printf("%s - %s\n",
lua_typename(L, lua_type(L, -2)), lua_typename(L, lua_type(L, -1)));
lua_pop(L, 1); /* removes `value'; keeps `key' for next iteration */
}
Durante el recorrido de una tabla, no llamar a lua_tolstring directamente sobre una clave, a menos que se sepa
que la clave es realmente una cadena de caracteres. Recordar que lua_tolstring altera el valor en el índice
suministrado; esto confunde la próxima llamada para lua_next.
lua_Number
typedef double lua_Number;
El tipo de números en Lua. Por estándar, es doble, pero se puede alterar en luaconf.h.
A través del archivo de configuración es posible alterar Lua para operar con otro tipo para números (por ejemplo,
float o long).
lua_objlen
size _t lua _objlen (lua _State *L, int index);
Retorna el "tamaño" del valor en el índice aceptable suministrado: Para cadenas de caracteres, éste es el tamaño
de la cadena; para tablas, éste es el resultado del operador de tamaño ('#'); para objetos del tipo userdata, éste es
el tamaño del bloque de memoria asignado para el userdata; para otros valores, el tamaño es 0.
lua_pcall
lua_pcall (lua_State *L, int nargs, int nresults, int errfunc);
Llama una función en modo protegido.
Tanto nargs cuanto nresults poseen el mismo significado que poseían en lua_call. Si no hay errores durante la
llamada, lua_pcall se comporta exactamente como lua_call. Sin embargo, si hay cualquier error, lua_pcall lo
captura, coloca un único valor en la pila (el mensaje de error) y retorna un código de error. Como lua_call,
lua_pcall siempre remueve la función y sus argumentos de la pila.
Si errfunc es 0, entonces el mensaje de error retornado en la pila es exactamente el mensaje de error original. En
caso contrario, errfunc es el índice en la pila de una función de tratamiento de errores. (En la implementación
actual, este índice no puede ser un pseudo-índice.) En el caso de errores de tiempo de ejecución, esta función
será llamada con el mensaje de error y su valor de retorno será el mensaje retornado en la pila por lua_pcall.
© ABNT 2007 - Todos los derechos reservados
227
ABNT NBR 15606-2:2007
Típicamente, la función de tratamiento de errores se utiliza para agregar más información de depuración al
mensaje de error, como un trazo de la pila. Tal información no se puede obtener después del retorno de lua_pcall,
pues en este punto la pila ya fue deshecha.
La función lua_pcall retorna 0 en caso de éxito o uno de los siguientes códigos de error (definidos en lua.h):

LUA_ERRRUN: un error en tiempo de ejecución.

LUA_ERRMEM: error de asignación de memoria. Para tales errores, Lua no llama la función de
tratamiento de errores.

LUA_ERRERR: error durante la ejecución de la función de tratamiento de errores.
lua_pop
void lua_pop (lua_State *L, int n);
Desapila n elementos de la pila.
lua_pushboolean
void lua_pushboolean (lua_State *L, int b);
Apila un valor booleano con valor b en la pila.
lua_pushcclosure
void lua_pushcclosure (lua_State *L, lua_CFunction fn, int n);
Apila un nuevo cierre C en la pila.
Cuando una función C es creada, es posible asociar algunos valores a la misma, creando entonces un cierre C
(ver B.3.5); estos valores son entonces accesibles para la función siempre que es llamada. Para asociar valores
con una función C, primero estos valores se deben colocar en la pila (cuando hay múltiples valores, el primer valor
es apilado primero). Entonces lua_pushcclosure es llamada para crear y colocar la función C en la pila, con el
argumento n informando cuántos valores deben ser asociados con la función. Lua_pushcclosure también desapila
estos valores de la pila.
lua_pushcfunction
void lua _pushcfunction (lua _State *L, lua _CFunction f);
Apila una función C en la pila. Esta función recibe un indicador para una función C y coloca en la pila un valor Lua
del tipo function que, cuando llamado, invoca la función C correspondiente.
Cualquier función para ser registrada en Lua debe seguir el protocolo correcto para recibir sus parámetros y
retornar sus resultados (ver lua_CFunction).
lua_pushcfunction es definida como una macro:
#define lua_pushcfunction(L,f) lua_pushcclosure(L,f,0)
228
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
lua_pushfstring
const char *lua_pushfstring (lua_State *L, const char *fmt, ...);
Coloca en la pila una cadena de caracteres formateada y retorna un indicador para esta cadena. Es análogo a la
función C sprintf, pero posee algunas diferencias importantes:

no es necesario asignar espacio para el resultado: El resultado es una cadena de caracteres y Lua se
encarga de la asignación de memoria (y de la desasignación, a través de la Recolecta de basura);

los especificadores de conversión son bastante limitados. No hay flags, tamaños o precisiones. Los
especificadores de conversión pueden ser solamente '%%' (inserta un '%' en la cadena), '%s' (inserta
una cadena terminada por cero, sin restricciones de tamaño), '%f' (inserta un lua_Number), '%p'
(inserta un indicador como un número hexadecimal), '%d' (inserta un int) y '%c' (inserta un int como un
carácter).
lua_pushinteger
void lua_pushinteger (lua_State *L, lua_Integer n);
Coloca un número con valor n en la pila.
lua_push lightuserdata
void lua_pushlightuserdata (lua_State *L, void *p);
Coloca un objeto del tipo userdata ligero en la pila.
Un userdata representa valores de C en Lua. Un userdata ligero representa un indicador. Es un valor (como un
número): No se puede crear, no posee una meta-tabla individual y no es colectado (ya que nunca fue creado). Un
userdata ligero es igual a "cualquier" userdata ligero con la misma dirección C.
lua_pushlstring
void lua _pushlstring (lua _State *L, const char *s, size _t len);
Apila la cadena de caracteres indicada por s con tamaño len en la pila. Lua crea (o reutiliza) una copia interna de
la cadena suministrada, de tal forma que la memoria indicada por s puede ser liberada o reutilizada
inmediatamente después del retorno de la función. La cadena puede contener ceros dentro de la misma.
lua_pushnil
void lua_pushnil (lua_State *L);
Coloca un valor nil en la pila.
lua_pushnumber
void lua_pushnumber (lua_State *L, lua_Number n);
Coloca un número con valor n en la pila.
© ABNT 2007 - Todos los derechos reservados
229
ABNT NBR 15606-2:2007
lua_pushstring
void lua _pushstring (lua _State *L, const char *s);
Apila la cadena terminada por cero indicada por s en la pila. Lua crea (o reutiliza) una copia interna de la cadena
suministrada, de tal forma que la memoria indicada por s puede ser liberada o reutilizada inmediatamente
después del retorno de la función. La cadena no puede contener ceros dentro de la misma; se presupone que la
cadena termina en el primer cero.
lua_pushthread
void lua _pushthread (lua _State *L);
Apila el flujo de ejecución representado por L en la pila. Retorna 1 si este flujo de ejecución es el flujo de
ejecución principal de su estado.
lua_pushvalue
void lua_pushvalue (lua_State *L, int index);
Apila una copia del elemento en el índice válido suministrado en la pila.
lua_pushvfstring
const char *lua_pushvfstring (lua_State *L, const char *fmt,
va_list argp);
Equivalente a lua_pushfstring, excepto que esta función recibe una va_list en vez de un número variable de
argumentos.
lua_rawequal
int lua _rawequal (lua _State *L, int index1, int index2);
Retorna 1 si los dos valores en los índices aceptables index1 e index2 son iguales primitivamente (es decir, sin
hacer llamadas meta-métodos). En caso contrario retorna 0. También retorna 0 si cualquiera de los índices no es
válido.
lua_rawget
void lua _rawget (lua _State *L, int index);
Análogo a lua_gettable, pero hace un acceso primitivo (o sea, sin usar meta-métodos).
230
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
lua_rawgeti
void lua _rawgeti (lua _State *L, int index, int n);
Coloca en la pila el valor t[n], donde t es el valor en el índice válido suministrado. El acceso es primitivo; es decir,
no invoca meta-métodos.
lua_rawset
void lua _rawset (lua _State *L, int index);
Análogo a lua_settable, pero hace una atribución primitiva (es decir, sin usar meta-métodos).
lua_rawseti
void lua _rawseti (lua _State *L, int index, int n);
Hace el equivalente a t[n] = v, donde t es el valor en el índice válido suministrado y v es el valor en la parte
superior de la pila. Esta función desapila el valor de la pila. La atribución es primitiva; es decir, no invoca metamétodos.
lua_Reader
typedef const char * (*lua_Reader)
(lua _State *L, void *data, size _t *size);
La función de lectura usada por lua_load. Siempre que necesita otro pedazo del trecho, lua_load llama la función
de lectura, pasando junto su parámetro fecha. La función de lectura debe retornar un indicador para un bloque de
memoria con un nuevo pedazo del trecho y atribuir a *size el tamaño del bloque. El bloque debe existir hasta que
la función de lectura sea llamada nuevamente. Para señalizar el fin del trecho, la función de lectura debe retornar
NULL. La función de lectura puede retornar pedazos de cualquier tamaño mayor que cero.
lua_register
void lua _register (lua _State *L, const char *name, lua _CFunction f);
Establece la función C f como el nuevo valor de la global name. Esta función es definida como una macro:
#define lua_register(L,n,f) (lua_pushcfunction(L, f), lua_setglobal(L, n))
lua_remove
void lua _remove (lua _State *L, int index);
Remueve el elemento en el índice válido suministrado, desplazando hacia abajo los elementos arriba de este
índice para rellenar el hueco. Esta función no puede ser llamada con un pseudo-índice, ya que el pseudo-índice
no es una posición real de la pila.
© ABNT 2007 - Todos los derechos reservados
231
ABNT NBR 15606-2:2007
lua_replace
void lua _replace (lua _State *L, int index);
Mueve el elemento de la parte superior para la posición suministrada (y lo desapila), sin desplazar cualquier
elemento (reemplazando por lo tanto el valor en la posición suministrada).
lua_resume
int lua _resume (lua _State *L, int narg);
Inicia y recomienza una co-rutina en un flujo de ejecución.
Para iniciar una co-rutina, se debe primero crear un nuevo flujo de ejecución (ver lua_newthread); a continuación
se debe colocar en su pila la función principal más cualesquiera argumentos; por último es llamado lua_resume,
con narg siendo el número de argumentos. Esta llamada retorna cuando la co-rutina suspende o finaliza su
ejecución. Cuando retorna, la pila contiene todos los valores pasados para lua_yield o todos los valores
retornados por el cuerpo de la función. Lua_resume retorna LUA_YIELD si la co-rutina cede, 0 si la co-rutina
termina su ejecución sin errores o un código de error en el caso de ocurrir errores (ver lua_pcall). En el caso de
errores, la pila no es deshecha, de forma que se puede usar la API de depuración sobre la misma. El mensaje de
error está en la parte superior de la pila. Para reiniciar una co-rutina, se debe colocar en la pila de la misma
solamente los valores a ser pasados como resultados de yield y entonces llamar a lua_resume.
lua_setallocf
void lua _setallocf (lua _State *L, lua _Alloc f, void *ud);
Cambia la función de asignación de un dato estado para f con objeto userdata ud.
lua_setfenv
int lua _setfenv (lua _State *L, int index);
Desapila una tabla de la pila y establece esta tabla como siendo el nuevo ambiente para el valor en el índice
suministrado. Si el valor en el índice suministrado no es una función, ni un flujo de ejecución ni un objeto userdata,
lua_setfenv retorna 0. En caso contrario, la función retorna 1.
lua_setfield
void lua _setfield (lua _State *L, int index, const char *k);
Hace el equivalente a t[k] = v, donde t es el valor en el índice válido suministrado y v es el valor en la parte
superior de la pila.
Esta función desapila el valor de la pila. Como en Lua, esta función puede disparar un meta-método para el evento
"index" (ver B.2.9).
232
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
lua_setg lobal
void lua_setglobal (lua_State *L, const char *name);
Desapila un valor de la pila y lo establece como el nuevo valor de la global name. Esta función es definida como
una macro:
#define lua _setglobal(L,s)
lua _setfield(L, LUA _GLOBALSINDEX, s)
lua_setmetatable
int lua _setmetatable (lua _State *L, int index);
Desapila una tabla de la pila y establece esta tabla como la noticia meta-tabla para el valor en el índice aceptable
suministrado.
lua_settable
void lua_settable (lua_State *L, int index);
Hace el equivalente a t[k] = v, donde t es el valor en el índice válido suministrado, v es el valor en la parte superior
de la pila y k es el valor inmediato abajo de la parte superior.
Esta función desapila tanto la clave como el valor de la pila. De la misma forma que en Lua, esta función puede
disparar un meta-método para el evento "newindex" (ver B.2.9).
lua_settop
void lua _settop (lua _State *L, int index);
Acepta cualquier índice aceptable, o 0, y establece este índice como la parte superior de la pila. Si el nuevo tope
es mayor que el antiguo, entonces los nuevos elementos son rellenados con nil. Si index es 0, entonces todos los
elementos de la pila son removidos.
lua_State
typedef struct lua _State lua _State;
Estructura opaca que guarda el estado completo de un interpretador Lua. La biblioteca de Lua es totalmente
reentrante: No existen variables globales. Toda la información sobre un estado es mantenida en esta estructura.
Un indicador para éste estado debe ser pasado como el primer argumento para toda función en la biblioteca,
excepto para lua_newstate, que crea un nuevo estado Lua desde el cero.
lua_status
int lua_status (lua_State *L); Retorna el estatus del flujo de ejecución L.
El estatus puede ser 0 para un flujo de ejecución normal, un código de error si el flujo de ejecución termina su
ejecución con un error o LUA_YIELD si el flujo de ejecución estuviera suspendido.
© ABNT 2007 - Todos los derechos reservados
233
ABNT NBR 15606-2:2007
lua_toboolean
int lua _toboolean (lua _State *L, int index);
Convierte un valor Lua en el índice aceptable suministrado para un valor booleano C (0 o 1). Como todos los tests
en Lua, lua_toboolean retorna 1 para cualquier valor Lua diferente de false y de nil; en caso contrario la función
retorna 0. La función también retorna 0 cuando llamada con un índice no válido (si se desea aceptar solamente
valores booleanos de hecho, usar lua_isboolean para testar el tipo del valor).
lua_tocfunction
lua _CFunction lua _tocfunction (lua _State *L, int index);
Convierte un valor en el índice aceptable suministrado para una función C. Tal valor debe ser una función C; en
caso contrario, retorna NULL.
lua_tointeger
lua _Integer lua _tointeger (lua _State *L, int idx);
Convierte el valor Lua en el índice aceptable suministrado para el tipo completo con señal lua_Integer. El valor
Lua debe ser un número o una cadena que puede ser convertida para un número (ver B.2.3.2); en caso contrario,
lua_tointeger retorna 0.
Si el número no es un entero, es truncado de alguna manera no especificada.
lua_tolstring
const char *lua _tolstring (lua _State *L, int index, size _t *len);
Convierte el valor Lua en el índice aceptable suministrado para una cadena C. Si len no es NULL, la función
también establece *len como el tamaño de la cadena. El valor Lua debe ser una cadena de caracteres o un
número; en caso contrario, la función retorna NULL. Si el valor es un número, entonces lua_tolstring también
cambia el valor real en la pila para una cadena. (Este cambio confunde lua_next cuando lua_tolstring se aplica a
claves durante un recorrido de tabla.)
lua_tolstring retorna un indicador totalmente alineado para una cadena de caracteres dentro del estado Lua. Esta
cadena siempre tiene un cero ('\0') después de su último carácter (como en C), pero puede contener otros ceros
en su interior. Visto que Lua posee Recolecta de basura, no hay garantía de que el indicador retornado por
lua_tolstring será válido después de ser removido de la pila el valor correspondiente.
lua_tonumber
lua _Number lua _tonumber (lua _State *L, int index);
Convierte el valor Lua en el índice aceptable suministrado para el tipo C lua_Number (ver lua_Number). El valor
Lua debe ser un número o una cadena que puede ser convertida para un número (ver B.2.3.2); en caso contrario,
lua_tonumber retorna 0.
234
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
lua_topointer
const void *lua _topointer (lua _State *L, int index);
Convierte el valor en el índice aceptable suministrado para un indicador C genérico (void*). El valor puede ser un
objeto userdata, una tabla, un flujo de ejecución o una función; objetos diferentes van a suministrar indicadores
diferentes. No hay manera de convertir el indicador de vuelta a su valor original.
Típicamente esta función se utiliza solamente para informaciones de depuración.
lua_tostring
const char *lua_tostring (lua _State *L, int index);
Equivalente a lua_tolstring con len siendo igual a NULL.
lua_tothread
lua_State *lua_tothread (lua_State *L, int index);
Convierte el valor en el índice aceptable suministrado para un flujo de ejecución (representado como lua_State*).
Este valor debe ser un flujo de ejecución; en caso contrario, la función retorna NULL.
lua_touserdata
void *lua _touserdata (lua _State *L, int index);
Si el valor en el índice aceptable suministrado es un objeto userdata completo, la función retorna la dirección de su
bloque. Si el valor es un userdata ligero, la función retorna su indicador. En caso contrario, retorna NULL.
lua_type
int lua _type (lua _State *L, int index);
Retorna el tipo del valor en el índice aceptable suministrado o LUA_TNONE para un índice no válido (es decir, un
índice para una posición de la pila "vacía"). Los tipos retornados por lua_type se codifican por las siguientes
constantes definidas en lua.h: LUA_TNIL, LUA_TNUMBER, LUA_TBOOLEAN, LUA_TSTRING, LUA_TTABLE,
LUA_TFUNCTION, LUA_TUSERDATA, LUA_TTHREAD y LUA_TLIGHTUSERDATA.
lua_typename
const char *lua _typename (lua _State *L, int tp);
Retorna el nombre del tipo codificado por el valor tp, que debe ser uno de los valores retornados por lua_type.
© ABNT 2007 - Todos los derechos reservados
235
ABNT NBR 15606-2:2007
lua_Writer
typedef int (*lua_Writer) (lua_State *L, const void* p, size_t sz, void* ud);
El tipo de la función de escritura usada por lua_dump. Siempre que la misma produce otro pedazo de trecho,
lua_dump llama la función de grabación, pasando junto el buffer a ser escrito (p), su tamaño (sz) y el parámetro
fecha suministrado para lua_dump.
La función de grabación retorna un código de error: 0 significa ningún error; cualquier otro valor significa un error y
hace lua_dump parar de llamar la función de grabación.
lua_xmove
void lua_xmove (lua_State *from, lua_State *to, int n);
Cambia valores entre diferentes flujos de ejecución del mismo estado global. Esta función desapila n valores de la
pila from y los apila en la pila to.
lua_yield
int lua _yield (lua _State *L, int nresults);
Cede una co-rutina.
Esta función solamente debe ser llamada como la expresión de retorno de una función C, de la siguiente forma:
return lua _yield (L, nresults);
Cuando una función C llama a lua_yield de esta manera, la co-rutina siendo ejecutada suspende su ejecución y
la llamada a lua_resume que inició esta co-rutina retorna. El parámetro results es el número de valores de la pila
que son pasados como resultados para lua_resume.
B.3.9 Interfaz de depuración
Lua no posee mecanismos de depuración pre-definidos. En vez de eso, ofrece una interfaz especial por medio de
funciones y ganchos. Esta interfaz permite la construcción de diferentes tipos de depuradores, medidores y otras
herramientas que necesitan "información interna" del interpretador.
lua_Debug
typedef struct lua_Debug {
int event;
const char *name;
/* (n) */
const char *namewhat;
/* (n) */
const char *what;
/* (S) */
const char *source;
/* (S) */
int currentline;
/* (l) */
int nups;
/* (u) number of upvalues */
int linedefined;
/* (S) */
int lastlinedefined;
/* (S) */
char short_src[LUA_IDSIZE]; /* (S) */
/* private part */
...
} lua_Debug;
236
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
Una estructura usada para guardar diferentes pedazos de información sobre una función activa. Lua_getstack
rellena solamente la parte privada de esta estructura, para uso posterior. Para rellenar los otros campos de
lua_Debug con información útil, llamar a lua_getinfo.
Los campos de lua_Debug poseen el siguiente significado:

source: si la función fue definida en una cadena de caracteres, entonces source es esa cadena. Si la
función fue definida en un archivo, entonces source empieza con un '@' seguido por el nombre del
archivo;

short_src: una versión "adecuada" para impresión de source, para ser usada en mensajes de error;

linedefined: el número de la línea donde la definición de la función empieza;

lastlinedefined: el número de la línea donde la definición de la función termina;

what: la cadena "Lua" si la función es una función Lua, "C" si es una función C, "main" si es la parte
principal de un trecho y "tail" si fue una función que hizo una recursión final. En el último caso, Lua no
posee ninguna otra información sobre la función;

currentline: la línea corriente donde la función suministrada está siendo ejecutada. Cuando ninguna
información sobre la línea está disponible, se atribuye -1 a currentline;

name: un nombre razonable para la función suministrada. Dado que funciones en Lua son valores de
primera clase, las mismas no poseen un nombre fijo: Algunas funciones pueden ser el valor de
múltiples variables globales, mientras otras pueden estar almacenadas solamente en un campo de una
tabla. La función lua_getinfo verifica cómo la función fue llamada para encontrar un nombre adecuado.
Si no es posible encontrar un nombre, entonces se atribuye NULL a name;

namewhat: explica el campo name. El valor de namewhat puede ser "global", "local", "method", "field",
"upvalue" o "" (la cadena vacía), de acuerdo con cómo la función fue llamada (Lua usa la cadena vacía
cuando ninguna otra opción parece aplicarse);

nups: el número de upvalues de la función.
lua_gethook
lua_Hook lua_gethook (lua_State *L);
Retorna la función gancho actual.
lua_gethookcount
int lua_gethookcount (lua_State *L);
Retorna el conteo de gancho actual.
lua_gethookmask
Int lua_gethookmask (lua_State *L);
Retorna la máscara de gancho actual.
© ABNT 2007 - Todos los derechos reservados
237
ABNT NBR 15606-2:2007
lua_getinfo
int lua_getinfo (lua_State *L, const char *what, lua_Debug *ar);
Retorna información sobre una función específica o una invocación de función específica.
Para obtener información sobre una invocación de función, el parámetro ar debe ser un registro de activación
válido que fue rellenado por una llamada anterior a lua_getstack o fue suministrado como argumento para un
gancho (ver lua_Hook).
Para obtener información sobre una función se debe colocar en la pila e iniciar la cadena what con el carácter '>'.
(En este caso, lua_getinfo desapila la función en la parte superior de la pila.) Por ejemplo, para saber en cuál
línea una función f fue definida, se puede escribir el siguiente código:
lua _Debug ar;
lua _getfield(L, LUA _GLOBALSINDEX, "f"); /* get global `f' */
lua _getinfo(L, ">S", &ar);
printf("%d\n", ar.linedefined);
Cada carácter en la cadena what selecciona algunos campos de la estructura ar para ser rellenados o un valor a
ser apilado en la pila:

'n': rellena los campos name y namewhat;

'S': rellena los campos source, short_src, linedefined, lastlinedefined y what;

'l': rellena el campo currentline;

'u': rellena el campo nups;

'f': coloca en la pila la función que está ejecutando en el nivel suministrado;

'L': coloca en la pila una tabla cuyos índices son el número de las líneas que son válidas en la función
(una línea válida es una línea con algún código asociado, es decir, una línea donde se puede colocar
un punto de parada. Líneas no válidas incluyen líneas vacías y comentarios).
Esta función retorna 0 en caso de error (por ejemplo, en el caso de una opción inválida en what).
lua_getlocal
const char *lua_getlocal (lua_State *L, const lua_Debug *aire, int n);
Obtiene información sobre una variable local de un registro de activación suministrado. El parámetro ar debe ser
un registro de activación válido que fue rellenado por una llamada anterior a lua_getstack o fue suministrado como
un argumento para un gancho (ver lua_Hook). El índice n selecciona cuál variable local inspeccionar (1 es el
primer parámetro o variable local activa y así sucesivamente, hasta la última variable local activa). lua_getlocal
coloca el valor de la variable en la pila y retorna el nombre de la misma.
Nombres de variables empezando con '(' (abre paréntesis) representan variables internas (variables de control de
lazos, temporales y funciones C locales.).
Retorna NULL (y no apila nada) cuando el índice es mayor que el número de variables locales activas.
lua_getstack
int lua_getstack (lua_State *L, int level, lua_Debug *aire);
Obtiene información sobre la pila de tiempo de ejecución del interpretador.
238
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
Esta función rellena partes de una estructura lua_Debug con una identificación del registro de activación de la
función ejecutando en un dado nivel. El nivel 0 es la función ejecutando actualmente, al tiempo que el nivel n+1 es
la función que llamó el nivel N. Cuando no hay errores, lua_getstack retorna 1; cuando es llamada con un nivel
mayor que la profundidad de la pila, la función retorna 0.
lua_getupvalue
const char *lua _getupvalue (lua _State *L, int funcindex, int n);
Obtiene información sobre un upvalue de un cierre (para funciones Lua, upvalues son variables locales externas
que la función usa y que son conceptualmente incluidas en el cierre de la misma). lua_getupvalue obtiene el
índice n de un upvalue, coloca el valor del upvalue en la pila y retorna su nombre. Funcindex apunta para el cierre
en la pila (upvalues no poseen un orden específico, ya que son activos a lo largo de toda la función. Entonces,
son numerados en un orden arbitrario).
Retorna NULL (y no apila nada) cuando el índice es mayor que el número de upvalues. Para funciones C, esta
función usa la cadena vacía "" como un nombre para todo el upvalues.
lua_Hook
typedef void (*lua_Hook) (lua_State *L, lua_Debug *aire);
El tipo para funciones de gancho de depuración.
Siempre que un gancho es llamado, se atribuye al campo event de su argumento ar el evento específico que
disparó el gancho. Lua identifica estos eventos con las siguientes constantes: LUA_HOOKCALL, LUA_HOOKRET,
LUA_HOOKTAILRET, LUA_HOOKLINE y LUA_HOOKCOUNT. Además de ello, para eventos de línea, el campo
currentline también es atribuido. Para obtener el valor de cualquier campo en ar, el gancho debe llamar a
lua_getinfo. Para eventos de retorno, event puede ser LUA_HOOKRET, el valor normal, o LUA_HOOKTAILRET.
En el último caso, Lua está simulando un retorno de una función que hizo una recursión final; en este caso, es
inútil llamar a lua_getinfo.
Mientras Lua está ejecutando un gancho, deshabilita otras llamadas ganchos. Por lo tanto, si un gancho llama a
Lua de vuelta para ejecutar una función o un trecho, esta ejecución ocurre sin cualesquiera llamadas a ganchos.
lua_sethook
int lua_sethook (lua_State *L, lua_Hook func, int mask, int count);
Establece la función de gancho de depuración.
El argumento f es una función de gancho. Mask especifica sobre para cuáles eventos el gancho será llamado: es
formado por una conjunción bit-a-bit de las constantes LUA_MASKCALL, LUA_MASKRET, LUA_MASKLINE y
LUA_MASKCOUNT. el argumento count solamente tiene significado cuando la máscara incluye
LUA_MASKCOUNT. Para cada evento, el gancho es llamado como explicado a continuación:

el gancho de llamada (CALL): es llamado cuando el interpretador llama una función. El gancho es
llamado después de Lua entrar en la nueva función, antes de la función recibir sus argumentos;

el gancho de retorno (RET): es llamado cuando el interpretador retorna de una función. El gancho es
llamado después de Lua salir de la función. No se tiene acceso a los valores a ser retornados por la
función;

el gancho de línea (LINE): es llamado cuando el interpretador está por iniciar la ejecución de una nueva
línea de código o cuando vuelve atrás en el código (aunque sea a la misma línea) (este evento solamente
ocurre cuando Lua está ejecutando una función Lua;
© ABNT 2007 - Todos los derechos reservados
239
ABNT NBR 15606-2:2007

el gancho del lua (COUNT): es llamado después del interpretador ejecutar cada una de las instrucciones
count (este evento solamente ocurre cuando Lua está ejecutando una función Lua).
Un gancho es desactivado atribuyéndose cero a mask.
lua_setlocal
const char *lua _setlocal (lua _State *L, const lua _Debug *ar, int n);
Establece el valor de una variable local de un registro de activación suministrado. Los parámetros ar y n son como
en lua_getlocal (ver lua_getlocal). lua_setlocal atribuye el valor en la parte superior de la pila a la variable y
retorna el nombre de la misma. La función también desapila el valor de la pila.
Retorna NULL (y no desapila nada) cuando el índice es mayor que el número de variables locales activas.
lua_setupvalue
const char *lua _setupvalue (lua _State *L, int funcindex, int n);
Establece el valor de un upvalue de un cierre. La función atribuye el valor en la parte superior de la pila al upvalue
y retorna su nombre. La misma también desapila el valor de la pila. Los parámetros funcindex y n son como en la
función lua_getupvalue (ver lua_getup value).
Retorna NULL (y no desapila nada) cuando el índice es mayor que el número de upvalues.
B.4 Biblioteca auxiliar
B.4.1 Conceptos básicos
La biblioteca auxiliar suministra varias funciones convenientes para la interfaz de C con Lua. Mientras la API
básica suministra las funciones primitivas para todas las interacciones entre C y Lua, la biblioteca auxiliar
suministra funciones del más alto nivel para algunas tareas comunes.
Todas las funciones de la biblioteca auxiliar son definidas en el archivo de encabezamiento lauxlib.h y poseen un
código luaL_.
Todas las funciones en la biblioteca auxiliar son construidas sobre la API básica y por lo tanto las mismas no
ofrecen nada que no se pueda hacer con la API básica.
Varias funciones en la biblioteca auxiliar son usadas para verificar argumentos de funciones C. El nombre de las
mismas siempre es luaL_check* o luaL_opt*. Todas esas funciones disparan un error si la verificación no se
realiza. Visto que el mensaje de error es formateado para argumentos (por ejemplo, "bad argument #1"), no se
debe usar estas funciones para otros valores de la pila.
B.4.2 Funciones y tipos
Todas las funciones y tipos de la biblioteca auxiliar son listadas a continuación en orden alfabético.
luaL_addchar
void luaL_addchar (luaL_Buffer B, char c);
Agrega el carácter c al buffer B (ver luaL_Buffer).
240
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
luaL_addlstring
void luaL _addlstring (luaL _Buffer *B, const char *s, size _t l);
Agrega la cadena de caracteres indicada por s con tamaño l al buffer B (ver luaL_Buffer). La cadena puede
contener ceros en su interior.
luaL_addsize
void luaL _addsize (luaL _Buffer B, size _t n);
Agrega al buffer B (ver luaL_Buffer) una cadena de largo n copiada anteriormente para el área de buffer (ver
luaL_prepbuffer).
luaL_addstring
void luaL _addstring (luaL _Buffer *B, const char *s);
Agrega la cadena terminada por 0 indicada por s al buffer B (ver luaL_Buffer). La cadena no puede contener
ceros dentro de la misma.
luaL_addvalue
void luaL _addvalue (luaL _Buffer *B);
Agrega el valor en la parte superior de la pila al buffer B (ver luaL_Buffer). Desapila el valor.
Ésta es la única función sobre buffers de cadenas que debe ser llamada con un elemento extra en la pila, que es
el valor a ser agregado al buffer.
lua L_arg check
void luaL _argcheck (lua _State *L, int cond, int numarg, const char *extramsg);
Verifica si cond es verdadera. Si no, dispara un error con el siguiente mensaje, donde func es recobrada desde la
pila de llamada:
bad argument #<narg> to <func> (<extramsg>)
© ABNT 2007 - Todos los derechos reservados
241
ABNT NBR 15606-2:2007
luaL_argerror
int luaL_argerror (lua_State *L, int numarg, const char *extramsg);
Dispara un error con el siguiente mensaje, donde func es recobrada desde la pila de llamada:
bad argument #<narg> to <func> (<extramsg>)
Esta función nunca retorna, pero es idiomático usarla en funciones C como return luaL_argerror(args).
luaL_Buffer
typedef struct luaL _Buffer luaL _Buffer;
El tipo para un buffer de cadena de caracteres.
Un buffer de cadena permite al código C construir cadenas Lua poco a poco. Su estándar de uso es el siguiente:

primero se declara una variable b del tipo luaL_Buffer;

a continuación se inicializa la variable con una llamada luaL_buffinit(L, &b);

después se agregan pedazos de la cadena al buffer llamando a cualquiera de las funciones luaL_add*;

se termina haciendo una llamada luaL_pushresult(&b). Esta llamada deja la cadena final en la parte
superior de la pila.
Durante esa operación normal, un buffer de cadena usa un número variable de posiciones de la pila. Entonces,
cuando se está usando un buffer, no se debe asumir que sabe dónde está la parte superior de la pila. Se puede
usar la pila entre llamadas sucesivas a las operaciones de buffer desde que este uso sea equilibrado; es decir,
cuando es llamada una operación de buffer, la pila está en el mismo nivel en el que estaba inmediatamente
después de la operación de buffer anterior (la única excepción a esta regla es luaL_addvalue). Después de llamar
a luaL_pushresult, la pila está de vuelta a su nivel cuando el buffer fue inicializado, más la cadena final en su tope.
luaL_buffinit
void luaL _buffinit (lua _State *L, luaL _Buffer *B);
Inicializa un buffer B. Esta función no asigna cualquier espacio; el buffer debe ser declarado como una variable
(ver luaL_Buffer).
luaL_callmeta
int luaL_callmeta (lua_State *L, int obj, const char *met);
Llama un meta-método.
Si el objeto en el índice obj posee una meta-tabla y esta meta-tabla posee un campo y, esta función llama ese
campo y pasa el objeto como su único argumento. En este caso esta función retorna 1 y coloca en la pila el valor
retornado por la llamada. Si no hay meta-tabla o meta-método, esta función retorna 0 (sin apilar cualquier valor en
la pila).
242
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
luaL_checkany
void luaL _checkany (lua _State *L, int narg);
Verifica si la función tiene un argumento de cualquier tipo (incluyendo nil) en la posición narg.
luaL_checkint
int luaL _checkint (lua _State *L, int narg);
Verifica si el argumento narg de la función es un número y retorna este número convertido para un int.
luaL_checkinteger
lua _Integer luaL _checkinteger (lua _State *L, int narg);
Verifica si el argumento narg de la función es un número y retorna este número convertido para un lua_Integer.
luaL_checklong
long luaL_checklong (lua_State *L, int narg);
Verifica si el argumento narg de la función es un número y retorna este número convertido para un long.
luaL_checklstring
const char *luaL _checklstring (lua _State *L, int narg, size _t *l);
Verifica si el argumento narg de la función es una cadena y retorna esta cadena; si l no es NULL rellena *l con el
tamaño de la cadena.
luaL_checknumber
lua_Number luaL_checknumber (lua_State *L, int narg);
Verifica si el argumento narg de la función es un número y retorna este número.
luaL_checkoption
int luaL_checkoption
*const lst[]);
(lua_State
*L,
int
narg,
const
char
*def,
const
char
Verifica si el argumento narg de la función es una cadena y busca por esta cadena en el array lst (lo cual debe ser
terminado por NULL). Retorna el índice en el array donde la cadena fue encontrada. Dispara un error si el
argumento no es una cadena o si la cadena no pudo ser encontrada.
© ABNT 2007 - Todos los derechos reservados
243
ABNT NBR 15606-2:2007
Si def no es NULL, la función usa def como un valor estándar cuando no hay argumento narg o si este argumento
es nil.
Ésta es una función útil para mapear cadenas para enumeraciones de C (la convención usual en bibliotecas Lua
es usar cadenas en vez de números para seleccionar opciones).
luaL_checkstack
void luaL _checkstack (lua _State *L, int sz, const char *msg);
Aumenta el tamaño de la pila para Top + sz elementos, disparando un error si la pila no puede ser aumentada
para aquel tamaño. Msg es un texto adicional a ser colocado en el mensaje de error.
luaL_checkstring
const char *luaL_checkstring (lua_State *L, int narg);
Verifica si el argumento narg de la función es una cadena y retorna esta cadena.
luaL_checktype
void luaL _checktype (lua _State *L, int narg, int t);
Verifica si el argumento narg de la función tiene tipo T. Ver lua_type para la codificación de tipos para t.
luaL_checkudata
void *luaL _checkudata (lua _State *L, int narg, const char *tname);
Verifica si el argumento narg de la función es un objeto userdata del tipo tname (ver luaL_newmetatable).
luaL_dofile
int luaL _dofile (lua _State *L, const char *filename);
Carga y ejecuta el archivo suministrado. Es definida como la siguiente macro:
(LuaL_loadfile(L, filename) || lua_pcall(L, 0, LUA_MULTRET, _0))
La función retorna 0 si no hay errores o 1 en caso de errores.
244
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
luaL_dostring
void *luaL_checkudata (lua_State *L, int narg, const char *tname);
Carga y ejecuta la cadena suministrada. Es definida como la siguiente macro:
(LuaL_loadstring(L, str) || lua_pcall(L, 0, LUA_MULTRET, _0))
La función retorna 0 si no hay errores o 1 en caso de errores.
luaL_error
int luaL _error (lua _State *L, const char *fmt, ...);
Dispara un error. El formato del mensaje de error se da por fmt más cualesquiera argumentos extras, siguiendo
las mismas reglas de lua_pushfstring. También agrega en el inicio del mensaje el nombre del archivo y el número
de la línea donde el error ocurrió, caso esta información esté disponible.
Esta función nunca retorna, pero es idiomático usarla en funciones C como return luaL_error(args).
luaL_getmetafield
int luaL _getmetafield (lua _State *L, int obj, const char *met);
Coloca en la pila el campo e de la meta-tabla del objeto en el índice obj. Si el objeto no posee una meta-tabla o si
la meta-tabla no posee este campo, retorna 0 y no apila nada.
luaL_getmetatable
void luaL_getmetatable (lua_State *L, const char *tname);
Coloca en la pila la meta-tabla asociada con el nombre tname en el registro (ver luaL_newmetatable).
luaL_gsub
const char *luaL _gsub (lua _State *L, const char *s, const char *p, const char *r);
Crea una copia de la cadena s reemplazando cualquier ocurrencia de la cadena p por la cadena R. Coloca la
cadena resultante en la pila y a retorna.
© ABNT 2007 - Todos los derechos reservados
245
ABNT NBR 15606-2:2007
luaL_loadbuffer
int luaL _loadbuffer (lua _State *L, const char *buff, size _t sz, const char *name);
Carga un buffer como un trecho de código Lua. Esta función usa lua_load para cargar el trecho en el buffer
indicado por buff con tamaño sz.
Esta función retorna los mismos resultados de lua_load. Name es el nombre del trecho, usado para informaciones
de depuración y mensajes de error.
luaL_loadfile
int luaL _loadfile (lua _State *L, const char *filename);
Carga un archivo como un trecho de código Lua. Esta función usa lua_load para cargar el trecho en el archivo
llamado filename. Si filename es NULL, entonces carga desde la entrada estándar. La primera línea en el archivo
es ignorada si empieza con #.
Esta función retorna los mismos resultados de lua_load, pero posee un código de error extra LUA_ERRFILE si no
puede abrir/leer el archivo.
De la misma forma que lua_load, esta función solamente carga el trecho; no lo ejecuta.
luaL_loadstring
int luaL _loadstring (lua _State *L, const char *s);
Carga una cadena como un trecho de código Lua. Esta función usa lua_load para cargar el trecho en la cadena
(terminada por cero) S.
Esta función retorna los mismos resultados de lua_load.
Así como lua_load, esta función solamente carga el trecho; no lo ejecuta.
luaL_newmetatable
int luaL _newmetatable (lua _State *L, const char *tname);
Si el registro ya posee la llave tname, retorna 0. En caso contrario, crea una nueva tabla para ser usada como
una meta-tabla para el objeto userdata, agrega esta tabla al registro con clave tname y retorna 1.
En ambos casos coloca en la pila el valor final asociado con tname en el registro.
246
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
luaL_newstate
lua_State *luaL_newstate (void);
Crea un nuevo estado Lua. Llama a lua_newstate con una función de asignación con base en la función estándar
de C realloc y entonces establece una función de pánico (ver lua_atpanic) que imprime un mensaje de error para
la salida de error estándar en caso de errores fatales.
Retorna el nuevo estado o NULL si ocurrió un error de asignación de memoria.
luaL_openlibs
void luaL_openlibs (lua_State *L);
Abre todas las bibliotecas estándares en el estado suministrado.
luaL_optint
int luaL _optint (lua _State *L, int narg, int d);
Si el argumento narg de la función es un número, retorna este número convertido para un int. Si este argumento
está ausente o si o es nil, retorna d. En caso contrario, dispara un error.
luaL_optinteger
lua_Integer luaL_optinteger (lua_State *L, int narg, lua_Integer d);
Si el argumento narg de la función es un número, retorna este número convertido para un lua_Integer. Si este
argumento está ausente o si o es nil, retorna d. En caso contrario, dispara un error.
luaL_optlong
long luaL _optlong (lua _State *L, int narg, long d);
Si el argumento narg de la función es un número, retorna este número convertido para un long. Si este argumento
está ausente o si o es nil, retorna d. En caso contrario, dispara un error.
luaL_optlstring
const char *luaL_optlstring (lua_State *L, int narg, const char *d, size_t *l);
Si el argumento narg de la función es una cadena, retorna esta cadena. Si este argumento está ausente o si o es
nil, retorna d. En caso contrario, dispara un error.
Si l no es NULL, rellena la posición *l con el tamaño del resultado.
© ABNT 2007 - Todos los derechos reservados
247
ABNT NBR 15606-2:2007
luaL_optnumber
lua_Number luaL_optnumber (lua_State *L, int narg, lua_Number d);
Si el argumento narg de la función es un número, retorna este número. Si este argumento está ausente o si o es
nil, retorna d. En caso contrario, dispara un error.
luaL_optstring
const char *luaL _optstring (lua _State *L, int narg, const char *d);
Si el argumento narg de la función es una cadena, retorna esta cadena. Si este argumento está ausente o si o es
nil, retorna d. En caso contrario, dispara un error.
luaL_prepbuffer
char *luaL _prepbuffer (luaL _Buffer *B);
Retorna una dirección para un espacio de tamaño LUAL_BUFFERSIZE donde se puede copiar una cadena para
ser agregada al buffer B (ver luaL_Buffer). Después de copiar la cadena para este espacio se debe llamar a
luaL_addsize con el tamaño de la cadena para agregarla realmente al buffer.
luaL_pushresult
void luaL_pushresult (luaL_Buffer *B);
Finaliza el uso del buffer B dejando la cadena final en la parte superior de la pila.
luaL_ref
int luaL _ref (lua _State *L, int t);
Crea y retorna una referencia, en la tabla en el índice t, para el objeto en la parte superior de la pila (y desapila el
objeto).
Una referencia es una clave entera única. Desde que no se agregue manualmente claves enteras en la tabla t,
luaL_ref garantiza la unicidad de la clave que retorna. Se puede recobrar un objeto referido por el referencia r
llamando a lua_rawgeti(L, t, r). La función luaL_unref libera una referencia y el objeto asociado a la misma.
Si el objeto en la parte superior de la pila es nil, luaL_ref retorna la constante LUA_REFNIL. La constante
LUA_NOREF es totalmente diferente de cualquier referencia retornada por luaL_ref.
248
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
luaL_Reg
typedef struct luaL_Reg {
const char *name;
lua _CFunction func;
} luaL _Reg;
El tipo para arrays de funciones a ser registrados por luaL_register. Name es el nombre de la función y func es un
indicador para la función. Cualquier array de luaL_Reg debe terminar con una entrada centinela en la cual tanto
name como func son NULL.
luaL_register
void luaL _register (lua _State *L, const char *libname, const luaL _Reg *l);
Abre una biblioteca.
Cuando llamada con libname igual a NULL, simplemente registra todas las funciones en la lista l (ver luaL_Reg)
en la tabla en la parte superior de la pila.
Cuando llamada con un valor de libname diferente de NULL, luaL_register crea una nueva tabla t, establece la
misma como el valor de la variable global libname, la establece como el valor de package.loaded[libname] y
registra en la misma todas las funciones en la lista L. si existe una tabla en package.loaded[libname] o en la
variable libname, la función reutiliza esta tabla en vez de crear una noticia.
En cualquier caso la función deja la tabla en la parte superior de la pila.
luaL_typename
const char *luaL_typename (lua_State *L, int idx);
Retorna el nombre del tipo del valor en el índice suministrado.
luaL_typerror
int luaL_typerror (lua_State *L, int narg, const char *tname);
Genera un error con un mensaje como el siguiente:
l o c a t i o n : bad argument n a r g to ' f u n c ' ( t n a m e expected, got r t )
Donde location es producida por luaL_where, func es el nombre de la función corriente y rt es el nombre del tipo
del argumento.
© ABNT 2007 - Todos los derechos reservados
249
ABNT NBR 15606-2:2007
luaL_unref
void luaL _unref (lua _State *L, int t, int ref);
Libera la referencia ref de la tabla en el índice t (ver luaL_ref). La entrada es removida de la tabla, de modo que el
objeto mencionado puede ser colectado. La referencia ref también es liberada para ser usada nuevamente.
Si ref es LUA_NOREF o LUA_REFNIL, luaL_unref no hace nada.
luaL_where
void luaL _where (lua _State *L, int lvl);
Coloca en la pila una cadena identificando la posición actual del control en el nivel lvl en la pila de llamada.
Típicamente esta cadena posee el siguiente formato:
chunkname: currentline:
Nivel 0 es la función ejecutando corrientemente, nivel 1 es la función que llamó la función que está ejecutando
actualmente, etc.
Esta función se utiliza para construir un código para mensajes de error.
B.5 Bibliotecas estándar
B.5.1 Visión general
Las bibliotecas estándar de Lua ofrecen funciones útiles que son implementadas directamente a través de la API
C. Algunas de esas funciones ofrecen servicios esenciales para el lenguaje (por ejemplo, type y getmetatable);
otras ofrecen acceso a servicios "externos" (por ejemplo, E/S); y otras podrían ser implementadas en Lua
concretamente, pero son bastante útiles o poseen requisitos de desempeño críticos que merecen una
implementación en C (por ejemplo, table.sort).
Todas las bibliotecas son implementadas a través de la API C oficial y son suministradas como módulos C
separados. Normalmente, Lua posee las siguientes bibliotecas estándar:
250

biblioteca básica;

biblioteca de paquetes;

manipulación de cadenas de caracteres;

manipulación de tablas;

funciones matemáticas (sen, log, etc.);

entrada y salida;

facilidades del sistema operativo;

facilidades de depuración.
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
Exceptuándose la biblioteca básica y la biblioteca de paquetes, cada biblioteca provee todas sus funciones como
campos de una tabla global o como métodos de sus objetos.
Para tener acceso a esas bibliotecas, el programa hospedero C debe llamar la función luaL_openlibs, que abre
todas las bibliotecas estándar. De modo alternativo, es posible abrirlas individualmente llamando a luaopen_base
(para la biblioteca básica), luaopen_package (para la biblioteca de paquetes), luaopen_string (para la biblioteca
de cadenas de caracteres), luaopen_table (para la biblioteca de tablas), luaopen_math (para la biblioteca
matemática), luaopen_io (para la biblioteca de E/S), luaopen_os (para la biblioteca del Sistema Operativo), y
luaopen_debug (para la biblioteca de depuración). Esas funciones están declaradas en lualib.h y no deben ser
llamadas directamente: Se deben llamar como cualquier otra función C de Lua, por ejemplo, usando lua_call.
B.5.2 Funciones básicas
La biblioteca de funciones básicas ofrece algunas funciones esenciales la Lua. Si no se incluye esta biblioteca en
su aplicación, se debe verificar cuidadosamente si necesita suministrar implementaciones para algunas de sus
facilidades.
assert (v [, message])
Producen un error cuando el valor de su argumento v es falso (ejemplo, nil o false); en caso contrario, retorna
todos sus argumentos. Message es un mensaje de error; cuándo ausente, el mensaje estándar es "¡assertion
failed!"
collectgarbage (opt [, arg])
Esta función es una interfaz genérica para el colector de basura. Realiza diferentes funciones de acuerdo con su
primer argumento, opt:

“stop” : interrumpe el colector de basura.

“restart” : reinicia el colector de basura.

“collect” : realiza un ciclo de Recolecta de basura completa.

“count” : retorna la memoria total que está siendo usada por Lua (en Kbytes).

“step” : realiza un paso de recolecta de basura. El "tamaño" del paso es controlado por arg (valores
mayores significan más pasos) de manera no especificada. Si se desea controlar el tamaño del paso, se
debe ajustar de manera experimental el valor de arg. Retorna true si el paso terminó un ciclo de
Recolecta de basura.

“steppause” : establece arg/100 como el nuevo valor para la pausa del colector (ver B.2.1 1).

“setstepmul” : establece arg/100 como el nuevo valor para el multiplicador de paso del colector (ver
B.2.1 1).
dofile (filename)
Abre el archivo indicado y ejecuta su contenido como un trecho de código Lua. Cuando es llamada sin
argumentos, dofile ejecuta el contenido de la entrada estándar (stdin). Retorna todos los valores retornados por el
trecho. En caso de errores, dofile propaga el error para su llamador (es decir, dofile no ejecuta en modo protegido).
© ABNT 2007 - Todos los derechos reservados
251
ABNT NBR 15606-2:2007
error (message [, level])
Termina la última función protegida llamada y retorna message como el mensaje de error. La función error nunca
retorna.
Generalmente, error agrega alguna información sobre la posición del error en el inicio del mensaje. El argumento
level especifica cómo obtener la posición del error. Cuando éste es igual a 1 (el estándar), la posición del error es
donde la función error fue llamada. Cuando éste es 2, la posición del error es donde la función que llamó a error
fue llamada; y así sucesivamente. Pasando un valor 0 para level evita la adición de información de la posición del
error al mensaje.
_G
Una variable global (no una función) que almacena el ambiente global (es decir, _G._G = _G). Lua por sí solo no
usa esta variable; una modificación de su valor no afecta cualquier ambiente y viceversa. (usar setfenv para
alterar ambientes.)
getfenv (f)
Retorna el ambiente que está siendo usado normalmente por la función. F puede ser una función Lua o un
número que especifica la función en aquel nivel de pila: La función que llamó a getfenv posee nivel 1. Si la función
suministrada no es una función Lua o se f es 0, getfenv retorna el ambiente global. El valor estándar para f es 1.
getmetatable (object)
Si object no posee una meta-tabla, retorna nil. En caso contrario, si la meta-tabla del objeto posee un campo
"__metatable", retorna el valor asociado. En caso contrario, retorna la meta-tabla del objeto suministrado.
ipairs (t)
Retorna tres valores: una función repetidora, la tabla t y 0, de modo que la construcción
for i,v in ipairs(t) do b o d y end
Repetirá sobre los pares (1,t [1]), (2,t[2]), ···, hasta la primera clave entera ausente de la tabla.
load (func [, chunkname])
Carga un trecho usando la función func para obtener sus pedazos. Cada llamada a func debe retornar una
cadena de caracteres que concatena con resultados anteriores. Cuando func retorna nil (o cuando no retorna
ningún valor), eso indica el fin del trecho.
Si no ocurren errores, retorna el trecho compilado como una función; en caso contrario, retorna nil más el
mensaje de error. El ambiente de la función retornada es el ambiente global.
chunkname se utiliza como el nombre del trecho para mensajes de error e información de depuración. Cuando
ausente, el valor estándar es "=(load)".
252
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
loadfile ([filename])
Análogo a load, pero obtiene el trecho del archivo filename o de la entrada estándar, si ningún nombre de archivo
se suministra.
loadstring (string [, chunkname])
Análogo a load, pero obtiene el trecho de la cadena suministrada.
Para cargar y rodar una dada cadena, usar la expresión idiomática
assert (loadstring(s)) ()
Cuando está ausente, el valor estándar para chunkname es la cadena suministrada.
next (table [, index])
Permite a un programa recorrer todos los campos de una tabla. Su primer argumento es una tabla y su segundo
argumento es un índice en esa tabla. Next retorna el próximo índice de la tabla y su valor asociado. Cuando
llamada con nil como su segundo argumento, next retorna un índice inicial y su valor asociado. Cuando llamada
con el último índice o con nil en una tabla vacía, next retorna nil. Si el segundo argumento está ausente,
entonces éste es interpretado como nil. En particular, se puede usar next(t) para verificar si la tabla está vacía.
El orden en el cual los índices son enumerados no se especifica, incluso para índices numéricos (para recorrer
una tabla en orden numérico, use el for numérico o la función ipairs).
El comportamiento de next es indefinido si, durante el recorrido, se atribuye cualquier valor a un campo no
existente en la tabla. Se puede, sin embargo, modificar campos existentes. En particular, se puede limpiar
campos existentes.
pairs (t)
Retorna tres valores: la función next, la tabla t y nil, de modo que la construcción
for k,v in pairs(t) do body end
Repetirá sobre todos los pares clave–valor de la tabla t.
Ver la función next para los cuidados que se deben tener al modificar la tabla durante su recorrido.
pcall (f, arg1, arg2, ...)
Llama la función f con los argumentos suministrados en modo protegido. Esto significa que cualquier error dentro
de f no es propagado; en vez de eso, pcall captura el error y retorna un código indicando el estatus. Su primer
resultado es el código de estatus (un booleano), que es verdadero si la llamada ocurrió sin errores. En este caso,
pcall también retorna todos los resultados de la llamada, después de este primer resultado. En el caso de ocurrir
un error, pcall retorna false más el mensaje de error.
© ABNT 2007 - Todos los derechos reservados
253
ABNT NBR 15606-2:2007
print (e1, e2, ...)
Recibe cualquier número de argumentos e imprime sus valores para stdout, usando la función tostring para
convertirlos en cadenas de caracteres. Print no es proyectada para salida formateada, sino solamente como una
manera rápida de mostrar un valor, típicamente para depuración. Para salida formateada, use string.format.
rawequal (v1, v2)
Verifica si v1 es igual a v2, sin invocar ningún meta-método. Retorna un booleano.
rawget (table, index)
Obtiene el valor real de table[index], sin invocar ningún meta-método. Table debe ser una tabla; index puede ser
cualquier valor.
rawset (table, index, value)
Atribuye value como el valor real de table[index], sin invocar ningún meta-método. Table debe ser una tabla, index
puede ser cualquier valor diferente de nil y value puede ser cualquier valor Lua.
Esta función retorna table.
select (index, ...)
Si index es un número, retorna todos los argumentos después del argumento número index. En caso contrario,
index debe ser la cadena "#" y select retorna el número total de argumentos extras recibidos.
setfenv (f, table)
Establece el ambiente a ser usado por la función suministrada. F puede ser una función Lua o un número que
especifica la función en aquel nivel de pila: La función llamando a setfenv posee nivel 1. Setfenv retorna la función
suministrada.
Como un caso especial, cuando f es 0 setfenv cambia el ambiente del flujo de ejecución corriente. En este caso,
setfenv no retorna ningún valor.
setmetatable (table, metatable)
Establece la meta-tabla para la tabla suministrada (no se puede alterar la meta-tabla de otros tipos desde Lua,
solamente desde C.) Si metatable es nil, remueve la meta-tabla de la tabla suministrada. Si la meta-tabla original
tiene un campo "__metatable", dispara un error.
Esta función retorna table.
254
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
tonumber (obj [, base])
Intenta convertir su argumento para un número. Si el argumento ya es un número o una cadena de caracteres
que puede ser convertida para un número, entonces tonumber retorna este número; en caso contrario, retorna nil.
Un argumento opcional especifica la base para interpretar el numeral. La base puede ser cualquier entero entre 2
y 36, ambos inclusive. En bases arriba de 10, la letra ‘a’ (mayúscula o minúscula) representa 10, 'B' representa 11
y así sucesivamente, con 'Z' representando 35. En la base 10 (el estándar), el número puede tener una parte
decimal, así como una parte exponente opcional (ver B.2.2). En otras bases, solamente son aceptados enteros
sin señal.
tostring (obj)
Recibe un argumento de cualquier tipo y lo convierte para una cadena de caracteres en un formato razonable.
Para un control completo de como números son convertidos, use string.format.
Si la meta-tabla de e posee un campo "__tostring", entonces tostring llama el valor correspondiente con e como
argumento y usa el resultado de la llamada como su resultado.
type (v)
Retorna el tipo de su único argumento, codificado como una cadena de caracteres. Los resultados posibles de
esta función son "nil" (una cadena de caracteres, no el valor nil), "number", "string", "boolean", "table", "function",
"thread" y "userdata".
unpack (list [, i [, j]])
Retorna los elementos de la tabla suministrada. Esta función es equivalente a
return list[ i], list[ i+1] , ···, list[ j]
excepto que el código anterior puede ser escrito solamente para un número fijo de elementos. Por estándar, i es 1
y j es el tamaño de la lista, como definido por el operador de tamaño (ver B.2.6.6).
_VERSION
Una variable global (no una función) que almacena una cadena conteniendo la versión corriente del interpretador.
El contenido corriente de esta variable es "Lua 5.1".
xpcall (f, err)
Esta función es análoga a pcall, excepto que se puede establecer un nuevo tratador de errores.
xpcall llama la función f en modo protegido, usando err como un tratador de errores. Cualquier error dentro de f no
es propagado; en vez de eso, xpcall captura el error, llama la función err con el objeto de error original y retorna
un código indicando un estatus. Su primer resultado es el código de status (un booleano), que es verdadero si la
llamada ocurrió sin errores. En este caso, xpcall también retorna todos los resultados de la llamada, después de
este primer resultado. En caso de error, xpcall retorna false más el resultado de err.
© ABNT 2007 - Todos los derechos reservados
255
ABNT NBR 15606-2:2007
B.5.3 Manipulación de co-rutinas
Las operaciones relacionadas con co-rutinas constituyen una sub-biblioteca de la biblioteca básica y están dentro
de la tabla coroutine. Ver B.2.12 para una descripción general de co-rutinas.
coroutine.create (f)
Crea una nueva co-rutina, con cuerpo f. f debe ser una función Lua. Retorna esta nueva co-rutina, un objeto con
tipo "thread".
coroutine.resume (co [, val1, ..., valn])
Inicia o continúa la ejecución de la co-rutina co. En la primera vez que se "continúa" una co-rutina, empieza
ejecutando su cuerpo. Los valores val1, ··· son pasados como los argumentos para el cuerpo de la función. Si la
co-rutina ya cedió la ejecución antes, resume la continúa; los valores val1, ··· son pasados como los resultados de
la cesión.
Si la co-rutina ejecuta sin ningún error, resume retorna true más cualesquiera valores pasados para yield (si la corutina cede) o cualquier valor retornados por el cuerpo de la función (si la co-rutina termina). Si hay cualquier error,
resume retorna false más el mensaje de error.
coroutine.running ()
Retorna la co-rutina siendo ejecutada o nil cuando es llamada por el flujo de ejecución principal.
coroutine.status (co)
Retorna el estatus de la co-rutina co, como una cadena de caracteres: "running", si la co-rutina está ejecutando
(es decir, llamó a estatus); "suspended", si la co-rutina está suspensa en una llamada a yield o se no comenzó su
ejecución aún; "normal" si la co-rutina está activa pero no está ejecutando (es decir, continuó otra co-rutina); y
"dead" si la co-rutina terminó su función principal o se paró con un error.
coroutine.wrap (f)
Crea una nueva co-rutina, con cuerpo f. f debe ser una función Lua. Retorna una función que recomienza la corutina cada vez que es llamada. cualesquiera argumentos pasados para la función se comportan como los
argumentos extras para resume. Retorna los mismos valores retornados por resume, excepto el primer booleano.
En caso de error, propaga el error.
coroutine.yield ([val1, ..., valn])
Suspende la ejecución de la co-rutina llamadora. La co-rutina no puede estar ejecutando una función C, un
metamétodo o un repetidor. Cualesquiera argumentos para yield son pasados como resultados extras para
resume.
B.5.4 Módulos
La biblioteca de paquetes provee facilidades básicas para cargar y construir módulos en Lua. Exporta dos de sus
funciones directamente en el ambiente global: Require y module. Todas las otras funciones son exportadas en
una tabla package.
256
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
module (name [, ...])
Crea un módulo. Si hay una tabla en package.loaded[name], esta tabla es el módulo. En caso contrario, si existe
una tabla global t con el nombre suministrado, esta tabla es el módulo. En caso contrario crea una nueva tabla t y
la establece como el valor de la global name y el valor de package.loaded[name]. Esta función también inicializa
t._NAME con el nombre suministrado, t._M con el módulo (el propio t) y t._PACKAGE con el nombre del paquete
(el nombre del módulo completo menos el último componente). Finalmente, module establece t como el nuevo
ambiente de la función corriente y el nuevo valor de package.loaded[name], de modo que require retorna t.
Si name es un nombre compuesto (es decir, un nombre con componentes separados por puntos), module crea (o
reutiliza, si las mismas ya existen) tablas para cada componente. Por ejemplo, si name es a.b.c, entonces module
almacena la tabla del módulo en el campo c del campo b de la global a.
Esta función puede recibir algunas opciones después del nombre del módulo, donde cada opción es una función
a ser aplicada sobre el módulo.
require (mod name)
Carga el módulo suministrado. Esta función empieza buscando en la tabla package.loaded para determinar si
modname ya fue cargado. En caso afirmativo, requiere retornar el valor almacenado en
package.loaded[modname]. En caso contrario, intenta hallar un cargador para el módulo.
Para encontrar un cargador, require es guiada por el array package.loaders. Modificando este array, podemos
alterar cómo require busca por un módulo. La siguiente explicación se basa en la configuración estándar para
package.loaders.
El primer require consulta package.preload[modname]. Se existe un valor en ese campo, este valor (que debe ser
una función) es el cargador. En caso contrario require busca por un cargador Lua usando el camino almacenado
en package.path. Si eso también falla, busca por un cargador C usando el camino almacenado en package.cpath.
Si eso también falla, intenta un cargador todo en uno (ver package.loaders).
Una vez que un cargador se encuentra, require llama el cargador con un único argumento, modname. Si el
cargador retorna cualquier valor, require atribuye el valor retornado a package.loaded[modname]. Si el cargador
no retorna ningún valor y no fue atribuido ningún valor a package.loaded[modname], entonces require atribuye
true a esta posición. En cualquier caso, require retorna el valor final de package.loaded[modname].
Si ocurre un error durante la carga o la ejecución del módulo o si no es posible encontrar un cargador para el
módulo, entonces require señaliza un error.
package.cpath
El camino usado por require para buscar un cargador C.
Lua inicializa el camino C package.cpath de la misma forma que inicializa el camino Lua package.path, usando la
variable de ambiente LUA_CPATH o un camino estándar definido en luaconf.h.
package.loaded
Una tabla usada por require para controlar cuáles módulos ya fueron cargados. Cuando se requisita un módulo
modname y package.loaded[modname] no es falso, require simplemente retorna el valor almacenado allá.
package.loaders
Una tabla usada por require para controlar cómo cargar módulos.
© ABNT 2007 - Todos los derechos reservados
257
ABNT NBR 15606-2:2007
Cada posición en esta tabla es una función buscadora. Cuando está buscando un módulo, require llama a cada
una de estas funciones buscadoras en orden creciente, con el nombre del módulo (el argumento suministrado a
require) como su único parámetro. La función puede retornar otra función (el cargador del módulo) o una cadena
de caracteres explicando por qué no halló aquel módulo (o nil si no tiene nada a decir). Lua inicializa esta tabla
con cuatro funciones.
La primera función buscadora simplemente buscar un cargador en la tabla package.preload.
La segunda función buscadora busca un cargador como una biblioteca Lua, usando el camino almacenado en
package.path. Un camino es una secuencia de estándares separadas por punto y coma. Para cada estándar, la
función buscadora va a alterar cada punto de interrogación en el estándar para filename, que es el nombre del
módulo con cada punto reemplazado por un "separador de directorio" (como "/" en el Unix); entonces intentará
abrir el nombre del archivo resultante. Por ejemplo, si el camino es la cadena de caracteres
"./?.lua;./?.lc;/usr/local/?/init.lua"
la busca de un archivo Lua para el módulo foo intentará abrir los archivos, ./foo.lc y /usr/local/foo/init.lua, en ese
orden.
La tercera función buscadora busca un cargador como una biblioteca C, usando el camino suministrado por la
variable package.cpath. Por ejemplo, si el camino C es la cadena
"./?.so;./?.dll;/usr/local/?/init.so"
la función buscadora para el módulo foo intentará abrir los archivos ./foo.so, ./foo.dll y /usr/local/foo/init.so, en ese
orden. Una vez que encuentra una biblioteca C, esta función buscadora primero usa una facilidad de enlace
dinámica para conectar la aplicación con la biblioteca. Entonces intenta encontrar una función C dentro de la
biblioteca para ser usada como cargador. El nombre de esta función C es la cadena "luaopen_" concatenada con
una copia del nombre del módulo donde cada punto es reemplazado por un subrayado. Además de ello, si el
nombre del módulo posee un guión, su código hasta (e incluyendo) el primer guión es removido. Por ejemplo, si el
nombre del módulo es a.v1-b.c, el nombre de la función será luaopen_b_c.
La cuarta función buscadora intenta un cargador todo en uno. Busca en el camino C una biblioteca para la raíz del
nombre del módulo suministrado. Por ejemplo, al solicitar a.b.c, buscará por una biblioteca C para a. Si encuentra,
busca en esa biblioteca por una función de apertura para el submódulo; en este ejemplo, sería luaopen_a_b_c.
Con esta facilidad, un paquete puede empaquetar varios submódulos C dentro de una única biblioteca, con cada
submódulo guardando su función de apertura original.
package.loadlib (libname, funcname)
Conecta dinámicamente el programa hospedero con la biblioteca C libname. Dentro de esta biblioteca, busca por
una función funcname y retorna esa función como una función C (de ese modo, funcname debe seguir el
protocolo (ver lua_CFunction)).
Ésta es una función de bajo nivel. Contorna completamente el sistema de paquetes y de módulos. Diferentemente
de require, no realiza cualquier busca de camino y no agrega extensiones automáticamente. Libname debe ser el
nombre del archivo completo de la biblioteca C, incluyendo, en caso de ser necesario, un camino y una extensión.
Funcname debe ser el nombre exacto expuesto por la biblioteca C (que puede depender de cómo se usan el
compilador y el conector C).
Esta función no es provista por ANSI C. De esa forma, está disponible solamente en algunas plataformas
(Windows, Linux, MAC LAS X, Solaris, BSD, más otros sistemas Unix que dan soporte al estándar dlfcn).
258
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
package.path
El camino usado por require para buscar un cargador Lua.
Al iniciar, Lua inicializa esta variable con el valor de la variable de ambiente LUA_PATH o con un camino estándar
definido en luaconf.h, si la variable de ambiente no está definida. Cualquier ";;" en el valor de la variable de
ambiente será reemplazado por el camino estándar.
package.preload
Una tabla para almacenar cargadores para módulos específicos (ver require).
package.seeall (module)
Establece una meta-tabla para module con su campo __index refiriéndose al ambiente global, de modo que ese
módulo hereda valores del ambiente global. Para ser usada como una opción a la función module.
B.5.5 Manejo de cadenas de caracteres
Esta biblioteca provee funciones genéricas para el manejo de cadenas de caracteres, tales como encontrar y
extraer subcadenas y casamiento de estándares. Al indexar una cadena en Lua, el primer carácter está en la
posición 1 (no en la posición 0, como en C). Índices pueden tener valores negativos y son interpretados como una
indexación de detrás para delante, desde el final de la cadena. Por lo tanto, el último carácter está en la posición 1 y así sucesivamente.
La biblioteca de cadenas provee todas sus funciones dentro de la tabla string. La misma también establece una
meta-tabla para cadenas donde el campo __index apunta para la tabla string. En consecuencia de eso, se puede
usar las funciones de cadenas en un estilo orientado a objetos. Por ejemplo, string.byte(s, i) puede ser escrito
como s:byte(i).
string.byte (s [, i [, j]])
Retorna el código numérico interno de los caracteres s[i], s[i+1], ···, s[j]. El valor estándar para i es 1; el valor
estándar para j es I.
Códigos numéricos no son necesariamente portátiles entre plataformas.
string.char (i1, i2, ...)
Recibe cero o más enteros. Retorna una cadena con tamaño igual al número de argumentos, en la cual cada
carácter posee un código numérico interno igual a su argumento correspondiente.
Códigos numéricos no son necesariamente portátiles entre plataformas.
string.dump (function)
Retorna una cadena conteniendo la representación binaria de la función suministrada, de modo que un loadstring
posterior en esta cadena retorna una copia de la función. Function debe ser una función Lua sin upvalues.
© ABNT 2007 - Todos los derechos reservados
259
ABNT NBR 15606-2:2007
string.find (s, pattern [, init [, plain]])
Busca la primera coincidencia del estándar pattern en la cadena S. Si la función encuentra una coincidencia,
entonces find retorna los índices de s donde esta ocurrencia comenzó y terminó; en caso contrario, retorna nil. El
tercer argumento, init, es un valor numérico opcional y especifica dónde iniciar la busca; su valor estándar es 1 y
puede ser negativo. Un valor true para el cuarto argumento, plain, que es opcional, deshabilita las facilidades de
coincidencia de estándares, de modo que la función hace una operación "encuentra subcadena" simple, sin
considerar ningún carácter en pattern como "mágico". Si plain se suministra, entonces init debe ser suministrado
también.
Si el estándar posee capturas, entonces en una coincidencia exitosa los valores capturados son también
retornados, después de los dos índices.
string.format (formatstring, e1, e2, ...)
Retorna la versión formateada de su número variable de argumentos siguiendo la descripción fecha en su primer
argumento (que debe ser una cadena). El formato de la cadena sigue las mismas reglas de la familia printf de
funciones C estándar. Las únicas diferencias son que las opciones/modificadores *, l, L, n, p y h no son ofrecidas
y que hay una opción extra, q. La opción q formatea una cadena en una forma adecuada para ser leída de vuelta
de forma segura por el interpretador Lua; la cadena es escrita entre comillas dobles y todas las comillas dobles,
quiebras de línea, barras alteradas y ceros dentro de la cadena son correctamente escapados cuando escritos.
Por ejemplo, la llamada
string.format('%q', 'a string with "quotes" and \n new line')
producirá la cadena:
"a string with \"quotes\" and \
new line"
Las opciones c, d, E, e, f, g, G, i, o, u, X y x esperan un número como argumento, mientras que q y s esperan una
cadena.
Esta función no acepta valores de cadenas conteniendo ceros dentro de las mismas, excepto cuando esos
valores son argumentos para la opción q.
string.gmatch (s, pattern)
Retorna una función repetidora que, cada vez que es llamada, retorna la próxima captura de pattern en la
cadena S. Si pattern no especifica ninguna captura, entonces la coincidencia entera es producida a cada
llamada. Como un ejemplo, el siguiente lazo
s = "hello world from Lua"
for w in string.gmatch(s, "%a+")do
print (w)
end
repetirá sobre todas las palabras de la cadena s, imprimiendo una por línea. El próximo ejemplo recolecta todos
los pares key=value de la cadena suministrada y los coloca en una tabla:
t = {}
s = "from=world, to=Lua"
for k, v in string.gmatch(s, "(%w+)=(%w+)") do
t[k] = v
end
Para esa función, un '^' en el inicio de un estándar no funciona como un ancla, visto que eso iría a impedir la
repetición.
260
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
string.gsub (s, pattern, repl [, n])
Retorna una copia de s en la cual todas las (o las primeras n, si se han suministrado) ocurrencias de pattern son
sustituidas por una cadena de sustitución especificada por repl, que puede ser una cadena, una tabla o una
función. Gsub también retorna, como su segundo valor, el número total de sustituciones que ocurrieron.
Si repl es una cadena, entonces su valor se utiliza para la sustitución. El carácter % funciona como un carácter
de escape: Cualquier secuencia en repl de la forma %n, con n entre 1 9, representa el valor de la n-ésima
subcadena capturada. La secuencia %0 representa el casamiento entero. La secuencia %% representa un %
simple.
Si repl es una tabla, entonces la tabla es consultada a cada coincidencia, usando la primera captura como la
clave; si el estándar no especifica ninguna captura, entonces la coincidencia entera se utiliza como la clave.
Si repl es una función, entonces esta función es llamada a siempre que la coincidencia ocurre, con todas las
subcadenas capturadas siendo pasadas como argumentos, en el orden en el que fueron capturadas; si el
estándar no especifica ninguna captura, entonces la coincidencia entera es pasada como un único argumento.
Si el valor retornado por la consulta a la tabla o por la llamada de función es una cadena o un número, entonces
ese valor se utiliza como la cadena de sustitución; en caso contrario, si es false o nil, entonces no hay
sustitución (es decir, el casamiento original es mantenido en la cadena).
Aquí están algunos ejemplos:
x = string.gsub("hello world", "(%w+)", "%1 %1")
--> x="hello hello world world"
x = string.gsub("hello world", "%w+", "%0 %0", 1)
--> x="hello hello world"
x = string.gsub("hello world from Lua", "(%w+)%s*(%w+)", "%2 %1")
--> x="world hello Lua from"
x = string.gsub("home = $HOME, user = $USER", "%$(%w+)", os.getenv)
--> x="home = /home/roberto, user = roberto"
x = string.gsub("4+5 = $return 4+5$", "%$(.-)%$", function (s)
return loadstring(s)()
end)
--> x="4+5 = 9"
local t = {name="lua", version="5.1"}
x = string.gsub("$name%-$version.tar.gz", "%$(%w+)", t)
--> x="lua-5.1.tar.gz"
string.len (s)
Recibe una cadena y retorna su tamaño. La cadena vacía "" tiene tamaño 0. Ceros dentro de la cadena son
contados, entonces "a\000bc\000" tiene tamaño 5.
string.lower (s)
Recibe una cadena y retorna una copia de esta cadena con todas las letras mayúsculas convertidas para
minúsculas. Todos los demás caracteres permanecen iguales. La definición de lo que es una letra mayúscula
depende del idioma (locale) corriente.
© ABNT 2007 - Todos los derechos reservados
261
ABNT NBR 15606-2:2007
string.match (s, pattern [, init])
Busca la primera coincidencia de pattern en la cadena S. Si encuentra una, entonces match retorna las capturas
del estándar; en caso contrario retorna nil. Si pattern no especifica ninguna captura, entonces la coincidencia
entera es retornada. Un tercer argumento numérico opcional, init, especifica dónde iniciar la busca; su valor
estándar es 1 y puede ser negativo.
string.rep (s, n)
Retorna una cadena que es la concatenación de n copias de la cadena s.
string .reverse (s)
Retorna una cadena que es la cadena s invertida.
string .sub (s, i [, j])
Retorna una subcadena de s que inicia en i y continúa hasta j; i y j pueden ser negativas. Si j está ausente,
entonces se presupone que es igual a -1 (que es lo mismo que el tamaño de la cadena). En particular, la llamada
string.sub(s,1,j) retorna un código de s con tamaño j y string.sub(s, -i) retorna un sufijo de s con tamaño i.
string.upper (s)
Recibe una cadena y retorna una copia de esta cadena con todas las letras minúsculas convertidas para
mayúsculas. Todos los demás caracteres permanecen iguales. La definición de lo que es una letra minúscula
depende del idioma (locale) corriente.
B.5.6 Estándares
Una clase de caracteres se utiliza para representar un conjunto de caracteres. Las siguientes combinaciones se
permiten en descripciones de una clase de caracteres:
262

x: (donde x no es uno de los caracteres mágicos ^$()%.[]* +-?) representa el propio carácter x.

. : (un

%a: representa todas las letras.

%c: representa todos los caracteres de control.

%d: representa todos los dígitos.

%l: representa todas las letras minúsculas.

%p: representa todos los caracteres de puntuación.

%s: representa todos los caracteres de espacio.

%u: representa todas las letras mayúsculas.

%w: representa todos los caracteres alfanuméricos.
punto) representa todos los caracteres.
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007

%x: representa todos los dígitos hexadecimales.

%z: representa el carácter con representación 0.

%x: (donde x es cualquier carácter no alfanumérico) representa el carácter x. Ésta es la manera
estándar de escapar los caracteres mágicos. Cualquier carácter de puntuación (incluso los no
mágicos) puede ser precedido por un '%' cuando usado para representar a sí mismo en un estándar.

[set]: representa la clase que es la unión de todos los caracteres en set. Una banda de caracteres
puede ser especificada separando los caracteres finales de la banda con un '-'. Todas las
clases %x descritas arriba también se pueden usar como componentes en set. Todos los otros
caracteres en set representan ellos mismos. Por ejemplo, [ %w_] (o [_%w]) representa todos los
caracteres alfanuméricos más el subrayado, [ 0-7] representa los dígitos octales y [ 0-7%l%-]
representa los dígitos octales más las letras minúsculas más el carácter '-'.
La interacción entre bandas y clases no es definida. Por lo tanto, estándares como [%a-z] o [a-%%] no
tienen significado.

[^set] : Representa el complemento de set, donde set es interpretado como arriba.
Para todas las clases representadas por una única letra (%a, %c, etc.), la letra mayúscula correspondiente
representa el complemento de la clase. Por ejemplo, %S representa todos los caracteres que no son de espacio.
Las definiciones de letra, espacio y otros grupos de caracteres dependen del idioma (locale) corriente. En
particular, la clase [a-z] puede no ser equivalente a %l.
Un ítem de estándar puede ser:

una clase de un único carácter, que empareja cualquier carácter simple que pertenezca a la clase;

una clase de un único carácter seguida por '*', que empareja 0 o más repeticiones de caracteres de la
clase. Estos ítems de repetición siempre emparejarán la mayor secuencia posible;

una clase de un único carácter seguida por '+', que empareja 1 o más repeticiones de caracteres de la
clase. Estos ítems de repetición siempre emparejarán la mayor secuencia posible;

una clase de un único carácter seguida por '-', que también empareja 0 o más repeticiones de caracteres
de la clase. Diferentemente de '*', estos ítems de repetición siempre emparejarán a menor secuencia
posible;

una clase de un único carácter seguida por '?', que empareja 0 ó 1 ocurrencia de un carácter de la clase;

%n, para n entre 1 9; tal ítem empareja una subcadena igual a la n-ésima cadena capturada;

%bxy, donde x e y son dos caracteres distintos; tal ítem empareja cadenas que empiezan con x, terminan
con y y donde el número de xs y de ys es equilibrado. Esto significa que, si alguien lee la cadena de
izquierda a derecha, contando +1 para una x y -1 para una y, la y final es la primera y donde el contador
alcanza 0. Por ejemplo, el ítem %b() empareja expresiones con paréntesis equilibrados.
Un estándar es una secuencia de ítems de estándar. Un '^' en el inicio de un estándar ancla la coincidencia en el
inicio de la cadena siendo usada. Un '$' al final de un estándar ancla la coincidencia al final de la cadena siendo
usada. En otras posiciones, '^' y '$' no poseen significado especial y representan a sí mismos.
© ABNT 2007 - Todos los derechos reservados
263
ABNT NBR 15606-2:2007
Un estándar puede contener subestándares delimitados por paréntesis; describen capturas. Cuando una
coincidencia ocurre, las subcadenas de la cadena siendo usada que coincidieron con las capturas son
almacenadas (capturadas) para uso futuro. Las capturas son numeradas de acuerdo con sus paréntesis
izquierdos. Por ejemplo, en el estándar "(a*(.)%w(%s*))", la parte de la cadena casando "a*(.)%w(%s*)" es
almacenada como la primera captura (y por lo tanto tiene el número 1); el carácter coincidiendo "." es capturado
con el número 2 y la parte coincidiendo "%s*" tiene el número 3.
Como un caso especial, la captura vacía () captura la posición de la cadena corriente (un número). Por ejemplo, si
aplicamos el estándar "()aA()" en la cadena "flaaap", habrá dos capturas: 3 y 5.
Un estándar no puede contener ceros dentro de él. Use %z como alternativa.
B.5.7 Manejo de tablas
Esta biblioteca provee funciones genéricas para manejo de tablas. Provee todas sus funciones en la tabla table.
La mayoría de las funciones en la biblioteca de tablas presupone que la tabla representa un array o una lista.
Para estas funciones, cuando hablamos sobre el "tamaño" de una tabla estamos hablando sobre el resultado del
operador de tamaño.
table.concat (table [, sep [, i [, j]]])
Dado un array donde todos los elementos son cadenas o números, retorna table[i]..sep..Table[i+1] ··· sep..table[j].
El valor estándar para sep es la cadena vacía, el estándar para i es 1 y el estándar para j es el tamaño de la tabla.
Si i es mayor que j, retorna la cadena vacía.
table.insert (table, [pos,] value)
Inserta el elemento value en la posición pos de table, desplazando los otros elementos para abrir espacio, en
caso de ser necesario. El valor estándar para pos es n+1, donde n es el tamaño de la tabla (ver B.2.6.6), de modo
que una llamada table.insert(t,x) inserta x al final de la tabla t.
table.maxn (table)
Retorna el mayor índice numérico positivo de la tabla suministrada o cero si la tabla no posee índices numéricos
positivos (para realizar su trabajo esta función hace un recorrido lineal de la tabla entera).
table.remove (table [, pos])
Remueve de table el elemento en la posición pos, desplazando los otros elementos para rellenar el espacio, en
caso de ser necesario. Retorna el valor del elemento removido. El valor estándar para pos es n, donde n es el
tamaño de la tabla, de modo que una llamada table.remove(t) remueve el último elemento de la tabla t.
table.sort (table [, comp])
Ordena los elementos de la tabla en un dado orden, in-place, de table[1] hasta table[n], donde n es el tamaño de
la tabla. Si comp se suministra, entonces él debe ser una función que recibe dos elementos de la tabla y retorna
true cuando el primero es menor que el segundo (de modo que not comp(la[i+1,a][i]) será verdadero después de
la ordenación). Si comp no se suministra, entonces el operador estándar de Lua < se utiliza en su lugar.
El algoritmo de ordenación no es estable; es decir, elementos considerados iguales por el orden suministrada
pueden tener sus posiciones relativas cambiadas por la ordenación.
264
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
B.5.8 Funciones matemáticas
Esta biblioteca es una interfaz para la biblioteca matemática de C estándar. Provee todas sus funciones en la
tabla math.
math.abs (x)
Retorna el valor absoluto de x.
math. acos (x)
Retorna el arco coseno de x (en radianos).
math.asin (x)
Retorna el arco seno de x (en radianos).
math.atan (x)
Retorna el arco tangente de x (en radianos).
math.atan2 (x)
Retorna el arco tangente de y/x (en radianos), pero usa la señal de los dos parámetros para hallar el cuadrante
del resultado (también trata correctamente el caso de x ser cero).
math.aceil (x)
Retorna el menor entero mayor o igual a x.
math.cos (x)
Retorna el coseno de x (presupone que x está en radianos).
math.cosh (x)
Retorna el coseno hiperbólico de x.
math.deg (x)
Retorna el ángulo x (dado en radianos) en grados.
math.exp (x)
© ABNT 2007 - Todos los derechos reservados
265
ABNT NBR 15606-2:2007
Retorna el valor de ex.
math.floor (x)
Retorna el mayor entero menor o igual a x.
math.fmod (x, y)
Retorna el resto de la división de x por y.
math.frexp (x)
Retorna m y e tales que x = m2e, e es un entero y el valor absoluto de m está en el intervalo [0.5, 1) (o cero
cuando x es cero).
math.huge (x)
El valor de HUGE_VAL, un valor mayor o igual a cualquier otro valor numérico.
math.ldexp (m, e)
Retorna m2e (e debe ser un entero).
math.log10 (x)
Retorna el logaritmo natural de x.
math.log10 (x)
Retorna el logaritmo base -10 de x.
math.max (x, …)
Retorna el valor máximo entre sus argumentos.
math.min (x, …)
Retorna el valor mínimo entre sus argumentos.
math.modf (x)
Retorna dos números, la parte integral de x y la parte fraccionaria de x.
math. pi
El valor de pi.
266
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
math.pow (x, y)
Retorna xy (también se puede usar la expresión x^y para computar este valor).
math.rad (x)
Retorna el ángulo x (dado en grados) en radianos.
math.random ([m [,n]])
Esta función es una interfaz para la función generadora pseudo-aleatoria simple rand suministrada por ANSI C.
(ninguna garantía puede ser dada para sus propiedades estadísticas).
Cuando llamada sin argumentos, retorna un número real pseudo-aleatorio en el intervalo [0,1). Cuando llamada
con un número m, math.random retorna un entero pseudo-aleatorio en el intervalo [1, m). Cuando llamada con
dos números m y n, math.random retorna un entero pseudo-aleatorio en el intervalo [m, n).
math.randomseed (x)
Establece x como la "semilla" para el generador pseudo-aleatorio: semillas iguales producen secuencias iguales
de números.
math.sin (x)
Retorna el seno de x (presupone que x está en radianos).
math.sinh (x)
Retorna el seno hiperbólico de x.
math.sqrt (x)
Retorna la raíz cuadrada de x (también se puede usar la expresión x^0.5 para computar este valor).
math.tan (x)
Retorna la tangente de x (presupone que x está en radianos).
math.tanh (x)
Retorna la tangente hiperbólica de x.
B.5.9 Facilidades de entrada y salida
La biblioteca de E/S provee dos estilos diferentes para manejo de archivos. El primero usa descriptores de archivo
implícitos; es decir, hay operaciones para establecer un archivo de entrada estándar y un archivo de salida
estándar y todas las operaciones de entrada/salida son realizadas sobre estos archivos. El segundo estilo usa
descriptores de archivo explícitos.
© ABNT 2007 - Todos los derechos reservados
267
ABNT NBR 15606-2:2007
Cuando se usa descriptores de archivo implícitos, todas las operaciones son provistas por la tabla io. Cuando se
usa descriptores de archivo explícitos, la operación io.open retorna un descriptor de archivo y entonces todas las
operaciones son provistas como métodos del descriptor de archivo.
La tabla io también suministra tres descriptores de archivo pre-definidos con sus significados usuales de C:
io.stdin, io.stdout e io.stderr.
A menos que dicho de modo contrario, todas las funciones de E/S retornan nil en caso de fallo (más un mensaje
de error como segundo resultado y un código de error dependiente del sistema como un tercer resultado), o algún
valor diferente de nil en caso de éxito.
io.close ([file])
Equivalente a file:close(). Cuando no recibe file, cierra el archivo de salida estándar.
io.flush ()
Equivalente a file:flush en el archivo de salida estándar.
io.input ([file])
Cuando es llamada con un nombre de archivo, abre el archivo con aquel nombre (en modo texto) y establece su
manipulador como el archivo de entrada estándar. Cuando es llamada con un manipulador de archivo,
simplemente establece este manipulador de archivo como el archivo de entrada estándar. Cuando llamada sin
parámetros, retorna el archivo de entrada estándar corriente.
En caso de errores esta función dispara el error, en vez de retornar un código de error.
io.lines ([filename])
Abre el nombre de archivo suministrado en modo de lectura y retorna una función repetidora que, cada vez que
es llamada, retorna una nueva línea del archivo. Por lo tanto, la construcción
for line in io.lines(filename) do body end
repetirá sobre todas las líneas del archivo. Cuando la función repetidora detecta el fin del archivo, retorna nil (para
finalizar el lazo) y automáticamente cierra el archivo.
La llamada io.lines() (sin ningún nombre de archivo) es equivalente a io.input():lines(); es decir, repite sobre las
líneas del archivo de entrada estándar. En este caso no cierra el archivo cuando el lazo termina.
io.open (filename [, mode])
Esta función abre un archivo, en el modo especificado en la cadena mode. Retorna un nuevo manipulador de
archivo o, en caso de errores, nil más un mensaje de error.
268
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
La cadena de caracteres mode puede ser cualquier una de las siguientes:

“r”: modo de lectura (el estándar);

“w”: modo de grabación;

“a”: modo de adición;

“r+”: modo de actualización, todos los datos anteriores son preservados;

“w+”: modo de actualización, todos los datos anteriores son preservados;

“a+”: modo de actualización de adición, datos anteriores son preservados, la grabación solamente se
permite al final del archivo.
La cadena mode también puede tener una 'b' al final, que es necesaria en algunos sistemas para abrir el archivo
en modo binario. Esta cadena es exactamente la que se utiliza en la función estándar de C fopen.
io.output ([file])
Análogo a io.input, pero opera sobre el archivo de salida estándar.
io.popen ([prog [, mode]])
Inicia el programa prog en un proceso separado y retorna un manipulador de archivo que se puede usar para leer
datos de este programa (si mode es "r", el estándar) o escribir datos para este programa (si mode es "w").
Esta función es dependiente del sistema y no está disponible en todas las plataformas.
io.read (format1, ...)
Equivalente a io.input():read.
io.tmpfile ()
Retorna un manipulador para un archivo temporal. Este archivo es abierto en modo de actualización y es
automáticamente removido cuando el programa termina.
io.type (obj)
Verifica si obj es un manipulador de archivo válido. Retorna la cadena "file" si obj es un manipulador de archivo
abierto, "close file" si obj es un manipulador de archivo cerrado o nil si obj no es un manipulador de archivo.
io.write (value1, ...)
Equivalente a io.output():write.
file:close ()
Cierra file. Archivos son automáticamente cerrados cuando sus manipuladores son colectados por el colector de
basura, pero lleva una cantidad indeterminada de tiempo para que eso ocurra.
© ABNT 2007 - Todos los derechos reservados
269
ABNT NBR 15606-2:2007
file:flush ()
Graba cualquier dato escrito para file.
file:lines ()
Retorna una función repetidora que, cada vez que es llamada, retorna una nueva línea del archivo. Por lo tanto, la
construcción
for line in file:lines() do ... end
repetirá sobre todas las líneas del archivo (al contrario de io.lines, esa función no cierra el archivo cuando el lazo
termina).
file:read (format1, ...)
Lee el archivo file, de acuerdo con los formatos suministrados, los cuales especifican lo que debe ser leído. Para
cada formato, la función retorna una cadena (o un número) con los caracteres leídos o nil si no puede retornar
datos con el formato especificado. Cuando llamada sin formatos, usa el formato estándar que lee la próxima línea
toda.
Los formatos disponibles son:

“*n”: lee un número; éste es el único formato que retorna un número en vez de una cadena.

“*a”: lee el archivo entero, empezando por la posición corriente. Cuando está al final del archivo, retorna
la cadena vacía.

“*l”: lee la próxima línea (saltando el fin de línea), retornando nil al final del archivo. Éste es el formato
estándar.

número: lee una cadena hasta este número de caracteres, retornando nil al final del archivo. Si el
número suministrado es cero, la función no lee nada y retorna una cadena vacía o nil cuando está al
final del archivo.
file:seek ([whence] [, offset])
Establece y obtiene la posición del archivo, medida desde el inicio del archivo, hasta la posición dada por offset
más una base especificada por la cadena whence, de la siguiente forma:
 “set” : base es la posición 0 (el inicio del archivo);
 “cur” : base es la posición corriente;
 “end" : base es el fin del archivo;
En caso de éxito, la función seek retorna la posición final del archivo, medida en bytes desde el inicio del archivo.
Si esta función falla, retorna nil, más una cadena describiendo el error.
El valor estándar para whence es "cur" y para offset es 0. Por lo tanto, la llamada file:seek() retorna la posición del
archivo corriente, sin modificarla; la llamada file:seek("set") establece la posición en el inicio del archivo (y retorna
0); y la llamada file:seek("end") establece la posición en el fin del archivo y retorna su tamaño.
270
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
file:setvbuf (mode [, size])
Define el modo de buferización para un archivo de salida. Hay tres modos disponibles:

“no” : ninguna buferización; el resultado de cualquier operación de salida aparece inmediatamente;

“full” : buferización completa; la operación de salida se realiza solamente cuando el buffer está lleno (o
cuando explícitamente se descarga el archivo (ver io.flush));

“line” : buferización de línea; la salida es buferizada hasta que una nueva línea es producida o hay
cualquier entrada desde algunos archivos especiales (como un dispositivo de terminal).
Para los últimos dos casos, size especifica el tamaño del buffer, en bytes. El estándar es un tamaño apropiado.
file:write (value1, ...)
Escribe el valor de cada uno de sus argumentos para file. Los argumentos deben ser cadenas de caracteres o
números. Para escribir otros valores, use tostring o string.format antes de write.
B.5.10 Facilidades del sistema operativo
Esta biblioteca es implementada a través de la tabla os.
os.clock ()
Retorna una aproximación de la cantidad de tiempo de CPU, en segundos, usada por el programa.
os.date ([format [, time]])
Retorna una cadena o una tabla conteniendo fecha y horario, formateada de acuerdo con la cadena format
suministrada.
Si el argumento time está presente, éste es el tiempo a ser formateado (ver la función os.time para una
descripción de este valor). En caso contrario, date formatea el horario corriente.
Si format empieza con '!', entonces la fecha es formateada en el Tiempo Universal Coordinado. Después de ese
carácter opcional, si format es la cadena "*t", entonces date retorna una tabla con los siguientes campos: Year
(cuatro dígitos), month (1--12), day (1--31), hour (0--23), min (0--59), sec (0--61), yday (día del año) e isdst (flag
que indica el horario de verano, un booleano).
Si format no es "*t", entonces date retorna la fecha como una cadena de caracteres, formateada de acuerdo con
las mismas reglas de la función C strftime.
Cuando llamada sin argumentos, date retorna una representación aceptable de la fecha y del horario que
depende del sistema hospedero y del idioma (locale) corriente. (Es decir, os.date() es equivalente a
os.date("%c")).
© ABNT 2007 - Todos los derechos reservados
271
ABNT NBR 15606-2:2007
os.difftime (t2, t1)
Retorna el número de segundos desde el tiempo t1 hasta el tiempo t2. En POSIX, Windows y algunos otros
sistemas, este valor es exactamente t2-t1.
os.execute ([command])
Esta función es equivalente a la función C system. Pasa command para ser ejecutado por un interpretador de
comandos del sistema operativo. Retorna un código de estatus, que es dependiente del sistema. Si command
está ausente, entonces la función retorna un valor diferente de cero si un interpretador de comandos está
disponible y cero en caso contrario.
os.exit ([code])
Llama la función C exit, con un código code opcional, para terminar el programa hospedero. El valor estándar
para code es el código de éxito.
os.getenv (varname)
Retorna el valor de la variable de ambiente del proceso varname o nil si la variable no está definida.
os.remove (filename)
Remueve un archivo o directorio con el nombre suministrado. Directorios deben estar vacíos para ser removidos.
Si esta función falla, retorna nil, más una cadena describiendo el error.
os.rename (oldname, newname)
Cambia el nombre de un archivo o directorio llamado oldname para newname. Si esta función falla, retorna nil,
más una cadena describiendo el error.
os.setlocale (locale [, category])
Establece el idioma (locale) corriente del programa. Locale es una cadena de caracteres especificando un idioma;
category es una cadena opcional describiendo para cual categoría se debe alterar: "All", "collate", "ctype",
"monetary", "numeric" o “time”; la categoría estándar es "all". Esta función retorna el nombre del nuevo idioma o
nil si la requisición no puede ser honrada.
Si locale es la cadena vacía, se establece el idioma corriente como un idioma nativo definido por la
implementación. Si locale es la cadena "C", se establece el idioma corriente como el idioma estándar de C.
Cuando llamada con nil como el primer argumento, esta función retorna solamente el nombre del idioma corriente
para la categoría suministrada.
os.time ([table])
Retorna el tiempo corriente cuando es llamada sin argumentos o un tiempo representando la fecha y el horario
especificados por la tabla suministrada. Esta tabla debe tener campos year, month y day y puede tener campos
hour, min, sec e isdst (para una descripción de estos campos, ver la función os.date).
272
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
El valor retornado es un número, cuyo significado depende de su sistema. En POSIX, Windows y algunos otros
sistemas, este número cuenta el número de segundos desde algún tiempo de inicio dado (a "era"). En otros
sistemas, el significado no se especifica y el número retornado por equipo se puede usar solamente como un
argumento para date y difftime.
os.tmpname ()
Retorna una cadena de caracteres con el nombre de un archivo que se puede usar para un archivo temporal. El
archivo debe ser explícitamente abierto antes de ser usado y explícitamente removido cuando no sea más
necesario.
B.5.11 Biblioteca de depuración
Esta biblioteca provee las funcionalidades de la interfaz de depuración para programas Lua. Se debe tener
cuidado al usar esta biblioteca. Las funciones suministradas aquí deben ser usadas exclusivamente para
depuración y tareas análogas, tales como medición (profiling). Debe evitarse usarlas como una herramienta de
programación usual: pueden ser muy lentas. Además de ello, varias de esas funciones violan algunas
suposiciones al respecto del código Lua (por ejemplo, que variables locales a una función no se pueden acceder
de fuera de la función o que meta-tablas de objetos userdata no pueden ser modificadas por código Lua) y por lo
tanto pueden comprometer un código que, de otro modo, sería seguro.
Todas las funciones en esta biblioteca son suministradas en la tabla debug. Todas las funciones que operan sobre
un objeto del tipo thread poseen un primer argumento opcional que es el objeto thread sobre el cual la función
debe operar. El estándar es siempre el flujo de ejecución corriente.
debug.debug ()
Entra en un modo interactivo con el usuario, ejecutando cada cadena de caracteres que el usuario entra. Usando
comandos simples y otros mecanismos de depuración, el usuario puede inspeccionar variables globales y locales,
alterar el valor de las mismas, evaluar expresiones, etc. Una línea conteniendo solamente la palabra cont termina
esta función, de modo que la función llamadora continúa su ejecución.
Los comandos para debug.debug no son anidados de modo léxico dentro de ninguna función y, por lo tanto, no
poseen acceso directo a variables locales.
debug.getfenv (o)
Retorna el ambiente del objeto o.
debug.gethook ()
Retorna las configuraciones de gancho corrientes del flujo de ejecución como tres valores: La función de gancho
corriente, la máscara de gancho corriente y el conteo de gancho corriente (como establecido por la función
debug.sethook).
debug.getinfo (function [, what])
Retorna una tabla con información sobre una función. Se puede suministrar la función directamente o se puede
suministrar un número como el valor de function, que significa la función ejecutando en el nivel function de la pila
de llamadas del flujo de ejecución suministrado: Nivel 0 es la función corriente (la propia getinfo); nivel 1 es la
función que llamó a getinfo; y así sucesivamente. Si function es un número mayor que el número de funciones
activas, entonces getinfo retorna nil.
© ABNT 2007 - Todos los derechos reservados
273
ABNT NBR 15606-2:2007
La tabla retornada puede contener todos los campos retornados por lua_getinfo, con la cadena what describiendo
cuáles campos deben ser rellenados. El estándar para what es obtener todas las informaciones disponibles,
excepto la tabla de líneas válidas. En caso de estar presente, la opción 'f' agrega un campo llamado func con la
propia función. En caso de estar presente, la opción 'L' agrega un campo llamado activelines con la tabla de
líneas válidas.
Por ejemplo, la expresión debug.getinfo(1,"n").name retorna una tabla con un nombre para la función corriente, si
un nombre razonable puede ser encontrado, y la expresión debug.getinfo(print) retorna una tabla con todas las
informaciones disponibles sobre la función print.
debug.getlocal (level, local)
Esta función retorna el nombre y el valor de la variable local con índice local de la función en el nivel level de la
pila (el primer parámetro o variable local posee índice 1 y así sucesivamente, hasta la última variable local activa).
La función retorna nil si no existe una variable local con el índice suministrado y dispara un error cuando llamada
con un level fuera de la banda de valores válidos (se puede llamar a debug.getinfo para verificar si el nivel es
válido).
Nombres de variables que empiezan con '(' (abre paréntesis) representan variables internas (variables de control
de lazos, temporales y locales de funciones C).
debug.getmetatable (object)
Retorna la meta-tabla del object suministrado o nil si él no posee una meta-tabla.
debug.getregistry ()
Retorna la tabla de registro (ver B.3.6).
debug.getupvalue (func, up)
Esta función retorna el nombre y el valor del upvalue con índice up de la función func. La función retorna nil si no
hay un upvalue con el índice suministrado.
debug.setfenv (object, table)
Establece la tabla table como el ambiente del object suministrado. Retorna object.
debug.sethook (hook, mask [, count])
Establece la función suministrada como un gancho. La cadena mask y el número count describen cuando el
gancho será llamado. La cadena mask puede tener los siguientes caracteres, con el respectivo significado:
 "c" : el gancho es llamado siempre que Lua llama una función;
 "r" : el gancho es llamado siempre que Lua retorna de una función;
 "l" : el gancho es llamado siempre que Lua entra una nueva línea de código.
Con un count diferente de cero, el gancho es llamado después de cada count instrucciones.
Cuando llamada sin argumentos, debug.gethook deshabilita el gancho.
274
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
Cuando el gancho se llama, su primer parámetro es una cadena de caracteres describiendo el evento que
disparó su llamada: "Call", "return" (o "tail return"), "line" y "count". Para eventos de línea, el gancho también
obtiene el nuevo número de línea como su segundo parámetro. Dentro del gancho, es posible llamar a getinfo
con nivel 2 para obtener más información sobre la función siendo ejecutada (nivel 0 es la función getinfo y nivel 1
es la función de gancho), a menos que el evento sea "tail return". En este caso, Lua está solamente simulando el
retorno y una llamada a getinfo retornará datos inválidos.
debug.setlocal (level, local, value)
Esta función atribuye el valor value a la variable local con índice local de la función en el nivel level de la pila. La
función retorna nil si no hay una variable local con el índice suministrado y dispara un error cuando llamada con
un level fuera de la banda de valores válidos (se puede llamar a getinfo para verificar si el nivel es válido). En
caso contrario, la función retorna el nombre de la variable local.
debug.setmetatable (object, table)
Establece table como la meta-tabla del object suministrado (table puede ser nil).
debug.setupvalue (func, up, value)
Esta función atribuye el valor value al upvalue con índice up de la función func. La función retorna nil si no hay un
upvalue con el índice suministrado. En caso contrario, la función retorna el nombre del upvalue.
debug.traceback ([message])
Retorna una cadena de caracteres con un trazo de la pila de llamadas. Una cadena opcional message es
agregada al inicio del trazo. Un número opcional level dice en cuál nivel iniciar el trazo (el estándar es 1, la función
llamando a traceback).
B.6 El interpretador Lua autónomo
Aunque Lua haya sido proyectada como un lenguaje de extensión, para ser incorporada en un programa C
hospedero, Lua también es frecuentemente usada como un lenguaje autosuficiente. Un interpretador para Lua
como un lenguaje autosuficiente, llamado simplemente lua, se suministra con la distribución estándar. Ese
interpretador incluye todas las bibliotecas estándar, incluso la biblioteca de depuración. Su uso es:
lua [ options] [ script [ args]]
Las opciones son:

-e stat : ejecuta la cadena stat;

-l mod : "requisita" mod;

-i : entra en modo interactivo después de ejecutar script;

-v : imprime información de versión;

-- : para de tratar opciones;

- : ejecuta stdin como un archivo y para de tratar opciones.
© ABNT 2007 - Todos los derechos reservados
275
ABNT NBR 15606-2:2007
Después de tratar sus opciones, Lua ejecuta el script suministrado, pasándole los args suministrados como
cadenas de argumentos. Cuando llamado sin argumentos, lua se comporta como lua -v -i cuando la entrada
estándar (stdin) es un terminal y como lua - en caso contrario.
Antes de ejecutar cualquier argumento, el interpretador verifica si hay una variable de ambiente LUA_INIT. Si su
formato es @filename, entonces lua ejecuta el archivo. En caso contrario, lua ejecuta la propia cadena de
caracteres.
Todas las opciones son manejadas en el orden dado, excepto -i. Por ejemplo, una invocación como
$ lua -e'Val=1' -e 'print(Val) ' script.lua
irá primero atribuir 1 a a, después imprimirá el valor de a (que es '1') y finalmente ejecutará el archivo script.lua sin
argumentos (aquí $ es el prompt del interpretador de comandos. Se puede tener un prompt diferente).
Antes de empezar a ejecutar el script, lua guarda todos los argumentos suministrados en la línea de comando en
una tabla global llamada arg. El nombre del script es almacenado en el índice 0, el primer argumento después del
nombre del script queda en el índice 1 y así sucesivamente. Cualesquiera argumentos antes del nombre del script
(es decir, el nombre del interpretador más las opciones) quedan en índices negativos. Por ejemplo, en la llamada
$ lua -la b.lua t1 t2
el interpretador primero ejecuta el archivo a.lua, después crea la tabla
arg = { [-2] = "lua", [-1] = "-la",
[0] = "b.lua",
[1] = "t1", [2] = "t2" }
y finalmente ejecuta el archivo b.lua. El script es llamado con arg[1], arg[2], ··· como argumentos; él también
puede acceder a estos argumentos con la expresión vararg '...'.
En modo interactivo, si se escribe un comando incompleto, el interpretador espera que lo complete e indica esto a
través de un prompt diferente.
Si la variable global _PROMPT contiene una cadena de caracteres, entonces su valor se utiliza como el prompt.
De manera análoga, si la variable global _PROMPT2 contiene una cadena, su valor se utiliza como el prompt
secundario (mostrado durante comandos incompletos). Por lo tanto, los dos prompts pueden ser modificados
directamente en la línea de comando o en cualesquiera programas Lua haciendo una atribución a _PROMPT. Ver
el ejemplo a continuación:
$ lua -e"_PROMPT='myprompt> '" –i
El par de comillas más externo es para el interpretador de comandos y el par más interno es para Lua. El uso de -i
para entrar en modo interactivo; en caso contrario, el programa iría a terminar silenciosamente después de la
atribución a _PROMPT.
Para permitir el uso de Lua como un interpretador de scripts en sistemas Unix, el interpretador de línea de
comando salta la primera línea de un trecho de código si él empieza con #. Por lo tanto, scripts Lua se pueden
usar como programas ejecutables usando chmod +x y la forma #!, como en
#! /usr/local/bin/lua
276
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
Está claro que la localización del interpretador Lua puede ser diferente en su máquina. Si lua está en su PATH,
entonces
#! /usr/bin/env lua
es una solución más portable.
B.7 Incompatibilidades con la versión 5.0
NOTA
Las incompatibilidades que pueden ser encontradas cuando se pasa un programa de Lua 5.0 para Lua 5.1 se listan
en esta sección. Se puede evitar la mayoría de las incompatibilidades compilando Lua con opciones apropiadas (ver el archivo
luaconf.h). Sin embargo, todas esas opciones de compatibilidad serán removidas en la próxima versión de Lua.
B.7.1 Cambios en el lenguaje
A continuación se listan las alteraciones en el lenguaje introducidos en Lua 5.1:
 el sistema de vararg cambió del pseudo-argumento arg con una tabla con los argumentos extras para la
expresión vararg (ver la opción de tiempo de compilación LUA_COMPAT_VARARG en luaconf.h);
 hubo un cambio sutil en el alcance de las variables implícitas del comando for y del comando repeat;
 la sintaxis de cadena larga/comentario largo ([[string]]) no permite anidado. En esos casos se puede usar la
nueva sintaxis ([=[string]=]) (ver la opción de tiempo de compilación LUA_COMPAT_LSTR em luaconf.h).
B.7.2 Cambios en las bibliotecas
A continuación se listan las alteraciones en las bibliotecas estándar introducidas en Lua 5.1:
 la función string.gfind fue rebautizada como string.gmatch (ver la opción de tiempo de compilación
LUA_COMPAT_GFIND en luaconf.h);
 cuando string.gsub es llamada con una función como su tercer argumento, siempre que esta función
retorna nil o false la cadena de reemplazo es la coincidencia entera, en vez de la cadena vacía;
 la función table.setn está ultrapasada y no se debe usar. La función table.getn corresponde al nuevo
operador de tamaño (#); usar el operador em vez de la función (ver la opción de tiempo de compilación
LUA_COMPAT_GETN em luaconf.h.);
 la función loadlib fue rebautizada como package.loadlib (ver la opción de tiempo de compilación LUA_COM
PAT_LOADLI B en luaconf.h);
 la función math.mod fue rebautizada como math.fmod (ver la opción de tiempo de compilación
LUA_COMPAT_MOD en luaconf.h);
 las funciones table.foreach y table.foreachi están ultrapasadas y no deben ser usadas. Se puede usar un
lazo for con pairs o ipairs en vez de las mismas;
 hubo cambios sustanciales en la función require debido al nuevo sistema de módulos. El nuevo
comportamiento es básicamente compatible con el antiguo, aunque ahora require obtiene el camino de
package.path y no más de LUA_PATH;
 la función collectgarbage posee argumentos diferentes. La función gcinfo está ultrapasada y no se debe
usar; usar collectgarbage("count") en vez de la misma.
© ABNT 2007 - Todos los derechos reservados
277
ABNT NBR 15606-2:2007
B.7.3 Cambios en la API
A continuación son listadas los cambios en la API C introducidas en Lua 5.1:
 las funciones luaopen_* (para abrir bibliotecas) no pueden ser llamadas directamente, como una función C
común. Deben ser llamadas a través de Lua, como una función Lua;
 la función lua_open fue reemplazada por lua_newstate para permitir que el usuario defina una función de
asignación de memoria. Se puede usar luaL_newstate de la biblioteca estándar para crear un estado con
una función de asignación estándar (con base en realloc);
 las funciones luaL_getn y luaL_setn (de la biblioteca auxiliar) están ultrapasadas y no deben usarse.
Usar lua_objlen en vez de lua_getn y nada en lugar de lua_setn;
 la función luaL_openlib fue reemplazada por luaL_register;
 la función luaL_checkudata ahora dispara un error cuando el valor suministrado no es un objeto userdata
del tipo esperado (en Lua 5.0 retornaba NULL).
B.8 Sintaxis completa de Lua
La sintaxis completa de Lua en la notación BNF extendida es la siguiente (no describe las precedencias de los
operadores):
chunk ::= {stat [`;´]} [laststat[`;´]]
block ::= chunk
stat ::= varlist1 `=´ explist1 |
functioncall |
do block end |
while exp do block end |
repeat block until exp |
if exp then block {elseif exp then block}[else block] end |
for Name `=´ exp `,´ exp [ `,´ exp] del block end
|
for namelist in explist1 do block end |
function funcname funcbody |
local function Name funcbody |
local namelist [`=´ explist1]
278
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
laststat ::= return [explist1] | break
funcname ::= Name {`.´ Name} [`:´ Name]
varlist1 ::= var {`,´ var}
var ::= Name | prefixexp `[´ exp `]´ | prefixexp `.´ Name
namelist ::= Name {`,´ Name}
explist1 ::= {exp `,´} exp
exp ::= nil | false | true | Number | String | `...´ |
function | prefixexp | tableconstructor |
exp binop | exp | unop exp
prefixexp ::= var | functioncall | `(´ exp `)´
functioncall ::= prefixexp args | prefixexp `:´ Name args
args ::= `(´ [explist1] `)´ | tableconstructor | String
function ::= function funcbody
funcbody ::= `(´ [parlist1] `)´ block end
parlist1 ::= namelist [`,´ `...´] | `...´
tableconstructor ::= `{´ [fieldlist] `}´
fieldlist ::= field {fieldsep field} [fieldsep]
field ::= `[´ exp `]´ `=´ exp | Name `=´ exp | exp
fieldsep ::= `,´ | `;´
binop ::= `+´ | `-´ | `*´ | `/´ | `^´ | `%´ | `..´ |
`<´ | `<=´ | `>´ | `>=´ | `==´ | `~=´ |
and | or
unop ::= `-´ | not | `#´
© ABNT 2007 - Todos los derechos reservados
279
ABNT NBR 15606-2:2007
Anexo C
(informativo)
Base de conectores
Esta base de conectores puede ser importada por cualquier documento NCL 3.0.
<!-This is NCL
Copyright: 2000-2005 PUC-RIO/LABORATORIO TELEMIDIA, All Rights Reserved.
See http://www.telemidia.puc-rio.br
Public URI: http://www.ncl.org.br/NCL3.0/connectorBases/causalConnBase.ncl
Author: TeleMidia Laboratory
Revision: 19/09/2006
-->
<?xml version="1.0" encoding="ISO-8859-1"?>
<ncl id="causalConnBase" xmlns="http://www.ncl.org.br/NCL3.0/CausalConnectorProfile">
<head>
<connectorBase>
<!-- OnBegin -->
<causalConnector id="onBeginStart">
<simpleCondition role="onBegin"/>
<simpleAction role="start"/>
</causalConnector>
<causalConnector id="onBeginStop">
<simpleCondition role="onBegin"/>
<simpleAction role="stop"/>
</causalConnector>
<causalConnector id="onBeginPause">
<simpleCondition role="onBegin"/>
<simpleAction role="pause"/>
</causalConnector>
<causalConnector id="onBeginResume">
<simpleCondition role="onBegin"/>
<simpleAction role="resume"/>
</causalConnector>
<causalConnector id="onBeginSet">
<connectorParam name="var"/>
<simpleCondition role="onBegin"/>
<simpleAction role="set" value="$var"/>
</causalConnector>
<!-- OnEnd -->
<causalConnector id="onEndStart">
<simpleCondition role="onEnd"/>
<simpleAction role="start"/>
280
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
</causalConnector>
<causalConnector id="onEndStop">
<simpleCondition role="onEnd"/>
<simpleAction role="stop"/>
</causalConnector>
<causalConnector id="onEndPause">
<simpleCondition role="onEnd"/>
<simpleAction role="pause"/>
</causalConnector>
<causalConnector id="onEndResume">
<simpleCondition role="onEnd"/>
<simpleAction role="resume"/>
</causalConnector>
<causalConnector id="onEndSet">
<connectorParam name="var"/>
<simpleCondition role="onEnd"/>
<simpleAction role="set" value="$var"/>
</causalConnector>
<!-- OnMouseSelection -->
<causalConnector id="onSelectionStart">
<simpleCondition role="onSelection"/>
<simpleAction role="start" />
</causalConnector>
<causalConnector id="onSelectionStop">
<simpleCondition role="onSelection"/>
<simpleAction role="stop" />
</causalConnector>
<causalConnector id="onSelectionPause">
<simpleCondition role="onSelection"/>
<simpleAction role="pause" />
</causalConnector>
<causalConnector id="onSelectionResume">
<simpleCondition role="onSelection"/>
<simpleAction role="resume" />
</causalConnector>
<causalConnector id="onSelectionSetVar">
<connectorParam name="var" />
<simpleCondition role="onSelection"/>
<simpleAction role="set" value="$var"/>
</causalConnector>
<!-- OnKeySelection -->
<causalConnector id="onKeySelectionStart">
<connectorParam name="keyCode"/>
<simpleCondition role="onSelection" key="$keyCode"/>
<simpleAction role="start"/>
</causalConnector>
<causalConnector id="onKeySelectionStop">
<connectorParam name="keyCode"/>
<simpleCondition role="onSelection" key="$keyCode"/>
<simpleAction role="stop"/>
</causalConnector>
© ABNT 2007 - Todos los derechos reservados
281
ABNT NBR 15606-2:2007
<causalConnector id="onKeySelectionPause">
<connectorParam name="keyCode"/>
<simpleCondition role="onSelection" key="$keyCode"/>
<simpleAction role="pause"/>
</causalConnector>
<causalConnector id="onKeySelectionResume">
<connectorParam name="keyCode"/>
<simpleCondition role="onSelection" key="$keyCode"/>
<simpleAction role="resume"/>
</causalConnector>
<causalConnector id="onKeySelectionSetVar">
<connectorParam name="keyCode"/>
<connectorParam name="var"/>
<simpleCondition role="onSelection" key="$keyCode"/>
<simpleAction role="set" value="$var"/>
</causalConnector>
<!-- OnBeginAttribution -->
<causalConnector id="onBeginAttributionStart">
<simpleCondition role="onBeginAttribution"/>
<simpleAction role="start"/>
</causalConnector>
<causalConnector id="onBeginAttributionStop">
<simpleCondition role="onBeginAttribution"/>
<simpleAction role="stop"/>
</causalConnector>
<causalConnector id="onBeginAttributionPause">
<simpleCondition role="onBeginAttribution"/>
<simpleAction role="pause"/>
</causalConnector>
<causalConnector id="onBeginAttributionResume">
<simpleCondition role="onBeginAttribution"/>
<simpleAction role="resume"/>
</causalConnector>
<causalConnector id="onBeginAttributionSet">
<connectorParam name="var"/>
<simpleCondition role="onBeginAttribution"/>
<simpleAction role="set" value="$var"/>
</causalConnector>
<!-- OnEndAttribution -->
<causalConnector id="onEndAttributionStart">
<simpleCondition role="onEndAttribution"/>
<simpleAction role="start"/>
</causalConnector>
<causalConnector id="onEndAttributionStop">
<simpleCondition role="onEndAttribution"/>
<simpleAction role="stop"/>
</causalConnector>
<causalConnector id="onEndAttributionPause">
<simpleCondition role="onEndAttribution"/>
<simpleAction role="pause"/>
</causalConnector>
282
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
<causalConnector id="onEndAttributionResume">
<simpleCondition role="onEndAttribution"/>
<simpleAction role="resume"/>
</causalConnector>
<causalConnector id="onEndAttributionSet">
<connectorParam name="var"/>
<simpleCondition role="onEnd"/>
<simpleAction role="set" value="$var"/>
</causalConnector>
<!-- OnBegin multiple actions -->
<causalConnector id="onBeginStartStop">
<simpleCondition role="onBegin"/>
<compoundAction operator="seq">
<simpleAction role="start"/>
<simpleAction role="stop"/>
</compoundAction>
</causalConnector>
<causalConnector id="onBeginStartPause">
<simpleCondition role="onBegin"/>
<compoundAction operator="seq">
<simpleAction role="start"/>
<simpleAction role="pause"/>
</compoundAction>
</causalConnector>
<causalConnector id="onBeginStartResume">
<simpleCondition role="onBegin"/>
<compoundAction operator="seq">
<simpleAction role="start"/>
<simpleAction role="resume"/>
</compoundAction>
</causalConnector>
<causalConnector id="onBeginStartSet">
<connectorParam name="var"/>
<simpleCondition role="onBegin"/>
<compoundAction operator="seq">
<simpleAction role="start"/>
<simpleAction role="set" value="$var"/>
</compoundAction>
</causalConnector>
<causalConnector id="onBeginStopStart">
<simpleCondition role="onBegin"/>
<compoundAction operator="seq">
<simpleAction role="stop"/>
<simpleAction role="start"/>
</compoundAction>
</causalConnector>
<causalConnector id="onBeginStopPause">
<simpleCondition role="onBegin"/>
<compoundAction operator="seq">
<simpleAction role="stop"/>
<simpleAction role="pause"/>
</compoundAction>
</causalConnector>
<causalConnector id="onBeginStopResume">
<simpleCondition role="onBegin"/>
© ABNT 2007 - Todos los derechos reservados
283
ABNT NBR 15606-2:2007
<compoundAction operator="seq">
<simpleAction role="stop"/>
<simpleAction role="resume"/>
</compoundAction>
</causalConnector>
<causalConnector id="onBeginStopSet">
<connectorParam name="var"/>
<simpleCondition role="onBegin"/>
<compoundAction operator="seq">
<simpleAction role="stop"/>
<simpleAction role="set" value="$var"/>
</compoundAction>
</causalConnector>
<causalConnector id="onBeginSetStart">
<connectorParam name="var"/>
<simpleCondition role="onBegin"/>
<compoundAction operator="seq">
<simpleAction role="set" value="$var"/>
<simpleAction role="start"/>
</compoundAction>
</causalConnector>
<causalConnector id="onBeginSetStop">
<connectorParam name="var"/>
<simpleCondition role="onBegin"/>
<compoundAction operator="seq">
<simpleAction role="set" value="$var"/>
<simpleAction role="stop"/>
</compoundAction>
</causalConnector>
<causalConnector id="onBeginSetPause">
<connectorParam name="var"/>
<simpleCondition role="onBegin"/>
<compoundAction operator="seq">
<simpleAction role="set" value="$var"/>
<simpleAction role="pause"/>
</compoundAction>
</causalConnector>
<causalConnector id="onBeginSetResume">
<connectorParam name="var"/>
<simpleCondition role="onBegin"/>
<compoundAction operator="seq">
<simpleAction role="set" value="$var"/>
<simpleAction role="resume"/>
</compoundAction>
</causalConnector>
<!-- OnEnd multiple actions -->
<causalConnector id="onEndStartStop">
<simpleCondition role="onEnd"/>
<compoundAction operator="seq">
<simpleAction role="start"/>
<simpleAction role="stop"/>
</compoundAction>
</causalConnector>
<causalConnector id="onEndStartPause">
<simpleCondition role="onEnd"/>
<compoundAction operator="seq">
284
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
<simpleAction role="start"/>
<simpleAction role="pause"/>
</compoundAction>
</causalConnector>
<causalConnector id="onEndStartResume">
<simpleCondition role="onEnd"/>
<compoundAction operator="seq">
<simpleAction role="start"/>
<simpleAction role="resume"/>
</compoundAction>
</causalConnector>
<causalConnector id="onEndStartSet">
<connectorParam name="var"/>
<simpleCondition role="onEnd"/>
<compoundAction operator="seq">
<simpleAction role="start"/>
<simpleAction role="set" value="$var"/>
</compoundAction>
</causalConnector>
<causalConnector id="onEndStopStart">
<simpleCondition role="onEnd"/>
<compoundAction operator="seq">
<simpleAction role="stop"/>
<simpleAction role="start"/>
</compoundAction>
</causalConnector>
<causalConnector id="onEndStopPause">
<simpleCondition role="onEnd"/>
<compoundAction operator="seq">
<simpleAction role="stop"/>
<simpleAction role="pause"/>
</compoundAction>
</causalConnector>
<causalConnector id="onEndStopResume">
<simpleCondition role="onEnd"/>
<compoundAction operator="seq">
<simpleAction role="stop"/>
<simpleAction role="resume"/>
</compoundAction>
</causalConnector>
<causalConnector id="onEndStopSet">
<connectorParam name="var"/>
<simpleCondition role="onEnd"/>
<compoundAction operator="seq">
<simpleAction role="stop"/>
<simpleAction role="set" value="$var"/>
</compoundAction>
</causalConnector>
<causalConnector id="onEndSetStart">
<connectorParam name="var"/>
<simpleCondition role="onEnd"/>
<compoundAction operator="seq">
<simpleAction role="set" value="$var"/>
<simpleAction role="start"/>
</compoundAction>
</causalConnector>
<causalConnector id="onEndSetStop">
© ABNT 2007 - Todos los derechos reservados
285
ABNT NBR 15606-2:2007
<connectorParam name="var"/>
<simpleCondition role="onEnd"/>
<compoundAction operator="seq">
<simpleAction role="stet" value="$var"/>
<simpleAction role="stop"/>
</compoundAction>
</causalConnector>
<causalConnector id="onEndSetPause">
<connectorParam name="var"/>
<simpleCondition role="onEnd"/>
<compoundAction operator="seq">
<simpleAction role="set" value="$var"/>
<simpleAction role="pause"/>
</compoundAction>
</causalConnector>
<causalConnector id="onEndSetResume">
<connectorParam name="var"/>
<simpleCondition role="onEnd"/>
<compoundAction operator="seq">
<simpleAction role="set" value="$var"/>
<simpleAction role="resume"/>
</compoundAction>
</causalConnector>
<!-- OnMouseSelection multiple actions -->
<causalConnector id="onSelectionStartStop">
<simpleCondition role="onSelection"/>
<compoundAction operator="seq">
<simpleAction role="start"/>
<simpleAction role="stop"/>
</compoundAction>
</causalConnector>
<causalConnector id="onSelectionStartPause">
<simpleCondition role="onSelection"/>
<compoundAction operator="seq">
<simpleAction role="start"/>
<simpleAction role="pause"/>
</compoundAction>
</causalConnector>
<causalConnector id="onSelectionStartResume">
<simpleCondition role="onSelection"/>
<compoundAction operator="seq">
<simpleAction role="start"/>
<simpleAction role="resume"/>
</compoundAction>
</causalConnector>
<causalConnector id="onSelectionStartSet">
<connectorParam name="var"/>
<simpleCondition role="onSelection"/>
<compoundAction operator="seq">
<simpleAction role="start"/>
<simpleAction role="set" value="$var"/>
</compoundAction>
</causalConnector>
<causalConnector id="onSelectionStopStart">
<simpleCondition role="onEnd"/>
<compoundAction operator="seq">
286
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
<simpleAction role="stop"/>
<simpleAction role="start"/>
</compoundAction>
</causalConnector>
<causalConnector id="onSelectionStopPause">
<simpleCondition role="onSelection"/>
<compoundAction operator="seq">
<simpleAction role="stop"/>
<simpleAction role="pause"/>
</compoundAction>
</causalConnector>
<causalConnector id="onSelectionStopResume">
<simpleCondition role="onSelection"/>
<compoundAction operator="seq">
<simpleAction role="stop"/>
<simpleAction role="resume"/>
</compoundAction>
</causalConnector>
<causalConnector id="onSelectionStopSet">
<connectorParam name="var"/>
<simpleCondition role="onSelection"/>
<compoundAction operator="seq">
<simpleAction role="stop"/>
<simpleAction role="set" value="$var"/>
</compoundAction>
</causalConnector>
<causalConnector id="onSelectionSetStart">
<connectorParam name="var"/>
<simpleCondition role="onSelection"/>
<compoundAction operator="seq">
<simpleAction role="set" value="$var"/>
<simpleAction role="start"/>
</compoundAction>
</causalConnector>
<causalConnector id="onSelectionSetStop">
<connectorParam name="var"/>
<simpleCondition role="onSelection"/>
<compoundAction operator="seq">
<simpleAction role="stet" value="$var"/>
<simpleAction role="stop"/>
</compoundAction>
</causalConnector>
<causalConnector id="onSelectionSetPause">
<connectorParam name="var"/>
<simpleCondition role="onSelection"/>
<compoundAction operator="seq">
<simpleAction role="set" value="$var"/>
<simpleAction role="pause"/>
</compoundAction>
</causalConnector>
<causalConnector id="onSelectionSetResume">
<connectorParam name="var"/>
<simpleCondition role="onSelection"/>
<compoundAction operator="seq">
<simpleAction role="set" value="$var"/>
<simpleAction role="resume"/>
</compoundAction>
</causalConnector>
© ABNT 2007 - Todos los derechos reservados
287
ABNT NBR 15606-2:2007
<!-- OnKeySelection multiple actions -->
<causalConnector id="onKeySelectionStartStop">
<connectorParam name="keyCode"/>
<simpleCondition role="onSelection" key="$keyCode"/>
<compoundAction operator="seq">
<simpleAction role="start"/>
<simpleAction role="stop"/>
</compoundAction>
</causalConnector>
<causalConnector id="onKeySelectionStartPause">
<connectorParam name="keyCode"/>
<simpleCondition role="onSelection" key="$keyCode"/>
<compoundAction operator="seq">
<simpleAction role="start"/>
<simpleAction role="pause"/>
</compoundAction>
</causalConnector>
<causalConnector id="onKeySelectionStartResume">
<connectorParam name="keyCode"/>
<simpleCondition role="onSelection" key="$keyCode"/>
<compoundAction operator="seq">
<simpleAction role="start"/>
<simpleAction role="resume"/>
</compoundAction>
</causalConnector>
<causalConnector id="onKeySelectionStartSet">
<connectorParam name="var"/>
<connectorParam name="keyCode"/>
<simpleCondition role="onSelection" key="$keyCode"/>
<compoundAction operator="seq">
<simpleAction role="start"/>
<simpleAction role="set" value="$var"/>
</compoundAction>
</causalConnector>
<causalConnector id="onKeySelectionStopStart">
<connectorParam name="keyCode"/>
<simpleCondition role="onSelection" key="$keyCode"/>
<compoundAction operator="seq">
<simpleAction role="stop"/>
<simpleAction role="start"/>
</compoundAction>
</causalConnector>
<causalConnector id="onKeySelectionStopPause">
<connectorParam name="keyCode"/>
<simpleCondition role="onSelection" key="$keyCode"/>
<compoundAction operator="seq">
<simpleAction role="stop"/>
<simpleAction role="pause"/>
</compoundAction>
</causalConnector>
<causalConnector id="onKeySelectionStopResume">
<connectorParam name="keyCode"/>
<simpleCondition role="onSelection" key="$keyCode"/>
<compoundAction operator="seq">
<simpleAction role="stop"/>
<simpleAction role="resume"/>
288
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
</compoundAction>
</causalConnector>
<causalConnector id="onKeySelectionStopSet">
<connectorParam name="var"/>
<connectorParam name="keyCode"/>
<simpleCondition role="onSelection" key="$keyCode"/>
<compoundAction operator="seq">
<simpleAction role="stop"/>
<simpleAction role="set" value="$var"/>
</compoundAction>
</causalConnector>
<causalConnector id="onKeySelectionSetStart">
<connectorParam name="var"/>
<connectorParam name="keyCode"/>
<simpleCondition role="onSelection" key="$keyCode"/>
<compoundAction operator="seq">
<simpleAction role="set" value="$var"/>
<simpleAction role="start"/>
</compoundAction>
</causalConnector>
<causalConnector id="onKeySelectionSetStop">
<connectorParam name="var"/>
<connectorParam name="keyCode"/>
<simpleCondition role="onSelection" key="$keyCode"/>
<compoundAction operator="seq">
<simpleAction role="set" value="$var"/>
<simpleAction role="stop"/>
</compoundAction>
</causalConnector>
<causalConnector id="onKeySelectionSetPause">
<connectorParam name="var"/>
<connectorParam name="keyCode"/>
<simpleCondition role="onSelection" key="$keyCode"/>
<compoundAction operator="seq">
<simpleAction role="set" value="$var"/>
<simpleAction role="pause"/>
</compoundAction>
</causalConnector>
<causalConnector id="onKeySelectionSetResume">
<connectorParam name="var"/>
<connectorParam name="keyCode"/>
<simpleCondition role="onSelection" key="$keyCode"/>
<compoundAction operator="seq">
<simpleAction role="set" value="$var"/>
<simpleAction role="resume"/>
</compoundAction>
</causalConnector>
<!-- OnBeginAttribution multiple actions -->
<causalConnector id="onBeginAttributionStartStop">
<simpleCondition role="onBeginAttribution"/>
<compoundAction operator="seq">
<simpleAction role="start"/>
<simpleAction role="stop"/>
</compoundAction>
</causalConnector>
<causalConnector id="onBeginAttributionStartPause">
© ABNT 2007 - Todos los derechos reservados
289
ABNT NBR 15606-2:2007
<simpleCondition role="onBeginAttribution"/>
<compoundAction operator="seq">
<simpleAction role="start"/>
<simpleAction role="pause"/>
</compoundAction>
</causalConnector>
<causalConnector id="onBeginAttributionStartResume">
<simpleCondition role="onBeginAttribution"/>
<compoundAction operator="seq">
<simpleAction role="start"/>
<simpleAction role="resume"/>
</compoundAction>
</causalConnector>
<causalConnector id="onBeginAttributionStartSet">
<connectorParam name="var"/>
<simpleCondition role="onBeginAttribution"/>
<compoundAction operator="seq">
<simpleAction role="start"/>
<simpleAction role="set" value="$var"/>
</compoundAction>
</causalConnector>
<causalConnector id="onBeginAttributionStopStart">
<simpleCondition role="onBeginAttribution"/>
<compoundAction operator="seq">
<simpleAction role="stop"/>
<simpleAction role="start"/>
</compoundAction>
</causalConnector>
<causalConnector id="onBeginAttributionStopPause">
<simpleCondition role="onBeginAttribution"/>
<compoundAction operator="seq">
<simpleAction role="stop"/>
<simpleAction role="pause"/>
</compoundAction>
</causalConnector>
<causalConnector id="onBeginAttributionStopResume">
<simpleCondition role="onBeginAttribution"/>
<compoundAction operator="seq">
<simpleAction role="stop"/>
<simpleAction role="resume"/>
</compoundAction>
</causalConnector>
<causalConnector id="onBeginAttributionStopSet">
<connectorParam name="var"/>
<simpleCondition role="onBeginAttribution"/>
<compoundAction operator="seq">
<simpleAction role="stop"/>
<simpleAction role="set" value="$var"/>
</compoundAction>
</causalConnector>
<causalConnector id="onBeginAttributionSetStart">
<connectorParam name="var"/>
<simpleCondition role="onBeginAttribution"/>
<compoundAction operator="seq">
<simpleAction role="set" value="$var"/>
<simpleAction role="start"/>
</compoundAction>
</causalConnector>
290
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
<causalConnector id="onBeginAttributionSetStop">
<connectorParam name="var"/>
<simpleCondition role="onBeginAttribution"/>
<compoundAction operator="seq">
<simpleAction role="set" value="$var"/>
<simpleAction role="stop"/>
</compoundAction>
</causalConnector>
<causalConnector id="onBeginAttributionSetPause">
<connectorParam name="var"/>
<simpleCondition role="onBeginAttribution"/>
<compoundAction operator="seq">
<simpleAction role="set" value="$var"/>
<simpleAction role="pause"/>
</compoundAction>
</causalConnector>
<causalConnector id="onBeginAttributionSetResume">
<connectorParam name="var"/>
<simpleCondition role="onBeginAttribution"/>
<compoundAction operator="seq">
<simpleAction role="set" value="$var"/>
<simpleAction role="resume"/>
</compoundAction>
</causalConnector>
<!-- OnEndAttribution multiple actions -->
<causalConnector id="onEndAttributionStartStop">
<simpleCondition role="onEndAttribution"/>
<compoundAction operator="seq">
<simpleAction role="start"/>
<simpleAction role="stop"/>
</compoundAction>
</causalConnector>
<causalConnector id="onEndAttributionStartPause">
<simpleCondition role="onEndAttribution"/>
<compoundAction operator="seq">
<simpleAction role="start"/>
<simpleAction role="pause"/>
</compoundAction>
</causalConnector>
<causalConnector id="onEndAttributionStartResume">
<simpleCondition role="onEndAttribution"/>
<compoundAction operator="seq">
<simpleAction role="start"/>
<simpleAction role="resume"/>
</compoundAction>
</causalConnector>
<causalConnector id="onEndAttributionStartSet">
<connectorParam name="var"/>
<simpleCondition role="onEndAttribution"/>
<compoundAction operator="seq">
<simpleAction role="start"/>
<simpleAction role="set" value="$var"/>
</compoundAction>
</causalConnector>
<causalConnector id="onEndAttributionStopStart">
© ABNT 2007 - Todos los derechos reservados
291
ABNT NBR 15606-2:2007
<simpleCondition role="onEndAttribution"/>
<compoundAction operator="seq">
<simpleAction role="stop"/>
<simpleAction role="start"/>
</compoundAction>
</causalConnector>
<causalConnector id="onEndAttributionStopPause">
<simpleCondition role="onEndAttribution"/>
<compoundAction operator="seq">
<simpleAction role="stop"/>
<simpleAction role="pause"/>
</compoundAction>
</causalConnector>
<causalConnector id="onEndAttributionStopResume">
<simpleCondition role="onEndAttribution"/>
<compoundAction operator="seq">
<simpleAction role="stop"/>
<simpleAction role="resume"/>
</compoundAction>
</causalConnector>
<causalConnector id="onEndAttributionStopSet">
<connectorParam name="var"/>
<simpleCondition role="onEndAttribution"/>
<compoundAction operator="seq">
<simpleAction role="stop"/>
<simpleAction role="set" value="$var"/>
</compoundAction>
</causalConnector>
<causalConnector id="onEndAttributionSetStart">
<connectorParam name="var"/>
<simpleCondition role="onEndAttribution"/>
<compoundAction operator="seq">
<simpleAction role="set" value="$var"/>
<simpleAction role="start"/>
</compoundAction>
</causalConnector>
<causalConnector id="onEndAttributionSetStop">
<connectorParam name="var"/>
<simpleCondition role="onEndAttribution"/>
<compoundAction operator="seq">
<simpleAction role="stet" value="$var"/>
<simpleAction role="stop"/>
</compoundAction>
</causalConnector>
<causalConnector id="onEndAttributionSetPause">
<connectorParam name="var"/>
<simpleCondition role="onEndAttribution"/>
<compoundAction operator="seq">
<simpleAction role="set" value="$var"/>
<simpleAction role="pause"/>
</compoundAction>
</causalConnector>
<causalConnector id="onEndAttributionSetResume">
<connectorParam name="var"/>
<simpleCondition role="onEndAttribution"/>
<compoundAction operator="seq">
<simpleAction role="set" value="$var"/>
<simpleAction role="resume"/>
292
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-2:2007
</compoundAction>
</causalConnector>
<!--Miscellaneous-->
<causalConnector id="onKeySelectionStopResizePauseStart">
<connectorParam name="width"/>
<connectorParam name="height"/>
<connectorParam name="left"/>
<connectorParam name="top"/>
<connectorParam name="keyCode"/>
<simpleCondition role="onSelection" key="$keyCode"/>
<compoundAction operator="seq">
<simpleAction role="stop"/>
<simpleAction role="setWidth" value="$width"/>
<simpleAction role="setHeight" value="$height"/>
<simpleAction role="setLeft" value="$left"/>
<simpleAction role="setTop" value="$top"/>
<simpleAction role="pause"/>
<simpleAction role="start"/>
</compoundAction>
</causalConnector>
<causalConnector id="onEndResizeResume">
<connectorParam name="left"/>
<connectorParam name="top"/>
<connectorParam name="width"/>
<connectorParam name="height"/>
<simpleCondition role="onEnd"/>
<compoundAction operator="seq">
<simpleAction role="setLeft" value="$left"/>
<simpleAction role="setTop" value="$top"/>
<simpleAction role="setWidth" value="$width"/>
<simpleAction role="setHeight" value="$height"/>
<simpleAction role="resume"/>
</compoundAction>
</causalConnector>
<causalConnector id="onKeySelectionStopSetPauseStart">
<connectorParam name="bounds"/>
<connectorParam name="keyCode"/>
<simpleCondition role="onSelection" key="$keyCode"/>
<compoundAction operator="seq">
<simpleAction role="stop"/>
<simpleAction role="set" value="$bounds"/>
<simpleAction role="pause"/>
<simpleAction role="start"/>
</compoundAction>
</causalConnector>
</connectorBase>
</head>
</ncl>
© ABNT 2007 - Todos los derechos reservados
293
ABNT NBR 15606-2:2007
Bibliografía
[1]
ITU Recommendation J.201:2004, Harmonization of declarative content format for interactive television
applications
[2] ARIB STD-B24:2004, Data coding and transmission specifications for digital broadcasting
[3]
Cascading Style Sheets, Cascading Style Sheets, level 2, Bert Bos, Håkon Wium Lie, Chris Lilley, Ian
Jacobs. W3C Recommendation 12. Maio de 1998, disponínel em <http://www.w3.org/TR/REC-CSS2>
[4]
DVB-HTML, Perrot P. DVB-HTML - An Optional Declarative Language within MHP 1.1, EBU Technical
Review. 2001
[5]
Namespaces in XML, Namespaces in XML, W3C Recommendation. Janeiro de 1999
[6]
NCM Core, Soares L.F.G; Rodrigues R.F. Nested Context Model 3.0: Part 1 – NCM Core, Technical
Report, Departamento de Informática PUC-Rio. Maio de 2005, ISSN: 0103-9741. Também disponível em
<http://www.ncl.org.br>
[7]
NCL Digital TV Profiles, Soares L.F.G; Rodrigues R.F. Part 8 – NCL (Nested Context Language) Digital TV
Profiles, Technical Report, Departamento de Informática PUC-Rio, No. 35/06. Outubro de 2006, ISSN:
0103-9741. Também disponível em <http://www.ncl.org.br>
[8]
NCL Live Editing Commands, Soares L.F.G; Rodrigues R.F; Costa, R.R.; Moreno, M.F. Part 9 – NCL Live
Editing Commands. Technical Report, Departamento de Informática PUC-Rio, No. 36/06. Dezembro de
2006, ISSN: 0103-9741. Também disponível em <http://www.ncl.org.br>
[9]
NCL-Lua, Cerqueira, R,; Sant’Anna, F. Nested Context Model 3.0: Part 11 – Lua Scripting Language for
NCL, Technical Report, Departamento de Informática PUC-Rio. Maio de 2007, ISSN: 0103-9741.
[10]
NCL Main Profile, Soares L.F.G; Rodrigues R.F; Costa, R.R. Nested Context Model 3.0: Part 6 – NCL
(Nested Context Language) Main Profile, Technical Report, Departamento de Informática PUC-Rio. Maio
de 2005, ISSN: 0103-9741. Também disponível em <http://www.ncl.org.br>
[11]
RDF, Resource Description Framework (RDF) Model and Syntax Specification, Ora Lassila and Ralph R.
Swick. W3C Recommendation. 22 de fevereiro de 1999. Disponível em <http://www.w3.org/TR/REC-rdfsyntax/>
[12]
SMIL 2.1 Specification, SMIL 2.1 - Synchronized Multimedia Integration Language – SMIL 2.1 Specification,
W3C Recommendation. Dezembro de 2005
[13]
XHTML 1.0, XHTML™ 1.0 2º Edition - Extensible HyperText Markup Language, W3C Recommendation,
Agosto de 2002
[14]
Programming in Lua,
ISBN 85-903798-2-5.
[15]
294
Segunda
Edição,
de
Roberto
Ierusalimschy
et
al.
Março
de
2006,
ACAP, Advanced Application Platform (ACAP), ATSC Standard: Document A/101. Agosto de 2005
© ABNT 2007 - Todos los derechos reservados
NORMA
BRASILEÑA
ABNT NBR
15606-3
Primera edición
30.11.2007
Válida a partir de
01.12.2007
Televisión digital terrestre — Codificación de
datos y espacificaciones de transmisión para
radiodifusión digital
Parte 3: Espacificación de transmisión de
datos
Palabras clave: Televisión digital terrestre. Radiodifusión digital. Transmisión
de datos.
ICS 33.160.
ISBN 978-85-07-00932-0
Número de referencia
ABNT NBR 15606-3:2008
82 páginas
© ABNT 2007
ABNT NBR 15606-3:2007
© ABNT 2007
Todos los derechos reservados. A menos que se especifique de otro modo, ninguna parte de esta publicación puede ser
reproducida o utilizada por cualquier medio, electrónico o mecánico, incluyendo fotocopia y microfilm, sin permiso por escrito de
la ABNT.
ABNT
Av.Treze de Maio, 13 - 28º andar
20031-901 - Rio de Janeiro - RJ
Tel.: + 55 21 3974-2300
Fax: + 55 21 2220-1762
abnt@abnt.org.br
www.abnt.org.br
Impresso en Brasi
ii
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-3:2007
Índice
Página
Prefacio.......................................................................................................................................................................vi
1
Alcance ...........................................................................................................................................................1
2
Referencias normativas ................................................................................................................................1
3
Términos y definiciones................................................................................................................................2
4
Tipos de especificación de transmisión de datos .....................................................................................7
5
5.1
5.2
5.2.1
5.2.2
5.3
5.4
5.4.1
5.4.2
5.4.3
5.4.4
5.4.5
5.4.6
5.4.7
5.4.8
5.4.9
5.5
5.5.1
5.5.2
5.5.3
5.5.4
Especificación de transmisión del carrusel de datos................................................................................8
Transmisión con carrusel de datos DSM-CC .............................................................................................8
Mensaje de control DSM-CC.........................................................................................................................8
Mensaje de indicación de información de download (DII) ........................................................................8
Sintaxis y semántica del mensaje DII ..........................................................................................................8
Sintaxis y semántica del dsmccMessageHeader()...................................................................................10
Descriptores del área de información del módulo y área privada .........................................................12
Tipos de descriptores .................................................................................................................................12
Descriptor de tipo ........................................................................................................................................12
Descriptor del nombre ................................................................................................................................13
Descriptor de información ..........................................................................................................................13
Descriptor del Module_link.........................................................................................................................14
Descriptor de la localización ......................................................................................................................14
Descriptor CRC ............................................................................................................................................15
Descriptor de tiempo estimado de download...........................................................................................15
Descriptor de tipo de compresión .............................................................................................................15
Mensaje DownloadDataBlock (DDB) .........................................................................................................16
Sintaxis y semántica del mensaje DDB.....................................................................................................16
Sintaxis y semántica del dsmccDownloadDataHeader().........................................................................16
Sintaxis del dsmccAdaptationHeader().....................................................................................................17
Sintaxis de la sección DSM-CC..................................................................................................................18
6
6.1
6.2
6.2.1
6.2.2
6.3
6.3.1
6.3.2
6.3.3
Especificación del carrusel de objetos .....................................................................................................20
Objetivo del carrusel de objetos ................................................................................................................20
Especificación del transporte de datos.....................................................................................................21
Dirección de carrusel NSAP .......................................................................................................................21
Estructura de la dirección NSAP del carrusel ..........................................................................................21
Descriptores.................................................................................................................................................22
Especificación PSI y SI ...............................................................................................................................22
Deferred_association_tags_descriptor .....................................................................................................22
Tipo de flujo .................................................................................................................................................23
7
7.1
7.2
7.3
7.4
Encapsulado multiprotocolo (MPE)...........................................................................................................24
Especificación de transporte de datos......................................................................................................24
Especificaciones PSI y SI ...........................................................................................................................26
Descriptor de protocolo de transporte......................................................................................................26
Tipo de stream .............................................................................................................................................28
8
8.1
8.2
8.3
8.4
Especificación de la transmisión del data piping ....................................................................................28
Especificación del transporte de datos.....................................................................................................28
Especificaciones PSI y SI ...........................................................................................................................28
Descriptor de protocolo de transporte......................................................................................................28
Tipo de stream .............................................................................................................................................28
9
9.1
9.2
9.3
Especificación de transmisión PES independiente .................................................................................28
Transmisión independiente de PES ..........................................................................................................28
PES sincronizada.........................................................................................................................................29
PES asíncrona..............................................................................................................................................29
© ABNT 2007 - Todos los derechos reservados
iii
ABNT NBR 15606-3:2008
10
Protocolos de transporte ............................................................................................................................30
10.1
Protocolo del canal de transmisión...........................................................................................................30
10.1.1 Stream de transporte MPEG-2....................................................................................................................30
10.1.2 Sección MPEG-2 ..........................................................................................................................................30
10.1.3 Datos privados DSM-CC .............................................................................................................................30
10.1.4 Carrusel de datos DSM-CC.........................................................................................................................31
10.1.5 Carrusel de objetos DSM-CC......................................................................................................................31
10.1.6 Protocolo IP de transporte de multicast en un canal de transmisión....................................................31
10.1.7 Protocolo IP..................................................................................................................................................31
10.1.8 Protocolo UDP .............................................................................................................................................31
10.1.9 Informaciones de servicio ..........................................................................................................................31
10.1.10 Señalización de IP .......................................................................................................................................32
10.2
Protocolos de canal de interacción ...........................................................................................................32
10.2.1 Pila de protocolo del canal interactivo......................................................................................................32
10.2.2 Protocolo dependiente de la red................................................................................................................32
10.2.3 Protocolo de internet (IP)............................................................................................................................32
10.2.4 Protocolo de control de transmisión (TCP) ..............................................................................................33
10.2.5 UNO-RPC ......................................................................................................................................................33
10.2.6 UNO-CDR......................................................................................................................................................33
10.2.7 DSM-CC usuario para usuario....................................................................................................................33
10.2.8 Protocolo HTTP............................................................................................................................................33
10.2.9 Protocolo específico para el servicio ........................................................................................................33
10.2.10 Protocolo de datagrama del usuario (UDP) ..............................................................................................33
10.2.11 DNS ...............................................................................................................................................................33
10.3
Protocolos de transporte para aplicaciones siendo cargados en el canal de interacción..................33
11
11.1
11.2
11.3
11.4
Modelo de aplicación ..................................................................................................................................33
Aplicación Ginga .........................................................................................................................................33
Modelo Ginga-J............................................................................................................................................34
Como manejar el modelo NCL ...................................................................................................................34
Gestión de recursos entre aplicaciones ...................................................................................................34
12
Transmisión de informaciones de aplicación ..........................................................................................34
12.1
Descriptores AIT y valores constantes .....................................................................................................34
12.2
Ejecución de la aplicación Ginga...............................................................................................................35
12.3
Señal de aplicaciones comunes ................................................................................................................36
12.4
Señal de aplicación adicional necesaria para Ginga-J............................................................................36
12.5
Informaciones adicionales en PSI/SI .........................................................................................................37
12.6
Identificación del componente de datos ...................................................................................................37
12.7
Descriptor de componente de datos y descriptor de contenidos de datos ..........................................37
12.7.1 Referencia indirecta ....................................................................................................................................37
12.7.2 Descriptor de componente de datos en aplicación Ginga - Sistema de codificación de datos..........38
12.7.3 Descriptor de contenidos de los datos en la aplicación Ginga - Sistema de contenido de datos .....40
12.7.4 Descriptor de componente de datos para transmisión AIT ....................................................................44
12.8
Localizador en descripción de aplicación ................................................................................................46
12.9
Descripción de aplicación ..........................................................................................................................46
12.10 Transmisión y monitoreo de descripción de aplicación .........................................................................47
12.11 Visibilidad de la descripción de aplicación ..............................................................................................47
12.12 Detalles de la descripción de aplicación...................................................................................................47
12.13 Tratamiento de la aplicación a partir del servicio previamente seleccionado......................................47
12.14 Descripción de aplicación específica al Ginga-J .....................................................................................47
12.15 Detalles de la descripción de aplicación Ginga .......................................................................................47
12.16 Sistema de codificación de información de aplicación...........................................................................47
12.16.1 Información de aplicación ..........................................................................................................................47
12.16.2 Application ID – Identificación de codificación de la aplicación............................................................49
12.16.3 Efecto sobre el ciclo de vida ......................................................................................................................50
12.16.4 Autenticación del ID de aplicación ............................................................................................................50
12.16.5 Control de aplicaciones de ciclo de vida ..................................................................................................50
12.16.6 Acceso y salida del dominio de la aplicación ..........................................................................................51
12.16.7 Control dinámico del ciclo de vida de las aplicaciones Ginga ...............................................................51
12.17 Descriptores para AIT - Descriptores para transmisión de informaciones de las aplicaciones.........52
12.17.1 Descriptores comunes ................................................................................................................................52
iv
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-3:2008
12.17.2 Descriptor de aplicación .............................................................................................................................52
12.17.3 Descriptor del nombre de aplicación ........................................................................................................54
12.17.4 Descriptor de la información de los iconos de la aplicación..................................................................54
12.17.5 Descriptor de autorización de aplicación externa ...................................................................................56
12.17.6 Transport protocol descriptor (descriptor de protocolo de transporte)................................................56
12.17.7 Transporte a través del OC (carrusel de objeto) ......................................................................................57
12.17.8 Transporte a través de IP............................................................................................................................58
12.17.9 Descriptor de señalización de IP ...............................................................................................................59
12.18 Descriptores de la aplicación Ginga-J ......................................................................................................62
12.18.1 Estructura del descriptor de aplicaciones Ginga.....................................................................................62
12.18.2 Descriptor de la localización de la aplicación Ginga...............................................................................62
13
13.1
13.2
13.2.1
13.2.2
13.3
13.4
13.5
13.6
Especificación de la transmisión del mensaje del evento ......................................................................63
Mensaje de evento.......................................................................................................................................63
Descriptores de stream...............................................................................................................................64
Descriptor de stream DSM-CC ...................................................................................................................64
Descriptor de referencia NPT .....................................................................................................................64
Descriptor de modo de stream...................................................................................................................66
Descriptores de evento de stream.............................................................................................................67
Descriptor de evento general .....................................................................................................................68
Sintaxis de sección de DSM-CC transmitiendo el descriptor de stream...............................................69
14
Sistema de archivo de difusión y transporte de disparador...................................................................71
Anexo A (normativo) Video y audio PES ................................................................................................................72
A.1
Formato de transmisión de datos a través de la PES de video MPEG-2 codificado............................72
A.2
Formato de transmisión de datos del audio PES codificado con MPEG-2 BC audio ..........................72
A.3
Formato de transmisión de datos del audio PES codificado con MPEG-2 AAC audio........................73
Anexo B (normativo) Información PSI/SI para transmisión de carruseles de datos y mensajes de eventos .74
B.1
Especificación de la codificación de datos con base en el carrusel de datos y esquema de evento
de mensaje ...................................................................................................................................................74
B.2
Contenido de enlace de additional_data_component_info y data_component_descriptor................74
B.3
Byte selector de data_contents_descriptor..............................................................................................75
B.3.1 Data structure ..............................................................................................................................................75
B.3.2 Estructura de datos para control de recepción de carrusel de datos para servicios de datos no
almacenados ................................................................................................................................................75
B.3.3 Estructura de datos para el control de la recepción del carrusel de datos para el servicio de datos
almacenados ................................................................................................................................................76
Anexo C (informativo) Relación entre el descriptor PMT/EIT y AIT .....................................................................79
Anexo D (informativo) Informaciones adicionales sobre trasmisiones utilizando independientes PES.........81
Bibliografia ................................................................................................................................................................82
© ABNT 2007 - Todos los derechos reservados
v
ABNT NBR 15606-3:2007
Prefacio
La Associação Brasileira de Normas Técnicas (ABNT) es el Fórum Nacional de Normalización. Las Normas
Brasileñas, cuyo contenido es responsabilidad de los Comités Brasileños (ABNT/CB), de los Organismos de
Normalización Sectorial (ABNT/ONS) y de las Comisiones de Estudios Especiales (ABNT/CEE), son elaboradas
por Comisiones de Estudio (CE), formadas por representantes de sus sectores implicados de los que forman
parte: productores, consumidores y neutrales (universidades, laboratorios y otros).
Los Documentos Técnicos ABNT se elaboran de acuerdo con las reglas de Directivas ABNT, Parte 2.
La Associação Brasileira de Normas Técnicas (ABNT) llama la atención sobre la posibilidad de que algunos de los
elementos de este documento pueden ser objeto de derechos de patente. La ABNT no debe ser considerada
responsable por la identificación de cualesquiera derechos de patente.
La ABNT NBR 15606-3 fue elaborada por la Comisión de Estudio Especial de Televisión Digital
(ABNT/CEE-00:001.85). El Proyecto circuló en Consulta Nacional según Edicto nº 09, de 06.09.2007 a 05.11.2007,
con el número de Proyecto 00:001.85-006/3.
En caso que surja cualquier duda con relación a la interpretación de la versión en español siempre deben
prevalecer las prescripciones de la versión en portugués
Esta Norma está basada en los trabajos del Fórum del Sistema Brasileiro de Televisão Digital Terrestre,
según establece el Decreto Presidencial nº 5.820, de 29/06/2006.
La ABNT NBR 15606, bajo el título general “Televisión digital terrestre – Codificación de datos y especificaciones
de transmisión para radiodifusión digital”, está previsto que contenga las siguientes partes:
⎯ Parte 1: Codificación de datos;
⎯ Parte 2: Ginga-NCL para receptores fijos y móviles – Lenguaje de aplicación XML para codificación de
aplicaciones;
⎯ Parte 3: Especificación de transmisión de datos;
⎯ Parte 4: Ginga-J – Ambiente para la ejecución de aplicaciones procedurales;
⎯ Parte 5: Ginga-NCL para receptores portátiles – Lenguaje de aplicación XML para codificación de aplicaciones.
Esta versión en español es equivalente a la versión corregida 2 de la ABNT NBR 15606-3:2007, de 22.08.2008.
vi
© ABNT 2007 - Todos los derechos reservados
NORMA BRASILEIRA
ABNT NBR 15606-3:2007
Televisión digital terrestre — Codificación de datos y espacificaciones de
transmisión para radiodifusión digital
Parte 3: Espacificación de transmisión de datos
1
Alcance
Esta parte de la ABNT NBR 15606 suministra una especificación de codificación y transmisión de datos para el
esquema de transmisión digital.
Esta parte de la ABNT NBR 15606 se aplica a la transmisión de datos realizada como parte de la transmisión
digital de datos.
2
Referencias normativas
Los documentos indicados a continuación son indispensables para la aplicación de este documento. Para las
referencias fechadas, se aplican solamente las ediciones citadas. Para las referencias sin fecha, se aplican las
ediciones más recientes del documento citado (incluyendo enmiendas).
ABNT NBR 15603-1, Televisión digital terrestre - Multiplexación y servicios de información (SI) – Parte 1: SI del
sistema de radiodifusión
ABNT NBR 15603-2:2007, Televisión digital terrestre – Multiplexación y servicios de información (SI) –
Parte 2: Estructura de datos y definiciones de la información básica de SI
ABNT NBR 15603-3, Televisión digital terrestre - Multiplexación y servicios de información (SI) – Parte 3: Sintaxis y
definiciones de información extendida del SI
ABNT NBR 15606-1, Televisión digital terrestre – Codificación de datos y especificaciones de transmisión para
radiodifusión digital - Parte 1: Codificación de datos
ABNT NBR 15606-2:2007, Televisión digital terrestre - Codificación de datos y especificaciones de transmisión
para radiodifusión digital - Parte 2: Ginga-NCL para receptores fijos y móviles – Lenguaje de aplicación XML para
codificación de aplicaciones
ISO 639-2, Codes for the representation of names of languages - Part 2: Alpha-3 code
ISO 8859-1, Information processing - 8-bit single-byte coded graphic character sets – Part 1: Latin alphabet Nº 1
ISO/IEC TR 8802-1, Information technology – Telecommunications and information exchange between systems –
Local and metropolitan area networks - Specific requirements - Part 1: Overview of Local Area Network Standards
ISO/IEC 8802-2, Information technology – Telecommunications and information exchange between systems –
Local and metropolitan area networks - Specific requirements - Part 2: Logical link control
ISO/IEC 13818-1, Information technology – Generic coding of moving pictures and associated audio information:
Systems
ISO/IEC 13818-6:1998, Information technology – Generic coding of moving pictures and associated audio
information – Part 6: Extensions for DSM-CC
© ABNT 2007 - Todos los derechos reservados
1
ABNT NBR 15606-3:2007
EN 300 468:2005, Digital video broadcasting (DVB); specification for service information (SI) in DVB systems
EN 301 192, Digital video broadcasting (DVB); DVB specification for data broadcasting
ARIB STD-B10:2007, Service information for digital broadcasting system
ARIB STD-B23:2004, Application execution engine platform for digital broadcasting
ARIB STD-B24:2007, Presentation engine platform for digital broadcasting
ETSI TR 101 162, Digital Video Broadcasting (DVB); Allocation of service information (SI), codes for DVB systems
ETSI TR 101 202, Digital Video Broadcasting (DVB); Implementation guidelines for data broadcasting
ETSI TS 101 812:2003, Multimedia home platform – MHP specification 1.03
GEM 1.0:2005, Globally executable MHP Version 1.02
GEM 1.1:2006, Globally executable MHP (GEM) Especification 1.1
IEEE 802:2001, IEEE Standard for Local and Metropolitan Area Networks: Overviem and Architecture
RFC 791, DARPA Internet program protocol specification
RFC 793:1981, Transmission Control Protocol Darpa Internet Program Protocol Specification
RFC 2396, URI Generic Syntax
RFC 1112, Host extensions for IP multicasting
RFC 1521, Borenstein N., and N. Freed, MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for
Specifying and Describing the Format of Internet Message
RFC 1950, ZLIB Compressed data format specification version 3.3
3
Términos y definiciones
Para los efectos de esta parte de la ABNT NBR 15606, se aplican los siguientes términos y definiciones.
3.1
acceso múltiple por división de código de múltiple portador
MC-CDMA
esquema de acceso múltiple por división de código (CDMA) que emplea sistemas de múltiples portadores
3.2
buffer de transporte
buffer que decodifica un paquete de stream de transporte en un decodificador-meta de un stream de transporte
MPEG2
3.3
encabezamiento del paquete PES
campo que comprende la primera parte de un paquete PES
2
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-3:2007
3.4
carrusel de datos
método que envía cualquier conjunto de datos repetidamente para que los datos puedan ser bajados vía
transmisión siempre que sea necesario
NOTA
Este método se especifica en la ISO/IEC 13818-6.
3.5
comando y control de almacenamiento de medios digital
DSMCC
método que brinda soporte al acceso a archivos y streams en servicio digital interactivo
3.6
comité para sistema de televisión avanzado
ATSC
comité con el propósito de estandarizar el sistema de transmisión digital en EUA
3.7
consejo audiovisual digital
DAVIC
Consorcio industrial para estandarización del servicio de multimedia interactiva
3.8
contenido
grupo de datos transmitidos por medio de un programa de transmisión de datos o servicio de comunicaciones
bidireccionales que es generado por el programa de transmisión de datos para servir como parte del programa de
transmisión de datos
NOTA
Como un término en el contexto de transmisión, "contenido" indica un conjunto de streams en el programa que
envía el grupo de datos. Un único programa de transmisión puede estar compuesto por múltiples contenidos.
3.9
contenido local
parte del contenido de transmisión de datos contenido en un único evento de datos
NOTA
Generalmente, un contenido local es un grupo de datos agrupados con base en el contexto o para una mayor
conveniencia de producción de programa.
3.10
DSM-CC U-U
Digital Storage Media – Command and Control User-to-User Interface
3.11
dirección
protocolo utilizado para definir un nombre de servidor utilizando el PPP
NOTA
Esta definición está de acuerdo con la RFC 1877.
3.12
ethernet
estándar LAN que define una red con base en barramento empleando el CSMA/CD (acceso múltiple de sentido de
portador/detección de colisión) para control de acceso
NOTA
Esta definición está de acuerdo con la IEEE 802.
© ABNT 2007 - Todos los derechos reservados
3
ABNT NBR 15606-3:2007
3.13
evento de datos
conjunto de streams de transmisión de datos que representa un grupo de contenido de transmisión de datos a ser
distribuido con los tiempos de inicio y finalización preconfigurados
NOTA
El concepto de evento de datos (data event) es introducido para permitir que un grupo de contenido de transmisión
de datos sea alternado para otro, si están o no en el mismo programa, conforme sea necesario. En otras palabras, un evento
de datos es independiente de un evento.
3.14
formato de adaptación
formato utilizado en un encabezamiento DSM-CC y que es una forma de información inserida en un área de
adaptación que codifica la información para atender a una solicitación, dependiendo de la red de distribución
3.15
hash function
función embrollo
función matemática que mapea un área amplia (inmensa en algunos casos) dentro de una pequeña banda
NOTA
Una hash function es de dirección única y libre de colisión.
3.16
host
máquina
dispositivo de punto de acceso o dispositivo de servidor, necesario para servicios de transmisión bidireccional
3.17
hypertext transfer protocol
HTTP
capa de aplicación para transmitir datos a través de la World Wide Web
NOTA
Esta definición está de acuerdo con la RFC 1954.
3.18
identificador de paquete
PID
identificador de paquete de un stream de transporte MPEG-2
3.19
información de servicio
SI
datos digitales que describen un arreglo de programas, un sistema de distribución para transmisión de streams de
datos, descripción de programas, informaciones de parrilla de programación/tiempo de duración
NOTA
Estos datos también transportan MPEG-2 PSI (Informaciones Específicas del Programa), así como partes de la
extensión definidas de forma independiente.
3.20
información específica del programa
PSI
información de control de transmisión, que suministra la información necesaria para permitir a un receptor
automáticamente demultiplexar y decodificar varios streams de programa que fueron multiplexados
3.21
MIME
protocolo de capa de aplicación que suministra una arquitectura de contenido que permite que datos multimedia,
como archivos de texto, audio e imágenes, en formato que no sea US-ASCII, sean transmitidos vía e-mail
4
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-3:2007
3.22
paquete PES
formato de datos usado para transmitir streams básicos que consiste en un encabezamiento de paquete PES
y una carga útil PES inmediatamente siguiendo el encabezamiento
3.23
private_stream_1
Tipo de stream transmitido usando PES y que se utiliza para transmitir un stream privado sincronizado con otros
streams
3.24
private_stream_2
tipo de stream transmitido usando PES y que se utiliza para transmitir un stream privado que no necesita ser
sincronizado con otros streams
3.25
procedimiento de control de conexión de datos de alto nivel
procedimiento HDLC
procedimiento de control de transmisión con alta confiabilidad, usado para comunicación entre computadoras,
principalmente en LAN e internet
3.26
protocolo datagrama del usuario
UDP
protocolo de capa de transporte que promueve entrega de datos sin conexión entre dos máquinas
NOTA 1
Aunque el UDP no soporte mensajes de reconocimiento, minimiza el protocolo elevado para mayor eficiencia en
servicios de transmisión.
NOTA 2
Esta definición está de acuerdo con la RFC 768.
3.27
protocolo de autenticación de contraseña NNTP
protocolo de capa de aplicación utilizado para distribuir, enviar y recuperar noticias (Net News) en Internet
NOTA
Esta definición está de acuerdo con la RFC 1334.
3.28
protocolo de autenticación de contraseña PAP
componente del protocolo de punto a punto (PPP) que soporta la autenticación
NOTA 1
Este protocolo no hace identificación de usuario y contraseña al enviar.
NOTA 2
Esta definición ésta de acuerdo con la RFC 1334.
3.29
protocolo de control de transmisión
TCP
protocolo de capa de transporte que promueve distribución de datos altamente confiable, de punta la punta,
orientada por conexión, utilizando un mecanismo de detección y corrección de error
NOTA
Esta definición está de acuerdo con la RFC 793.
3.30
protocolo de control IP
IPCP
protocolo utilizado para establecer varias configuraciones exigidas para utilizar IP en la fase de protocolo de capa
de red
NOTA
Esta definición está de acuerdo con la RFC 1332.
© ABNT 2007 - Todos los derechos reservados
5
ABNT NBR 15606-3:2007
3.31
protocolo de internet
IP
protocolo de capa de red que define el mecanismo de encaminamiento en Internet para permitir que los datos
sean transmitidos
NOTA
Esta definición está de acuerdo con la RFC 791.
3.32
protocolo de resolución de dirección
ARP
Protocolo utilizado en una red TCP/IP para obtener la dirección física del nudo Ethernet basado en su dirección de
IP
3.33
protocolo de transmisión de datos en modo básico
protocolo de comunicaciones desarrollados para transmisión básica de datos entre un host y un terminal
NOTA
El protocolo emplea un método para minimizar los errores de transmisión.
3.34
red digital de servicios integrados
ISDN
red digital de servicios integrados
3.35
reservado
término que, cuando se utiliza en sentencias que definen el stream de bit codificado, indica que el valor se puede
usar en el futuro para extensiones definidas por la ISO
NOTA
Los bits reservados se configuran en 1.
3.36
reserved_future_use
término que, cuando se utiliza en sentencias definiendo el stream de bit codificado, indica que el valor se puede
utilizar en extensiones definidas por la ISO en el futuro
NOTA
Los bits reservados se configuran en 1.
3.37
sección
Estructura sintáctica utilizada para mapear las informaciones de servicio y otros datos dentro de un paquete de
stream de transporte
3.38
servicio de nombre de dominio
DNS
protocolo utilizado por el servicio que mapea un nombre de máquina en una red dentro de su dirección de IP
NOTA
Esta definición está de acuerdo con las RFC 1034 y RFC 1035.
3.39
tabla de información de evento
EIT
tabla de información de evento que contiene datos relacionados a un evento y un programa como un nombre de
evento (programa), hora de inicio y un período
6
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-3:2007
3.40
tabla de mapeo de programa
PMT
tabla que forma parte del PSI
3.41
transmisión de video digital
DVB
proyecto para estandarización del sistema de transmisión digital en Europa
4
Tipos de especificación de transmisión de datos
Los tipos de especificaciones para transmisión de datos e identificación de tipo de stream contenidas en un PMT
se presentan en la Tabla 1.
Tabla 1 – Tipos de especificación de transmisión
Especificación de la transmisión
Función mayoritaria y facilidad de uso
PES independiente
Utilizado para streams de datos
sincronizados a asíncronos para servicios de
radiodifusión
Carrusel de datos/objetos
Utilizado para transferencias de datos en
general: Sincronizados y asíncronos para
servicios de radiodifusión. Aplicado a la
transmisión de datos para servicios de
download y servicios multimedia
Mensaje de eventos
Protocolos de canal de
interactividad
Identificación del tipo de stream
0x06
0x0B, 0X0D a
Utilizado para notificaciones sincronizadas y
asíncronas referentes a las aplicaciones en
el TA partiendo de la estaca de broadcast.
Utilizado para servicios de multimedia
0x0C, 0X0D b
Protocolo de transmisión utilizado en redes
fijas como redes PSTN/ISDN y redes de
celular, incluyendo red celular/PHS con
d
comunicaciones bidireccionales
—
Encapsulado multiprotocolo
Datagramas son encapsulados en
datagram_sections Que son compatibles con
el formato DSMCC_section para datos
privados
Data piping
Protocolo que permite insertar datos de una
red de radiodifusión directamente en el
payload del paquete MPEG-2
0x0A
c
0x7E
a
Cuando un stream no contiene datos DSM-CC, sino un carrusel de datos, se utiliza 0x0B ó 0x0D y, cuando también tiene
otros datos se utiliza DSM-CC, 0x0D.
b
Cuando un stream no contiene datos DSM-CC, sino como mensaje de evento, se utiliza 0x0C ó 0x0D y, cuando también
tiene otros datos DSM-CC, se utiliza 0x0D.
c
Cuando un stream no contiene datos DSM-CC, sino datos de encapsulado de multiprotocolos (MPE), se utiliza 0x0A y,
cuando también tiene otros datos DSM-CC, se utiliza 0x0D.
d
PSTN: Red Telefónica conmutada pública.
© ABNT 2007 - Todos los derechos reservados
7
ABNT NBR 15606-3:2007
5
Especificación de transmisión del carrusel de datos
5.1
Transmisión con carrusel de datos DSM-CC
La especificación de transmisión del carrusel de datos se destina a implementar la transmisión general
sincronizada o asíncrona sin la necesidad de datos streaming, tales como download de datos para una unidad
receptora o transmisión de contenidos para servicios de multimedia. La especificación de transmisión del carrusel
de datos definida en esta Norma se basa en la especificación del carrusel de datos DSM-CC establecida en la
ISO/I EC 13818-6.
La transmisión repetida de datos, como es definida en la especificación del carrusel de datos DSC-CC, permite a
la unidad receptora obtener datos por demanda en cualquier momento durante un período de transmisión.
Los datos se transmiten en una unidad modular formada por bloques donde todos los bloques, excepto los que
están al final del módulo, tienen el mismo tamaño y cada bloque se transmite en secciones.
En la transmisión de estos datos se utilizan el mensaje download de bloque de datos (referida como mensaje
DDB) y mensaje de indicación de información download (referida como mensaje DII). Ambos mensajes son
componentes del protocolo de download del usuario de la red especificado en la ISO/IEC 13818-6. El cuerpo de
datos se transmite por el mensaje DDB con cada módulo dividido dentro de los bloques. Para informaciones
adicionales relacionadas a la transmisión PSI/SI, ver el Anexo B.
5.2 Mensaje de control DSM-CC
5.2.1
Mensaje de indicación de información de download (DII)
Un mensaje DII forma parte de un mensaje de control DSM-CC. Así, el mensaje DII transmite el contenido del
mensaje reteniéndolo en el userNetworkMessage() en la sección DSM-CC.
La versión del mensaje DII es indicada por el transaction_number (número de la transacción) en el campo
transaction_id (identificación de transacción) del dsmccMessageHeader. Este número de versión es común a
todos los mensajes DII del carrusel de datos y el número de la versión se incrementa en uno cuando el contenido
de uno o más mensajes DII se altera.
5.2.2
Sintaxis y semántica del mensaje DII
La estructura de los datos del mensaje DII se presenta en la Tabla 2.
8
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-3:2007
Tabla 2 — Estructura de los datos del mensaje de indicación de información de download
Sintaxis
DownloadInfoIndication() {
dsmccMessageHeader()
downloadId
blockSize
windowSize
ackPeriod
tCDownloadWindow
tCDownloadScenario
compatibilityDescriptor()
numberOfModules
for(i=0;i< numberOfModules;i++) {
moduleId
moduleSize
moduleVersion
moduleInfoLength
for(i=0;i< moduleInfoLength;i++){
moduleInfoByte
}
}
privateDataLength
for(i=0;i<privateDataLength;i++){
privateDataByte
}
}
Número de bits
Mnemónico
32
16
8
8
32
32
uimsbf
uimsbf
uimsbf
uimsbf
uimsbf
uimsbf
16
uimsbf
16
32
8
8
uimsbf
uimsbf
uimsbf
uimsbf
8
uimsbf
16
uimsbf
8
uimsbf
La semántica de los campos DII debe ser la siguiente:
⎯ dsmccMessageHeader () (encabezamiento del mensaje DSM-CC): tal como especificado en 5.3;
⎯ downloadId (identificador de download): campo de 32 bits que sirve como un rótulo para la identificación
única del carrusel de datos. En el caso de evento de operación de datos, data_event_id (identificación del
evento de datos) debe ser insertado en los bits 28-31 del downloadId (identificador de download). En caso
contrario, la banda y los valores para asegurar la unicidad se especifica en un estándar operativo;
⎯ windowSize: campo de 8 bits que no se utiliza para transmisión del carrusel de datos y el valor debe ser
ajustado en 0;
⎯ ackPeriod: campo de 8 bits que no se utiliza en la transmisión del carrusel de datos y el valor debe ser
ajustado en 0;
⎯ tCDownloadWindow: campo de 32 bits que no se utiliza en la transmisión del carrusel de datos y el valor
debe ser ajustado en 0;
⎯ tCDownloadScenario: campo de 32 bits que indica el período de límite de tiempo en el que se presume que
el download está completo en microsegundos;
⎯ compatibilityDescriptor(): estructura del descriptor de compatibilidad (compatibilityDescriptor()) que se
especifica en la ISO/IEC 13818-6 y que debe ser configurada en este campo. Cuando el contenido de la
estructura del compatibilityDescriptor() no es necesaria, el descriptorCount se debe configurar en 0x0000 y,
así, la extensión del campo debe ser de 4 bytes;
© ABNT 2007 - Todos los derechos reservados
9
ABNT NBR 15606-3:2007
⎯ numberOfModules (número de módulo): campo de 16 bits que indica el número de módulos descritos en el
enlace siguiente en este mensaje DII;
⎯ moduleId (identificador de módulo): campo de 16 bits que indica la identificación del módulo descrito en los
siguientes campos: ModuleSize, module Version y moduleInfoByte;
⎯ moduleSize (extensión del módulo): campo de 32 bits que indica la extensión byte del módulo. Cuando la
extensión del byte del módulo no es conocida, debe ser configurada en 0;
⎯ moduleVersion: campo de 8 bits que indica la versión de este módulo;
⎯ moduleInfoLength (extensión de la información del módulo): campo de 8 bits que indica la extensión byte
del área de información del módulo;
⎯ moduleInfoByte (información del módulo): campo de unidad de 8 bits que se puede usar para insertar
descriptores relacionados al módulo. Estos descriptores se definen en 5.4;
NOTA
Los valores de tag de los descriptores a ser insertados se definen en la Tabla 5.
⎯ privateDataLength: campo de 16 bits que indica la extensión byte del campo PrivateDataByte;
⎯ privateDataByte (datos privados): campo de unidad de 8 bits que se puede usar para contener una
estructura de datos en un formato de descriptor. La estructura de datos es definida con base en un formato de
codificación de datos o por un operador de servicio.
La semántica de los valores de tag de los descriptores para este campo es definida en la Tabla 3. Los descriptores
posibles para este campo son los definidos en 5.4 y por un formato de codificación de datos.
Tabla 3 — Semántica de los tags de los descriptores del área de información
de módulo y área privada en el DII
5.3
Valor de tag del descriptor
Semántica
0x01 – 0x7F
Valores de tag reservados de descriptores compatibles DVB a
ser insertados en el área de información del módulo y área
privada (ver 5.4)
0x80 - 0xBF
Valores de tag disponibles de descriptores definidos por un
operador de servicio
0xC0 – 0 xEF
Valores de tag reservados de descriptores a ser insertados en
el área de información del módulo y área privada (ver 5.4)
0xF0 – 0 xFE
Valores de tag reservados de descriptores definidos con base
en un formato de codificación de datos
Sintaxis y semántica del dsmccMessageHeader()
La estructura de datos del dsmccMessageHeader() se define en la Tabla 4.
10
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-3:2007
Tabla 4 — Estructura de datos del dsmccMessageHeader
Sintaxis
dsmccMessageHeader() {
protocolDiscriminator
dsmccType
messageID
transaction_id
Reserved
adaptationLength
messageLength
if(adaptationLength>0){
dsmccAdaptationHeader()
}
}
Número de bits
Mnemónico
8
8
16
32
8
8
16
uimsbf
uimsbf
uimsbf
uimsbf
bslbf
uimsbf
uimsbf
16
uimsbf
La semántica del dsmccMessageHeader() debe ser la siguiente:
⎯ protocolDiscriminator: campo de 8 bits que se debe configurar en 0 x 11 e indica que este mensaje es del
tipo MPEG-2 DSM-CC;
⎯ dsmccType (tipo DSM-CC): campo de 8 bits que indica el tipo del mensaje MPEG-2 DSM-CC. En un
mensaje DII para transmisión del carrusel de datos, se debe configurar en 0x03 (mensaje download U-N);
⎯ messageId (identificador del tipo del mensaje): campo de 16 bits que identifica el tipo del mensaje DSMCC. En un mensaje DII, se debe configurar en 0x1002;
⎯ transaction_id (identificador de transacción): campo de 32 bits que identifica el mensaje y tiene la función
de controlar la versión. El formato de la transaction_id se muestra en la Figura 1. El campo Transaction
Number en los bits 0-29 se debe usar para identificar la versión de la DII, como especificado en la ISO/IEC
13818-6. El valor de bits 30-31 se debe configurar en ‘10’ (TransactionId asignado por la red) conforme
definido en el Transaction id Originator, como especificado en la ISO/IEC 13818-6;
Figura 1 — Formato de la transaction_id
⎯ adaptationLength: campo de 8 bits que indica el número de bytes del campo dsmccAdaptationHeader();
⎯ messageLength: Campo de 16 bits que indica el número de bytes del mensaje inmediatamente después de
este campo. Es decir, el valor es una suma de la extensión payload y de la extensión
dsmccAdaptationHeader();
⎯ dsmccAdaptationHeader(): La estructura de datos de este campo está definida en 5.5.3.
© ABNT 2007 - Todos los derechos reservados
11
ABNT NBR 15606-3:2007
5.4
5.4.1
Descriptores del área de información del módulo y área privada
Tipos de descriptores
Los tipos de descriptores utilizados en un área de información del módulo y en un área privada son mostrados en
la Tabla 5. Cualquiera de estos descriptores se puede usar en el área de información del módulo y/o en un área
privada conforme sea necesario. Los descriptores contenidos en un área privada en una DII se aplican a los
módulos en la DII. Cuando el área de información del módulo y el área privada tienen el mismo conjunto de
descriptores, sólo los descriptores en el área de información del módulo son activados.
Tabla 5 — Tipos de descriptores
Valor de
tag
0x01
0x02
0x03
0x04
0x05
0x06
0x07
Descriptor
Tipo de módulo
(forma MIME etc.)
Nombre del módulo
name_descriptor
(nombre del archivo)
Información del módulo
info_descriptor
(tipo de carácter)
Información del link
module_link_descriptor
(id del módulo)
CRC32 del módulo
CRC32_descriptor
location_descriptor
Tiempo estimado de
est_download_time_descriptor
download (s)
type_descriptor
0x08 0x7F
0x80 0xBF
0xC0 0xC1
0xC2
o
o
o
o
o
o
o
o
o
o
Reservado para el futuro
Disponible para un broadcaster
Reservado para el futuro
compression_Type_descriptor
0xC3 0xCC
0xCD 0xEE
5.4.2
Área de
Área
información
privada
del módulo
Función
Algoritmo de compresión
cuando el módulo se
transmite
o
Reservado para el futuro
Reservado para el futuro
Descriptor de tipo
El descriptor de tipo (ver Tabla 6) indica el tipo de archivo transmitido como un módulo único, implementando la
transmisión del carrusel de datos con base en esta Norma, que especifica que un archivo único se transmite como
un módulo único.
12
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-3:2007
Tabla 6 — Descriptor de tipo
Sintaxis
Número de bits
Mnemónico
descriptor_tag
8
uimsbf
descriptor_length
8
uimsbf
8
uimsbf
Type_descriptor(){
for(i=0;i<N;i++) {
text_char
}
}
La semántica de campo en el descriptor de tipo debe ser la siguiente:
⎯ text_char: campo de 8 bits. La secuencia de estos campos indica tipo de media de acuerdo con la RFC 1521.
5.4.3
Descriptor del nombre
El descriptor del nombre (ver Tabla 7) indica el nombre del archivo transmitido como un módulo único,
implementando la transmisión del carrusel de datos con base en esta Norma, que especifica que un archivo único
se transmite como un módulo único. Sin embargo, cuando hay el descriptor Module Link, el descriptor del nombre
no debe estar presente en otra posición sino = módulo 0x00 en la DII.
Tabla 7 — Descriptor del nombre
Sintaxis
Name_descriptor() {
descriptor_tag
descriptor_length
for(i=0;i<N;i++) {
text_char
}
}
Número de bits
Mnemónico
8
8
uimsbf
uimsbf
8
uimsbf
La semántica de campo en el descriptor del nombre deber ser la siguiente:
⎯ text_char: campo de 8 bits. La secuencia de este campo indica el nombre del archivo transmitido como un
módulo único usando la especificación de codificación de datos o un código de carácter especificado en un
estándar operativo.
5.4.4
Descriptor de información
El descriptor de información (ver Tabla 8) describe las informaciones relacionadas al módulo.
Tabla 8 — Descriptor de información
Sintaxis
info_descriptor() {
descriptor_tag
descriptor_length
ISO_639_language_code
for(i=0;i<N;i++) {
text_char
}
}
© ABNT 2007 - Todos los derechos reservados
Número de bits
Mnemónico
8
8
24
uimsbf
uimsbf
bslbf
8
uimsbf
13
ABNT NBR 15606-3:2007
La semántica de campos en el descriptor de información debe ser la siguiente:
⎯ ISO_639_language_code: Campo de 24 bits que identifica el lenguaje que se utiliza en el área text_char. El
código del lenguaje es representado por tres caracteres alfabéticos especificados en la ISO 639-2. Cada
carácter se codifica dentro de una representación de 8 bits de acuerdo con la ISO 8859-1 y es insertado
dentro de un campo de 24 bits en ese orden;
⎯ text_char: campo de 8 bits. La secuencia de estos campos indica la información textual relacionada al archivo
transmitido como un módulo único usando la especificación de codificación de datos o un código de
señalización especificado en una norma operativa.
5.4.5
Descriptor del Module_link
El descriptor Module_link (ver Tabla 9) genera una lista de módulos conectados a otros módulos. Por ser la
extensión del campo número de bloques de un mensaje DDB restringido a 16 bits, el tamaño máximo de un
módulo en la transmisión del carrusel de datos es de 256 Mbytes. Cuando se transmite un archivo mayor que 256
Mbytes, el archivo se divide en dos o más módulos antes de ser enviado y esta información se asocia al descriptor
del Module_link.
Tabla 9 — Descriptor del Module_link
Sintaxis
module_link_descriptor() {
descriptor_tag
descriptor_length
position
moduleId
}
Número de bits
Mnemónico
8
8
8
16
uimsbf
uimsbf
uimsbf
uimsbf
La semántica de campos en el descriptor Module_link debe ser la siguiente:
⎯ position: campo de 8 bits que indica la relación de posición con módulo conectado. “0x00” indica que está
localizado en la parte superior del link, “0x01 indica que está en medio y “0x02” indica que está en el final;
⎯ module Id: campo de 16 bits que es la identificación del módulo conectado. Cuando la posición es “0x02”, el
valor de este campo es ignorado.
5.4.6
Descriptor de la localización
El location_descriptor contiene la localización del PID donde los bloques, módulos o grupos pueden ser
encontrados conteniendo los datos del carrusel. La Tabla 10 muestra la sintaxis del location_descriptor.
Tabla 10 — Sintaxis del location_descriptor
Sintaxis
location_descriptor(){
descriptor_tag
descriptor_length
location_tag
}
Número de bits
Valor
8
8
8
0x06
La semántica del location_descriptor debe ser la siguiente:
⎯ descriptor_tag: campo de 8 bits que identifica el descriptor. El location_descriptor está configurado en 0x06;
⎯ descriptor_length: campo de 8 bits que especifica el número de bytes del descriptor inmediatamente
después de este campo;
14
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-3:2007
⎯ location_tag: campo de 8 bits que tiene el mismo valor que el campo component_tag en el descriptor
identificador del stream.
5.4.7
Descriptor CRC
El descriptor CRC (ver Tabla 11) describe el valor CRC del módulo completo.
Tabla 11 — Descriptor CRC
Sintaxis
CRC32_descriptor() {
descriptor_tag
descriptor_length
CRC_32
}
Número de bits
Mnemónico
8
8
32
uimsbf
uimsbf
rpchof
La semántica de campo en el descriptor CRC debe ser la siguiente:
⎯ CRC_32: campo de 32 bits que almacena el valor CRC calculado para el módulo completo. El valor CRC
debe ser calculado como definido en la ABNT NBR 15603-2:2007, Anexo B.
5.4.8
Descriptor de tiempo estimado de download
El descriptor de tiempo estimado de download (ver Tabla 12) describe el período estimado necesario para el
download del módulo.
Tabla 12 — Descriptor de tiempo estimado de download
Sintaxis
est_download_time_descriptor() {
descriptor_tag
descriptor_length
est_download_time a
}
Número de bits
Mnemónico
8
8
32
uimsbf
uimsbf
uimsbf
La semántica del campo en el descriptor del tiempo estimado de download debe ser la siguiente:
⎯ est_download_time: campo de 32 bits que indica el período estimado, en segundos, necesario para hacer el
download del módulo.
5.4.9
Descriptor de tipo de compresión
El descriptor de tipo de compresión (ver Tabla 13) indica que el módulo fue comprimido en el formato zlib basado
en la RFC 1950 y muestra su algoritmo de compresión y el tamaño del módulo antes de la compresión en bytes.
Un módulo que no haya sido comprimido no tiene ese descriptor.
Tabla 13 — Descriptor de tipo de compresión
Sintaxis
Compression_Type_descriptor() {
descriptor_tag
descriptor_length
compression_type
original_size
}
© ABNT 2007 - Todos los derechos reservados
Número de bits
Mnemónico
8
8
8
32
uimsbf
uimsbf
uimsbf
uimsbf
15
ABNT NBR 15606-3:2007
La semántica de campos en el descriptor de tipo de compresión debe ser la siguiente:
⎯ compression_type: campo de 8 bits que define el tipo de compresión usada para comprimir el módulo;
⎯ original_size: campo de 32 bits que indica el tamaño del módulo antes de la compresión en bytes.
5.5 Mensaje DownloadDataBlock (DDB)
5.5.1
Sintaxis y semántica del mensaje DDB
El contenido de un mensaje DDB se transmite por almacenamiento en el campo downloadDataMessage() en la
sección DSM-CC.
Un mensaje DDB es la estructura de datos transmitiendo bloques de datos (ver Tabla 14). Un módulo se puede
dividir con extensión fijada para formar bloques. En ese caso, cada bloque es representado con un número de
bloque en el mensaje DDB para permitir que una unidad receptora reorganice los bloques en el orden pretendido.
De acuerdo con lo especificado en la ISO/IEC 13818-6, cuando los mensajes DDB se transmiten en MPEG-2 TS,
apenas los mensajes DDB que tienen el mismo downloadId deben ser incluidos en el mismo paquete PID. Eso
significa que los mensajes DDB en dos carruseles diferentes no se deben presentar en un único stream elemental.
Tabla 14 — Estructura de datos del bloque de datos de download
Sintaxis
DownloadDataBlock() {
dsmccDownloadDataHeader()
moduleId
moduleVersion
reserved
blockNumber
for(i=0;i<N;i++) {
blockDataByte
}
}
Número de bits
Mnemónico
16
8
8
16
uimsbf
uimsbf
bslbf
uimsbf
8
uimsbf
Los campos de DDB deben ser los siguientes:
⎯ moduleId: campo de 16 bits que indica el número de identificación al cual este bloque pertenece;
⎯ moduleVersion: campo de 8 bits que indica la versión del módulo al cual este bloque pertenece;
⎯ blockNumber: campo de 16 bits que indica la posición de este bloque dentro del módulo. El primer bloque de
un módulo debe ser representado por el bloque número 0;
⎯ blockDataByte: campo de 8 bits. El tamaño de una serie del área de datos del bloque es igual al tamaño del
bloque de la DII, es decir, el tamaño de los bloques divididos desde un módulo. Sin embargo, el número del
último bloque en el módulo puede ser menor que el tamaño de bloque descrito en la DII.
5.5.2
Sintaxis y semántica del dsmccDownloadDataHeader()
La estructura de datos del dsmccDownloadDataHeader() está definida en la Tabla 15.
16
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-3:2007
Tabla 15 — Estructura de datos del dsmccDownloadDataHeader
Sintaxis
dsmccDownloadDataHeader() {
protocolDiscriminator
dsmccType
messageId
downloadId
Reserved
adaptationLength
messageLength
if(adaptationLength>0) {
dsmccAdaptationHeader()
}
}
Número de bits
Mnemónico
8
8
16
32
8
8
16
uimsbf
uimsbf
uimsbf
uimsbf
bslbf
uimsbf
uimsbf
8
uimsbf
Los campos del dsmccDownloadDataHeader() deben ser los siguientes:
⎯ protocol discriminator: campo de 8 bits que es configurado en 0x11 e indica que este mensaje es un
mensaje DSM-CC MPEG-2 dsmccType. Este campo de 8 bits indica el tipo del mensaje DSM-CC MPEG-2 y
es configurado en 0x03 (mensaje download U-N) para el mensaje DDB en la transmisión del carrusel de
datos;
⎯ messageId: campo de 16 bits que identifica el tipo del mensaje DSM-CC y es configurado en 0x1003 para un
mensaje DDB;
⎯ downloadId: campo de 32 bits que es configurado en el mismo valor que el identificador de download en el
mensaje DII correspondiente;
⎯ adaptationLength: campo de 8 bits que indica el número de bytes del campo dsmccAdaptationHeader();
⎯ dsmccAdaptationHeader(): la estructura de datos de este campo es definida en 5.5.3;
⎯ messageLength: campo de 16 bits que indica la extensión del mensaje, no incluyendo este campo y su área
precedente en bytes. El valor es idéntico a la suma de la extensión de payload y la extensión
dsmccAdaptationHeader.
5.5.3
Sintaxis del dsmccAdaptationHeader()
En el dsmccMessageHeader() que es el encabezamiento de un mensaje DII y en el dsmccDownloadDataHeader()
que es el encabezamiento de un mensaje DDB, puede ser establecida la estructura de datos común
dsmccAdaptationHeader().
La estructura de datos del dsmccAdaptationHeader es indicada en la Tabla 16.
Tabla 16 — Estructura del dsmccAdaptationHeader
Sintaxis
dsmccAdaptationHeader() {
adaptationType
for (i=0; i<(adaptationLength-1);i++) {
adaptationDataByte
}
}
}
© ABNT 2007 - Todos los derechos reservados
Número de bits
Mnemónico
8
uimsbf
8
uimsbf
17
ABNT NBR 15606-3:2007
La semántica del dsmccAdaptationHeader() debe ser la siguiente:
⎯ adaptation Type: campo de 8 bits que indica el tipo de encabezamiento de adaptación. El valor de este
campo indica un formato de adaptación conforme Tabla 17.
Tabla 17 — Tipo de adaptación
Tipo de adaptación
Formato de la adaptación
Definición en la ISO/IEC 13818-6
0x00
Reservado
Lo mismo que en la columna a la izquierda
0x01
Reservado
DSM-CC Acceso condicional
0x02
Reservado
DSM-CC identificador de usuario
0x03
DIIMsgNumber
Lo mismo que en la columna a la izquierda
0x04-0x7F
Reservado
Lo mismo que en la columna a la izquierda
0x80-0xFF
Definición del usuario
Lo mismo que en la columna a la izquierda
NOTA Para los tipos de adaptación utilizados en esta Norma, la operación del formato de adaptación de
definición del usuario del tipo de adaptación 0x80 – 0xFF es opcionalmente hecha por un operador de servicio.
5.5.4
Sintaxis de la sección DSM-CC
Los mensajes DII y DDB se transmiten usando las secciones DSM-CC, como se muestra en la Tabla 18.
18
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-3:2007
Tabla 18 — Sección DSM-CC (transmisión de mensajes DII/DBB)
Sintaxis
DSMCC_section () {
table_id
section_syntax_indicator
private_indicator
reserved
dsmcc_section_length
table_id_extension
reserved
version_number
current_next_indicator
section_number
last_section_number
if (table_id==0x3B) {
userNetworkMessage ()
}
else if (table_id==0x3C) {
downloadDataMessage()
}
else if (table_id==0x3E) {
for (i=0;i<dsmcc_section_length-9;i++) {
private_data_byte
}
}
if (section_syntax_indicator==’0’) {
Checksum
}
else {
CRC_32
}
}
Número de bits
Mnemónico
8
1
1
2
12
16
2
5
1
8
8
uimsbf
bslbf
bslbf
bslbf
uimsbf
uimsbf
bslbf
uimsbf
bslbf
uimsbf
uimsbf
8
uimsbf
32
uimsbf
32
rpchof
La semántica de la sección DSM-CC debe ser la siguiente:
⎯ table_id: campo de 8 bits que contiene el número de identificación del tipo de datos en la sección de payload
DSM-CC. Basado en el valor de este campo, se aplica una regla de codificación específica para el campo
siguiente en la sección DSM-CC. La tabla de los valores de identificación es mostrada en la Tabla 19, como
especificado en la ISO/IEC 13818-6;
Tabla 19 — Table_id
table_id
0x3A
0x3B
a
Tipo de sección DSM-CC
Reservado
Mensaje DII
0x3C
Mensaje DDB
0x3D
Descriptor de Stream
0x3E
Datos privados
0x3F
Reservado
Definición en la ISO/IEC 13818-6
Cápsula multiprotocolo a
Mensaje U-N incluyendo DII
Lo mismo que en la columna a la
izquierda
Lo mismo que en la columna a la
izquierda
Lo mismo que en la columna a la
izquierda
Lo mismo que en la columna a la
izquierda
Ver ISO/IEC 13818-6.
© ABNT 2007 - Todos los derechos reservados
19
ABNT NBR 15606-3:2007
⎯ section_syntax_indicator: campo de 1 bit. Cuando es configurado en 1, indica que existe un CRC32 al final
de la sección. Cuando es configurado en ***0, indica que existe una suma de verificación. Se debe configurar
en 1 para la transmisión de los mensajes DII y DDB;
⎯ private_indicator: campo de 1 bit que almacena el valor complementar del flag del section_syntax_indicator;
⎯ dsmcc_section_length: campo de 12 bits que indica el número de bytes del área desde el inicio del campo,
inmediatamente después de ese campo hasta el fin de la sección. El valor en este campo no debe exceder 4
093 bytes;
⎯ table_id_extension: campo de 16 bits que es configurado como mostrado abajo, de acuerdo con el campo
table_id:
•
cuando el valor del campo table_id es igual a 0x3B, este campo debe transportar una copia de los 2
bytes menos significativos del campo transaction_id;
•
cuando el valor del campo table_id es igual a 0x3C, este campo debe transportar una copia del
campo module_id;
⎯ version_number: campo de 5 bits que es configurado tal como se muestra abajo, de acuerdo con el
identificador de tabla;
⎯ value: cuando el valor del campo table_id es igual a 0x3B, este campo se debe configurar en 02. Cuando el
valor del campo table_id es igual a 0x3C, se debe configurar en los 5 bits menos significativos del campo
versión del módulo;
⎯ current_next_indicator: designación de 1 bit que indica que la subtabla está activa cuando está en “1”.
Cuando está en “0”, a subtabla enviada aún no fue aplicada y usada como la próxima subtabla. Cuando el
valor del campo table_id es igual a un valor en la banda de 0x3A a 0x3C, este campo se debe configurar en
“1”;
⎯ section_number: campo de 8 bits que indica el número de la sección de la primera sección en la subtabla.
Cuando la sección contiene un mensaje DII, este campo se debe configurar en 0. Cuando esta sección
contiene un mensaje DDB, este campo debe transportar una copia de los 8 bits menos significantes del
número del bloque de la DDB;
⎯ last_section_number: campo de 8 bits que indica el número de la última sección (sección que tiene el
número máximo de la sección) de la subtabla a la cual pertenece la sección;
⎯ userNetworkMessage(): mensaje DII es almacenada;
⎯ downloadDataMessage(): mensaje DDB es almacenada.
6
6.1
Especificación del carrusel de objetos
Objetivo del carrusel de objetos
La especificación del carrusel de objetos fue añadida para brindar soporte a los servicios de transmisión de datos
que requieren transmisión periódica de objetos DSM-CC U-U a través de las redes de transmisión compatibles con
el sistema brasileño de televisión digital terrestre (SBDTV).
La transmisión de datos de acuerdo con la especificación del sistema brasileño de televisión digital terrestre para
carrusel de objetos se transmite de acuerdo con la DSM-CC de carrusel de objetos y especificación de carrusel de
datos DSM-CC que se definen en MPEG-2 DSM-CC (ver a ISO/IEC 13818-6:1998, Sección 5).
20
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-3:2007
6.2
6.2.1
Especificación del transporte de datos
Dirección de carrusel NSAP
La especificación SBTVD para carrusel de objetos se basa en la especificación DSM-CC de carrusel de objetos
(ver a ISO/IEC 13818-6). Un carrusel de objetos SBTVD representa un dominio de servicio particular que consiste
en una colección de objetos DSM-CC U-U dentro de una red SBTVD. El dominio de servicio tiene un puerto de
servicio que presenta un gráfico de servicios y nombres de objetos para los receptores.
La única identificación del puerto de servicio en las redes de transmisión se realiza por medio de la dirección
Network Service Access Point (NSAP) del carrusel, conforme definido en DSM-CC (ver a ISO/IEC 13818-6). Esta
dirección contiene una parte específica de la red que debe tornar la dirección única dentro del ambiente de red
usado. La dirección NSAP del carrusel se utiliza para referirse al carrusel de objetos desde otro dominio de
servicio. Para los ambientes del SBTVD, la sintaxis y la semántica de la dirección NSAP del carrusel se definen
abajo.
6.2.2
Estructura de la dirección NSAP del carrusel
La dirección NSAP del carrusel tiene una estructura según definida en la Figura 2 (ver a ISO/IEC 13818-6).
AFI
Type
carouselId
specifier
privateData
1 byte
1 byte
4 bytes
4 bytes
10 bytes
Figura 2 — Formato de la dirección NSAP del carrusel
La semántica del AFI (identificador de autorización y formato), tipo, carouselId y especificador se definen en la
ISO/IEC 13818-6. En particular:
⎯ AFI: campo de 8 bits que se debe configurar en el valor de 0x00 para indicar el uso privado del formato NSAP
(ver a EN 301 192);
⎯ Type (Tipo): campo de 8 bits que se debe configurar en 0x00 para indicar el uso de la dirección NSAP para
carruseles de objetos;
⎯ carouselId: campo de 32 bits que se debe configurar en el identificador del carrusel de objetos, es decir, el
campo carouselId;
⎯ specifier (especificador): campo de 32 bits que debe transportar el campo specifierType (configurado en el
valor de 0x01) y el código OUI (Identificador Único Organizacional) como definido en la DSM-CC (ver la
ISO/IEC 13818-6:1998, sección 5). El código OUI se debe configurar en un valor que haya sido asignado para
DVB por la autoridad de registro IEEE 802;
⎯ privateData: campo que debe transportar la estructura ginga_service_location que es definida en la Tabla 20.
Tabla 20 — Sintaxis para la estructura ginga_service_location
Sintaxis
ginga_service_location() {
transport_stream_id
org_network_id
service_id
reserved
}
© ABNT 2007 - Todos los derechos reservados
Número de bits
Mnemónico
16
16
16
32
uimsbf
uimsbf
uimsbf
bslbf
21
ABNT NBR 15606-3:2007
La semántica de la estructura dvb_service_location debe ser la siguiente:
⎯ transport_stream_id: campo de 16 bits que identifica el stream de transporte en el cual el carrusel se
transmite;
⎯ org_network_id: campo de 16 bits que identifica el network_id del sistema de entrega del que se origina el
carrusel;
⎯ service_id: campo de 16 bits que suministra el identificador del servicio que contiene el carrusel de objetos.
El service_id es lo mismo que el program_number en la program_map_section asociada.
6.3 Descriptores
NOTA
6.3.1
Todos los descriptores del carrusel de datos son los mismos que se utilizan en la Sección 5.
Especificación PSI y SI
El servicio de transmisión de datos indica el uso de un carrusel de objeto SBTVD por la inclusión de uno o más
descriptores de componentes de los datos – descriptor de ID del carrusel – descriptor de tag de asociación, de
acuerdo con la ARIB STD-B23.
Cada descriptor debe indicar un carrusel de objetos y ser asociado a un stream particular vía un identificador
component_tag. En particular, el valor del campo component_tag es idéntico al valor del campo component_tag de
un stream_identifier_descriptor (ver a EN 300 468) que puede estar presente en la sección de mapa del programa
PSI para el stream que se utiliza como stream de datos.
Cada descriptor de transmisión de datos permite el uso de protocolos de capas más altas basados en el criterio de
lenguaje usando una lista de objetos.
Un carrusel de objeto se puede implementar usando servicios de transmisión de datos múltiples. Los servicios de
transmisión de datos pueden publicar que ellos son parte de un carrusel de objeto particular por la inclusión del
carousel_identifier_descriptor como definido por la DSM-CC (ver la ISO/IEC 13818-6) en el primer enlace de
descriptor de la tabla de mapa de programa.
Además de ello, los carruseles-objetos usan el concepto de taps (ver la ISO/IEC 13818-6) para identificar los
streams en los cuales los objetos se transmiten. La asociación entre los taps y los streams del servicio de datos se
puede realizar por uno u otro, usando el descriptor association_tag definido en (ver la ISO/IEC 13818-6) o el
stream_identifier_descriptor en EN 300 468.
En último caso, se presume que el campo component_tag del descriptor stream_identifier sea el byte de menor
significación del valor association_tag indicado que tiene el byte más significativo configurado en 0x00.
Finalmente, los objetos de stream dentro de los carruseles de objetos U-U pueden ser conectados a los streams
elementales del servicio de transmisión de datos por ellos mismos a los streams elementales de otros servicios o
para completar servicios SBTVD. Si el objeto de stream es conectado a los stream elementales de otros servicios
o para completar los servicios SBTVD, la tabla de mapa de programa del servicio de transmisión de datos debe
incluir el deferred_association_tags_descriptor en el primer enlace del descriptor.
6.3.2
Deferred_association_tags_descriptor
La sintaxis y la semántica del deferred_association_tags_descriptor() en las redes compatibles con el SBTVD se
describen en la Tabla 21.
22
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-3:2007
Tabla 21 — Deferred_association_tags_descriptor
Sintaxis
deferred_association_tags_descriptor() {
descriptor_tag
descriptor_length
association_tags_loop_length
for (i=0;i<N1;i++) {
association_tag
}
transport_stream_id
program_number
for (i=0;i<N2;i++){
private_data_byte
}
}
Número de bits
Mnemónico
8
8
8
uimsbf
uimsbf
uimsbf
16
uimsbf
16
16
uimsbf
uimsbf
8
uimsbf
La semántica del deferred_association_tags_descriptor debe ser la siguiente:
⎯ descriptor_tag: campo de 8 bits que debe tener el valor de 0x15;
⎯ descriptor_length: campo de 8 bits que especifica la extensión del descriptor en bytes;
⎯ association_tags_loop_length: campo de 8 bits que define la extensión en bytes del enlace de las tags de
asociación que siguen este campo;
⎯ association_tag: campo de 16 bits que contiene la association_tag que está asociada a un stream que no
forma parte del servicio de transmisión de datos o con otro servicio SBTVD;
⎯ transport_stream_id: campo de 16 bits que indica la stream de transporte en el cual reside el servicio que
está asociado a las tags de asociación listadas;
⎯ program_number: campo de 16 bits que se debe configurar en el service_id del servicio que está asociado a
las tags de asociación listadas;
⎯ private_data_byte: campo que debe contener la estructura deferred_service_location definida en la Tabla 22.
Tabla 22 — Sintaxis para la estructura deferred_service_location
Sintaxis
deferred_service_location() {
org_network_id
for (i=0;i<N;i++) {
private_data_byte
}
}
Número de bits
Mnemónico
16
uimsbf
8
uimsbf
La semántica de la estructura deferred_service_location debe ser la siguiente:
⎯ org_network_id: campo de 16 bits que identifica el network_id del sistema de entrega a partir del cual se
origina el servicio;
⎯ private_data_byte: campo de 8 bits que no se especifica en esta Norma.
6.3.3
Tipo de flujo
La presencia de un carrusel de objetos en un servicio debe ser indicada en la tabla de mapa de programa de ese
servicio colocando el tipo de stream que contiene el carrusel de datos en el valor de 0x0B (ver ISO/IEC 13818-1) o
un valor definido por el usuario.
© ABNT 2007 - Todos los derechos reservados
23
ABNT NBR 15606-3:2007
7
7.1
Encapsulado multiprotocolo (MPE)
Especificación de transporte de datos
Los datagramas son encapsulados en las datagram_sections que son compatibles con el formato DSMCC_section
para datos privados (ver la ISO/IEC 13818-6). El mapeo de la sección dentro de los paquetes MPEG-2 de stream
de transporte se define en sistemas MPEG-2 (ver la ISO/IEC 13818-1).
La sintaxis y la semántica del datagram_section se definen en la Tabla 23.
Tabla 23 — Sintaxis del datagram_section
Sintaxis
datagram_section () {
table_id
section_syntax_indicator
private_indicator
reserved
section_length
MAC_address_6
MAC_address_5
reserved
payload_scrambling_control
address_scrambling_control
LLC_SNAP_flag
current_next_indicator
section_number
last_section_number
MAC_address_4
MAC_address_3
MAC_address_2
MAC_address_1
if (LLC_SNAP_flag == ‘1’) {
LLC_SNAP()
}
Else{
for (j=0;j<N1;j++) {
IP_datagram_data_byte
}
}
if (section_number == last_section_number) {
for(j=0;j<N2;j++){
stuffing_byte
}
}
If(section_syntax_indicator == ‘0’){
checksum
}
else{
CRC32
}
}
24
Número de de bits
Mnemónico
8
1
1
2
12
8
8
2
2
2
1
1
8
8
8
8
8
8
uimsbf
bslbf
bslbf
bslbf
uimsbf
uimsbf
uimsbf
bslbf
bslbf
bslbf
bslbf
bslbf
uimsbf
uimsbf
uimsbf
uimsbf
uimsbf
uimsbf
8
bslbf
8
bslbf
32
uimsbf
32
rpchof
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-3:2007
La semántica del datagram_section debe ser la siguiente:
⎯ table_id: campo de 8 bits que se debe configurar en 0x3E, secciones DSM-CC con datos privados (ver la
ISO/IEC 13818-6:1998, Sección 5);
⎯ section_syntax_indicator: campo que se debe configurar conforme definido en la ISO/IEC 13818-6:1998,
sección 5;
⎯ private_indicator: campo que se debe configurar conforme definido en la ISO/IEC 13818-6:1998, Sección 5;
⎯ reserved: campo de 2 bits que se debe configurar en “11”;
⎯ section_length: campo que se debe configurar conforme definido en la ISO/IEC 13818-6:1998, sección 5;
⎯ MAC_address_[1.. 6]: campo de 48 bits que contiene la dirección MAC del destino. La dirección MAC es
fragmentada en 6 campos de 8 bits, rotulados como MAC_address_1 a MAC_address_6. El campo
MAC_address_1 contiene el byte más significativo de la dirección MAC, mientras el MAC_address_6 contiene
el byte menos significativo. La Figura 3 ilustra el mapeo de los bytes de la dirección MAC en los campos de la
sección.
NOTA
El orden de los bits en los bytes no está reservado y el MSB (Bit Más Significativo) de cada byte también se
transmite primero.
Los campos MAC_address contienen una dirección MAC clara o codificada, como indicado por el campo
address_scrambling_control;
Figura 3 — Mapeo de los bytes de la dirección MAC para los campos de la sección
⎯ payload_scrambling_control: campo de 2 bits que define el modo de codificación del payload de la sección.
Eso incluye el comienzo del payload después del MAC_address_1, pero excluye a checksum o campo CRC32
(ver Tabla 24). El método de codificación aplicado es exclusivo del usuario;
Tabla 24 — Codificación del campo payload_scrambling_control
Valor
00
01
10
11
Control de codificación del payload
No codificado
Definido por el servicio
Definido por el servicio
Definido por el servicio
⎯ address_scrambling_control: campo de 2 bits que define el modo de dispersión de la dirección MAC en esta
subsección (ver Tabla 25). Este campo permite un cambio dinámico de las direcciones MAC. El método de
codificación aplicado es exclusivo del usuario;
© ABNT 2007 - Todos los derechos reservados
25
ABNT NBR 15606-3:2007
Tabla 25 — Codificación del campo address_scrambling_control
Valor
00
01
10
11
Control de dirección de codificación
No codificado
Definido por el servicio
Definido por el servicio
Definido por el servicio
⎯ LLC_SNAP_flag: flag de 1 bit. Si el flag está configurado en “1”, la payload carga un datagrama siguiendo
campo MAC_address_1. La estructura LLC/SNAP debe indicar el tipo de datagrama transportadas. Si el flag
está configurado en “0”, la sección debe contener un datagrama IP sin encapsulado LLC/SNAPP;
⎯ current_next_indicator: campo de 1 bit que se debe configurar en el valor de “1”;
⎯ section_number: campo de 8 bits. Si el datagrama es transportado en secciones múltiples, entonces este
campo indica la posición de la sección dentro del proceso de fragmentación. En caso contrario será
configurado en cero;
⎯ last_section_number: campo de 8 bits que debe indicar el número de la última sección usada para cargar el
datagrama, es decir, el número de la última sección del proceso de fragmentación;
⎯ LLC_SNAP: estructura que debe contener el datagrama de acuerdo con las especificaciones de la ISO/IEC
8802-2 LLC (Control de Conexión Lógica) y de la ISO/IEC TR 8802-1 SNAP (Punto de Anexión de la Subrede).
Si la payload de la sección está codificada (ver payload_scrambling_mode), estos bytes deben estar
diseminados;
⎯ IP_datagram_data_byte: Bytes contienen los datos del datagrama. Si la payload de la sección está codificada
(ver payload_scrambling_mode), estos bytes deben estar codificados;
⎯ stuffing_byte: campo opcional de 8 bits cuyo valor no se especifica. Si la payload de la sección está
codificada (ver payload_scrambling_mode), estos bytes se codifican. Deben auxiliar la codificación del bloque
y procesamiento de datos en los ambientes de wide bus. El número de stuffing_bytes que se utilizan debe
adecuarse a las exigencias de alineamiento de los datos definidos en el data_broadcast_descriptor;
⎯ checksum: campo que se debe configurar conforme definido en la ISO/IEC 13818-6:1998, Sección 5. Es
calculado sobre el datagram_section completo;
⎯ CRC_32: campo que se debe configurar conforme definido en la ISO/IEC 13818-6:1998, Sección 5. Es
calculado sobre el datagram_section completo.
7.2
Especificaciones PSI y SI
El servicio de transmisión de datos debe indicar la transmisión de datagramas por la inclusión de uno o más
descriptores de transmisión de datos en SI (ver la ARIB STD-B23). Cada descriptor debe ser asociado a un
stream vía un identificador component_tag. En particular, el valor del campo component_tag debe ser idéntico al
valor del campo component_tag de un stream_identifier_descriptor (ver la EN 300 468:2005, Sección 2) que puede
estar presente en la tabla de mapa de programa PSI (PMT) para el stream usado para transmitir los datagramas.
7.3
Descriptor de protocolo de transporte
El descriptor de protocolo de transporte se utiliza de la siguiente manera:
⎯ protocol_id: campo que se debe configurar en 0x0002 para indicar el uso de la especificación de
encapsulado multiprotocolo;
26
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-3:2007
⎯ component_tag: campo que debe tener el mismo valor de un campo component_tag de un
stream_identifier_descriptor, que pueda estar presente en la sección de mapa de programa PSI para el
stream en el que se transmiten los datos;
⎯ selector_byte: bytes selectores que deben transportar la estructura multiprotocol_encapsulation_info que es
definida en la Tabla 26.
Tabla 26 — Sintaxis para la estructura multiprotocol_encapsulation_info
Sintaxis
multiprotocol_encapsulation_info() {
MAC_address_range
MAC_IP_mapping_flag
alignment_indicator
reserved
max_sections_per_datagram
}
Número de bits
Mnemónico
3
1
1
3
8
uimsbf
bslbf
bslbf
bslbf
uimsbf
La semántica de la estructura multiprotocol_encapsulation_info debe ser la siguiente:
⎯ MAC_address_range: campo de 3 bits que debe indicar el número de bytes de la dirección MAC que el
servicio usa para diferenciar los receptores de acuerdo con la Tabla 27;
Tabla 27 — Codificación del campo MAC_address_range
MAC_address_range
0x00
0x01
0x02
0x03
0x04
0x05
0x06
0x07
Bytes de MAC_address válidos
Reservado
6
6,5
6,5,4
6,5,4,3
6,5,4,3,2
6,5,4,3,2,1
Reservado
⎯ MAC_IP_mapping_flag: flag de 1 bit. El servicio debe configurar ese flag en “1”, si usa el IP para mapeo MAC
(ver la RFC 1112). Si ese flag está configurado en “0”, el mapeo de las direcciones IP para direcciones MAC
se realiza fuera del objetivo de esta Norma;
⎯ alignment_indicator: campo de 1 bit que debe indicar la alineamiento que existe entre los bytes del
datagram_section y los bytes del stream de transporte, de acuerdo con la Tabla 28;
Tabla 28 — Codificación del campo alignment_indicator
Valor
0
1
Alineamiento en bits
8 (estándar)
32
⎯ reserved: Campo de 3 bits que se debe configurar en "111";
⎯ max_sections_per_datagram: Campo de 8 bits que debe indicar el número máximo de secciones que se
puede usar para cargar una única unidad de datagrama.
© ABNT 2007 - Todos los derechos reservados
27
ABNT NBR 15606-3:2007
7.4
Tipo de stream
La presencia de un stream de datos de multiprotocolo en un servicio debe ser indicada en la sección de mapa de
programa de ese servicio por la configuración del tipo de stream para el valor de 0x0A (ver la ISO/IEC 13818-6:1998,
Sección 5) o un valor definido por el usuario.
8
8.1
Especificación de la transmisión del data piping
Especificación del transporte de datos
El servicio de transmisión de datos debe insertar los datos a ser transmitidos directamente en la payload de los
paquetes MPEG-2 TS.
El servicio de transmisión de datos puede usar el campo payload_unit_start_indicator y el campo
transport_priority de los paquetes de la stream de Transporte MPEG-2 en forma de servicio privado. El uso del
adaptation_field debe ser compatible con MPEG-2.
La entrega de los bits en tiempo a través de un data pipe es un servicio privado y no se especifica en esta Norma.
8.2
Especificaciones PSI y SI
El servicio de transmisión de datos debe indicar el uso de un data pipe (canal de datos), incluyendo uno o más
descriptores de transmisión de datos en SI (ver la EN 300 468). Cada descriptor debe ser asociado a un canal de
datos particular vía un identificador component_tag.
En particular, el valor del campo component_tag debe ser idéntico al valor del campo component_tag de un
stream_identifier_descriptor (ver la EN 300 468) que se puede presentar en la sección de mapa de programa PSI
para el stream que se utiliza como un data pipe.
8.3
Descriptor de protocolo de transporte
El descriptor de transmisión de datos se debe usar de la siguiente forma:
— protocol_id: campo que se debe configurar en 0x0003 para indicar un canal de datos DVB. Los otros campos
están presentes.
8.4
Tipo de stream
La especificación del stream_type en la sección de mapa de programa debe ser 0x7E (ver la ABNT NBR 156032:2007, Tabla J.1),
9
9.1
Especificación de transmisión PES independiente
Transmisión independiente de PES
La especificación de transmisión PES independiente es un método utilizado para implementar el streaming para
servicios de transmisión de datos. Hay dos tipos de especificación de transmisión PES: Sincronizada y asíncrona.
El sistema de transmisión PES sincronizada se utiliza cuando es necesario sincronizar datos en un stream con
otros streams, incluyendo video y audio. La especificación de transmisión PES asíncrona se utiliza cuando la
sincronización no es necesaria. Como un ejemplo de aplicación importante, se espera que el tipo sincronizado sea
utilizado para transmitir closed caption, y el tipo asíncrono para transmisión de caracteres superpuestos
(superimposed). Para informaciones relacionadas a la PES independiente, ver Anexo A.
28
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-3:2007
9.2
PES sincronizada
De acuerdo con la especificación de transmisión PES sincronizada, los datos se transmiten utilizando un paquete
PES especificado en la ISO/IEC 13818-1. Cualquier mapeo de paquete PES para un stream de transporte MPEG2 debe cumplir la ISO/IEC 13818-1.
De acuerdo con la especificación de transmisión del tipo sincronizada, un paquete PES con las siguientes
restricciones se utiliza además de la sintaxis y semántica especificadas en la ISO/IEC 13818-1.
Para el encabezamiento del paquete PES correspondiente al private_stream_1, se deberá utilizar lo siguiente:
⎯ stream_id: en el caso de un stream del tipo sincronizado, éste se debe configurar en ‘0xBD‘(private_stream_1);
⎯ PES_packet_length: campo de 16 bits que debe tener un valor que no sea cero.
La estructura de datos de la PES sincronizada mostrada en la Tabla 29 se debe insertar en el campo
PES_packet_data_bytes.
Tabla 29 — Estructura de datos de la PES sincronizada
Sintaxis
syncronized_PES_data() {
data_identifier
private_stream_id
reserved_future_use
PES_data_packet_header_length
for (i=0; i<N1; i++) {
PES_data_private_data_byte
}
for(i=0;i<N2;i++){
syncronized_PES_data_byte
}
}
Número de bits
Mnemónico
8
8
4
4
uimsbf
uimsbf
bslbf
uimsbf
8
bslbf
8
bslbf
La semántica de campos en un paquete PES sincronizada es:
⎯ data_identifier: campo de 8 bits que se debe configurar en ‘0x80’;
⎯ private_stream_id: no utilizado (0xFF);
⎯ PES_data_packet_header_length:
PES_data_private_date_bytes;
campo
de
4
bits
indica
la
extensión
en
bytes
del
⎯ PES_data_private_data_byte: campo de 8 bits que es una utilización más detallada de este campo y
depende de un servicio. Una unidad receptora puede omitir este campo;
⎯ synchronized_PES_data_byte: campo de 8 bits conteniendo los datos transmitidos.
9.3
PES asíncrona
De acuerdo con la especificación de PS asíncrona, los datos se transmiten utilizando un paquete PS especificada
en la ISO/IEC 13818-1. Cualquier mapeo de paquete PS para un stream de transporte MPEG-2 debe cumplir la
ISO/IEC 13818-1.
De acuerdo con la especificación de transmisión asíncrona, un paquete PES con las siguientes restricciones se
utiliza además de la sintaxis y semántica especificadas en la ISO/IEC 13818-1.
© ABNT 2007 - Todos los derechos reservados
29
ABNT NBR 15606-3:2007
Para el encabezamiento del paquete PES correspondiente al private_stream_2, se deberá utilizar:
⎯ stream_id: en caso de un stream tipo asíncrono, se debe configurar a ‘0xBF’ (private_stream_2);
⎯ PES_packet_length: campo de 16 bits que debe tener un valor que no sea cero.
La estructura de datos de la PES asíncrona mostrada en la Tabla 30 se inserta en el campo del PES_
packet_data_bytes.
Tabla 30 — Estructura de datos de PES asíncrona
Sintaxis
Asynchronous_PES_data() {
data_identifier
private_stream_id
reserved_future_use
PES_data_packet_header_length
for (i=0; i<N1; i++) {
PES_data_private_data_byte
}
for(i=0;i<N2;i++){
Asynchronous_PES_data_byte
}
}
Número de bits
Mnemónico
8
8
4
4
uimsbf
uimsbf
bslbf
uimsbf
8
bslbf
8
bslbf
La semántica de campos en un paquete PES asíncrona es:
⎯ data_identifier: campo de 8 bits que se debe configurar en ‘0x81;
⎯ private_stream_id: no utilizado (0xFF);
⎯ PES_data_packet_header_length:
PES_data_private_date_bytes;
campo
de
4
bits
que
indica
la
extensión
en
bytes
del
⎯ PES_data_private_data_byte: campo de 8 bits que es una utilización más detallada de este área y depende
de un servicio. Una unidad receptora puede omitir este campo;
⎯ asynchronous_PES_data_byte: campo de 8 bits conteniendo los datos transmitidos.
10 Protocolos de transporte
10.1 Protocolo del canal de transmisión
10.1.1 Stream de transporte MPEG-2
El stream de transporte MPEG-2 debe estar de acuerdo con la GEM 1.0:2005, Subsección 6.2.1.
10.1.2 Sección MPEG-2
La sección MPEG-2 debe estar de acuerdo con la GEM 1.0:2005, Subsección 6.2.2.
10.1.3 Datos privados DSM-CC
Los datos privados DSM-CC deben estar de acuerdo con la GEM 1.0:2005, Subsección 6.2.3.
30
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-3:2007
10.1.4 Carrusel de datos DSM-CC
El carrusel de datos DSM-CC debe estar de acuerdo con la GEM 1.0:2005, Subsección 6.2.4.
10.1.5 Carrusel de objetos DSM-CC
Para el protocolo de transporte de transmisión que transmite contenidos de aplicación GINGA, se especifican dos
sistemas: El sistema de transmisión de carrusel de objetos y el de carrusel de datos.
Cada sistema está de acuerdo con la GEM 1.0:2005, Subsección 6.2.5, y está disponible a través del paquete
org.dvb.dsmcc (ver Tabla 31).
Tabla 31 – Equivalentes funcionales
Nombre
GEM
Ver la ARIB-STD-B23:2004,
Anexo B
Carrusel
Ver la GEM 1.0:2005,
subsecciones 6.2.5 y
11.7.2
Observaciones
Implementación en la
ARIB STD-B23
En caso de utilización de carrusel
de datos, se aplica la ARIB STDB23:2004, Anexo B
Ver ARIB STD-B24
transport_stream_id, original_network_id, service_id de
dvb_service_location() en la ARIB STD-B23:2004, Tabla B.26: DVB
dirección carrusel NSAP debe seguir la semántica de la ARI B-SI.
Cualquier sistema estándar de carrusel es seleccionable.
ETSI TS 101 812:2003, Anexo B, e
ISO/IEC 13818-6 (DSM-CC carrusel
de objetos)
En caso de utilización de un
carrusel de objetos, se aplica la
ETSI TS 101 812:2003, Anexo B,
10.1.6 Protocolo IP de transporte de multicast en un canal de transmisión
El protocolo IP de transporte de multicast en un canal de transmisión debe estar de acuerdo con la GEM 1.0:2005,
Subsección 6.2.6.
10.1.7 Protocolo IP
El protocolo IP debe estar de acuerdo con la GEM 1.0:2005, Subsección 6.2.7.
10.1.8 Protocolo UDP
El protocolo UDP debe estar de acuerdo con la GEM 1.0:2005, Subsección 6.2.8.
10.1.9 Informaciones de servicio
Las informaciones de servicio deben estar de acuerdo con la ABNT NBR 15603-1, ABNT NBR 15603-2 y
ABNT NBR 15603-3.
© ABNT 2007 - Todos los derechos reservados
31
ABNT NBR 15606-3:2007
10.1.10
Señalización de IP
La señalización de IP debe estar de acuerdo con la GEM 1.0:2005, Subsección 6.2.10.
10.2 Protocolos de canal de interacción
10.2.1 Pila de protocolo del canal interactivo
Los protocolos de canal de interacción deben estar de acuerdo con la GEM 1.0:2005, subsección 6.3. Esta norma
no considera otros protocolos y las API que ofrecerían acceso a ellos. Otros protocolos privados y posiblemente
otras API no están excluidos, pero están fuera del objetivo de esta Norma.
La Figura 4 ilustra el conjunto de protocolos de canal de interacción SBTVD definido que son accesibles por
aplicaciones MHP en algunos o todos los perfiles (ver la ABNT NBR 15606-1). Los detalles completos de las API
que ofrecen acceso a estos protocolos de interacción están en la ETSI TS 101 812:2003, Sección 11.
Figura 4 — Pila de protocolo del canal de interacción
10.2.2 Protocolo dependiente de la red
El protocolo dependiente de la red debe estar de acuerdo con la GEM 1.0:2005, Subsección 6.3.1.
10.2.3 Protocolo de internet (IP)
El protocolo de internet está definido en la RFC 791.
32
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-3:2007
10.2.4 Protocolo de control de transmisión (TCP)
El protocolo de control de transmisión está definido en la RFC 793.
10.2.5 UNO-RPC
Lo UNO-RPC debe estar de acuerdo con la GEM 1.0 :2005, Subsección 6.3.4.
10.2.6 UNO-CDR
Lo UNO-CDR debe estar de acuerdo con la GEM 1.0:2005, Subsección 6.3.5.
10.2.7 DSM-CC usuario para usuario
El DSM-CC usuario para usuario debe estar de acuerdo con la GEM las 1.0.1:2005, Subsección 6.3.6.
10.2.8 Protocolo HTTP
El protocolo HTTP debe estar de acuerdo con la GEM 1.0 :2005, Subsección 6.3.7.
10.2.9 Protocolo específico para el servicio
El protocolo específico para el servicio debe estar de acuerdo con la GEM 1.0:2005, Subsección 6.3.8.
10.2.10
Protocolo de datagrama del usuario (UDP)
El protocolo de datagrama de usuario (UDP) debe estar de acuerdo con la GEM 1.0:2005, Subsección 6.3.9.
10.2.11
DNS
El DNS debe estar de acuerdo con la GEM 1.0:2005, Subsección 6.3.10.
10.3 Protocolos de transporte para aplicaciones siendo cargados en el canal de interacción
Los protocolos de transporte para aplicaciones siendo cargados en el canal de interacción deben estar de
acuerdo con la GEM 1.1:2006, Subsección 6.4.
El sistema de archivo implementado apenas por el canal de interacción debe estar de acuerdo con la
GEM 1.0:2005, Subsección 6.4.
El híbrido entre el stream de transmisión y el canal de interacción debe estar de acuerdo con la GEM 1.0:2005,
Subsección 6.4.
11 Modelo de aplicación
11.1 Aplicación Ginga
La aplicación Ginga-J debe estar de acuerdo con la GEM 1.0:2005, sección 9 subsección 7.1. En esta Norma,
este modelo se utiliza como modelo Ginga-J; para el modelo Ginga-NCL la aplicación Ginga debe estar de
acuerdo con la ABN NBR 15606-2.
La aplicación Ginga es definida como una aplicación extendida de la aplicación GEM, además de las
especificaciones de la GEM 1.0. La aplicación GEM es un subconjunto de la aplicación GINGA-J. Así, la
aplicación Ginga-J, preparada sin las especificaciones adicionales, es equivalente a la aplicación GEM.
© ABNT 2007 - Todos los derechos reservados
33
ABNT NBR 15606-3:2007
11.2 Modelo Ginga-J
El modelo se utiliza como el modelo Ginga-J y debe estar de acuerdo con la GEM 1.0:2005, Subsección 9.2.
11.3 Como manejar el modelo NCL
El Modelo NCL debe estar de acuerdo con los detalles de la ABNT NBR 15606-2.
11.4 Gestión de recursos entre aplicaciones
La gestión de recursos entre aplicaciones debe estar de acuerdo con la ABNT NBR 15606-2.
12 Transmisión de informaciones de aplicación
12.1 Descriptores AIT y valores constantes
Los descriptores AIT y los valores constantes deben estar de acuerdo con la ARIB STD-B23 y con la Tabla 32.
Tabla 32 — Descriptores AIT y valores constantes
Donde se utiliza
Data contents descriptor
Data coding descriptor
Carousel ID descriptor
Association tag
descriptor
Tipo
Valor
0xC7
0xFD
0x13
Descriptor tag
0x14
Extension tag descriptor
0x1 5
Label descriptor
Caching priority
Content type descriptor
Reservado para MHP
para futuro descriptor OC
Application information
table (AIT)
(AIT)
Application
descriptor
Descriptor tag
0x70
0x71
0x72
0x730x7F
Table ID no PID
AIT
0x74
0x01
Transport protocol
descriptor
0x02
Ginga-J application
location descriptor
External application
authorisation descriptor
Ginga-NCL application
descriptor
34
PMT
Foco
Descriptores
Ver 12.2,
Anexo B,
Anexo C y
ARIB STD-B23
Ver ARIB
STD-B23
DII moduleinfo Ver ARIB STDBIOP objectinfo B23 (Carrusel de
datos y objetos)
OC
Ver Sección 12
0x00
Application name
descriptor
Ginga-J application
descriptor
Donde es
definido
EIT
Descriptor tag
0x03
Ver GEM Middleware
AIT
Ver Sección 12
y Anexo C
0x04
0x05
0x06
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-3:2007
Tabla 32 (continuación)
Donde se utiliza
Tipo
Ginga-NCL application
location descriptor
NCL HTML
reservado por el MHP
NCL-HTML
(reservado por el MHP)
Application icons
descriptor
Valor
0x0A
0x0B
DII location descriptor
0x0D
Reservado para MHP
para uso futuro
Private data specifier
descriptor
Reservado para MHP
para uso futuro
Definido por el usuario
Sistema de codificación
Sistema de codificación
Ginga-J
de datos
Sistema de transmisión (data_component_id)
AIT
Sistema de transmisión
de carrusel de datos
Sistema de transmisión Formato de transmisión
de carrusel de objetos (transmission_format)
Carrusel de objetos
Ginga
Identificación de
protocolo (protocol_id)
Carrusel de datos
Ginga (NCL)
Tipo de aplicación
Ginga-J application type
(application_type)
Descriptores
0x08-0x09
0x0C
IP signalling descriptor
Foco
0x07
Pre-fetch descriptor
Reservado para MHP
para uso futuro
Donde es
definido
0x0E –
0x010
0x11
0x12-0x5E
0x5F
0x60-07F
0x80-0xFE
A0
A3
1
10
0x0001
PMT
Ver 12.2 a 12.18 y
ARIB STD-B23
Área de
sistema
Ver 12.2 a 12.18 y
codificación de
ARIB STD-B23
datos
AIT
Ver 12.2 a 12.18, y
ARIB STD-B23
AIT
Ver 12.2 a 12.18, y
ARI B STD-B23
Ver ARI B
STD-B23
0x0004
0x0001
12.2 Ejecución de la aplicación Ginga
Para realizar la ejecución de las aplicaciones Ginga, es necesario especificar la aplicación y transmitir a
informaciones adicionales de la aplicación para controlarla.
El sistema de transmisión de la información de la aplicación para ser utilizada en esta Norma debe estar de
acuerdo con la GEM 1.0:2005, Sección 10.
© ABNT 2007 - Todos los derechos reservados
35
ABNT NBR 15606-3:2007
Las informaciones adicionales de acuerdo con la ARIB STD-B23 son las siguientes:
⎯ valores de identificación referentes al Ginga y a AIT, para identificar el almacenamiento del componente de
datos del additional_ ginga_j_info() desde el additional identifying information en el data component descriptor
para el ES que transmite la aplicación Ginga en la PMT;
⎯ almacenamiento del ginga_j_info() desde el additional information dentro del data contents descriptor para ser
almacenado con el área de los descriptores de un evento de programa que utilice las aplicaciones Ginga en la
EIT;
⎯ almacenamiento de la ait_identifier_info() desde el additional information dentro del data component descriptor
para el ES que transmite a AIT en la PMT;
⎯ en el campo additional_ ginga_j_info() y ginga_j_info(), el carrusel de objetos debe ser identificado con el
valor ‘10’.
Además de las informaciones arriba, la Application Information Table (Tabla de Informaciones de la Aplicación),
especificada en 12.16.1, debe ser transmitida en un ES que engloba el programa en forma de secciones privadas.
Utilizada la AIT, la información de la aplicación es almacenada (ver 12.17.1) sobre la estructura de los grupos de
descriptores almacenados en la AIT. Para informaciones adicionales relacionadas a las tablas PMT y EIT, ver el
Anexo C.
12.3 Señal de aplicaciones comunes
La señal de aplicaciones comunes debe estar de acuerdo con la GEM 1.0:2005, Subsección 10.1.1.
Las informaciones de aplicaciones se transmiten en secciones privadas, desde la Tabla 46 (ver 12.16.1), como
un ES que engloba el programa. De esta forma, se transmite la información adicional necesaria para cada
aplicación.
Como complemento, los valores de identificación del componente de datos son determinados para indicar la
existencia de la transmisión de la AIT, así como la aplicación GINGA, y la estructura de la selección de área del
data component descriptor (ver 12.7 para detalles).
Los siguientes descriptores deben ser almacenados en la AIT como información común, sin llevar en
consideración el formato de la aplicación:
⎯ transport protocol descriptor: Todas las aplicaciones deben estar en el objetivo de por lo menos un
transport protocol descriptor. Este descriptor puede ser almacenado tanto en el common information
descriptor loop como en el application information descriptor loop;
⎯ application descriptor: Un único descriptor de aplicación debe ser almacenado en un enlace de descriptor
de información de aplicación para cada una de éstas;
⎯ application name descriptor: Una única aplicación debe ser almacenada en un enlace de descriptor de
información de aplicación para cada una de éstas.
12.4 Señal de aplicación adicional necesaria para Ginga-J
Las exigencias especificadas en la GEM 1.0:2005, Subsección 10.1.2, deben ser observadas. Las informaciones
necesarias, como la aplicación Ginga, deben ser transmitidas vía AIT.
NOTA
36
Para los efectos de esta Norma, Ginga-J y DVB-J son equivalentes.
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-3:2007
En el enlace del descriptor de informaciones de aplicación AIT Ginga, los siguientes deben ser almacenados por
lo menos para una aplicación.
⎯ Ginga-J application descriptor;
⎯ Ginga-J application location descriptor;
o
⎯ Ginga-NCL application descriptor;
⎯ Ginga-NCL application descriptor location.
12.5 Informaciones adicionales en PSI/SI
Como para las informaciones de aplicación, la Tabla 32 de informaciones de aplicación (AIT) se transmite en modo
sección privada como un ES que comprende el programa. Las informaciones adicionales referentes a la
transmisión de informaciones de aplicación son las siguientes:
⎯ definición de valores de identificación correspondientes a Ginga-J y AIT para identificar el almacenamiento del
componente de datos de additional_ginga_j_info() de informaciones adicionales, identificando las
informaciones del descriptor de componente de datos para ES que transmite Ginga-J de PMT;
⎯ almacenamiento de Ginga-J info() en información adicional dentro del descriptor de contenidos de datos a ser
almacenados en el área del descriptor de un evento de programa que utiliza la aplicación Ginga-J en EIT;
⎯ almacenamiento ait_identifier_info() en información adicional dentro del descriptor de componente de datos
para ES que transmite AIT de PMT;
⎯ diferenciación de otros sistemas de transmisión atribuyendo 0x0004 como el protocol_id que corresponde a
los datos de transmisión de carrusel. Para detalles del selector_byte, ver 12.17.6;
⎯ atribución de un sistema de transmisión de carrusel de objetos en ‘10’ en el campo de
additional_ginga_j_info() y ginga_j_info() para identificar el sistema de transmisión de contenidos en nivel
PAT/PMT;
⎯ en el caso de transmission_format=’10’ (= sistema de transmisión de carrusel de objetos), el descriptor
association_tag (valor de tag: 0x14), el descriptor deffered_Association_tag (valor de tag: 0x15) o el descriptor
Carousel_id (valor: 0x13), especificados en la ISO/IEC 13818-6, deben ser almacenados en PMT, conforme
sea necesario.
12.6 Identificación del componente de datos
Un data_component_id es atribuido a la aplicación Ginga. Mientras tanto, un valor de identificación de componente
de datos es atribuido a la transmisión AIT y un stream elemental a ser transferido en el modo de sección privada
se agrega al PMT.
12.7 Descriptor de componente de datos y descriptor de contenidos de datos
12.7.1 Referencia indirecta
Desde el carrusel que transmite la aplicación Ginga, se debe realizar referencia indirecta con el descriptor de
componente de datos relevante al sistema de codificación Ginga por el componente de tag (component_tag.)
© ABNT 2007 - Todos los derechos reservados
37
ABNT NBR 15606-3:2007
12.7.2 Descriptor de componente de datos en aplicación Ginga - Sistema de codificación de datos
Cuando la identificación de la codificación de datos es realizada por el sistema de codificación Ginga, la estructura
additional_ginga_j_info(), tal como demostrado en la Tabla 33, se describe dentro del área de informaciones
adicionales de identificación en el descriptor de componente de datos. La información adicional que no se
transmite en AIT es almacenada aquí (ver la ABNT NBR 15603-2:2007, Subsección 8.3.20).
Tabla 33 — Additional_ginga_j_info()
Número de
bits
Sintaxis
additional_ginga_j_info() {
transmission_format
application_identifier_flag
document_resolution
independent_flag
if (application_identifier_flag == 1) {
application_identifier()
}
if (transmission_format == ‘00’ ){
download_id
ondemand_retrieval_flag
file_storable_flag
event_section_flag
reserved_future_use
}
else if (transmission_format == ‘01 ’){
reserved_future_use
}
else if (transmission_format == ‘10’){
carousel_id
ondemand_retrieval_flag
file_storable_flag
event_section_flag
reserved_future_use
Mnemónico
2
1
4
1
bslbf
bslbf
bslbf
bslbf
8
bslbf
32
1
1
1
5
uimsbf
bslbf
bslbf
bslbf
bslbf
8
bslbf
32
1
1
1
5
uimsbf
bslbf
bslbf
bslbf
bslbf
}
}
La descripción del additional_ginga_j_info( ) debe ser la siguiente:
⎯ transmission_format (formato de transmisión): el área de 2 bits especifica el sistema de transmisión de la
aplicación Ginga (ver Tabla 34);
Tabla 34 – Formato de transmisión
38
Valor
Descripción
00
Carrusel de datos y mensaje de eventos (excepto
servicio de datos sólo para almacenamiento)
00
Carrusel de datos (servicio de datos solo para
almacenamiento)
10
Carrusel de objetos
11
Reservado para el futuro
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-3:2007
⎯ application_identifier_flag (flag identificador de la aplicación): flag de 1 bit que indica si el identificador de
aplicación está incluido en el área de selección (ver Tabla 35);
Tabla 35 – Flag identificador de la aplicación
default_version_flag
Descripción
0
No utilizar el valor estándar para el número de la versión
1
Usar valor estándar para el número de la versión
⎯ document_resolution (resolución del documento): Resolución de la aplicación Ginga (correspondiente a las
características de resolución) y tasa de aspecto (correspondiente a las características de display-aspect-ratio)
son indicadas. Elegir uno de los valores de la Tabla 36;
Tabla 36 – Resolución del documento
Valor
0
1
10
11
100
101
110
111
1000
1001
1010
1010 - 1111
Descripción
Aplicaciones Ginga con múltiples tamaños y resoluciones
1920 x 1080 (16:9)
1280 x 720 (16:9)
960 x 540 (16:9)
720 x 480 (16:9)
720 x 480 (4: 3)
160 x 120 (4:3)
160 x 90 (16:9)
320 x 240 (4:3
320 x 180 (16:9)
352 x 288 (4:3)
Reservado para el futuro
⎯ independent_flag (flag independiente de disponibilidad de audio y video): indica si se presume que el
programa de transmisión de datos sea oído y visto independientemente; 0 = Imposible y 1 = Posible.
⎯ application_identifier() (identificador de aplicación): un valor para identificar exclusivamente la aplicación..
Ver Tabla 37 para los detalles;
Tabla 37 — Codificación de identificador de aplicación
Estructura de datos
application_identifier() {
Tasa de bits
String de bits
organization_id
32
bslbf
application_id
16
bslbf
⎯ organization_id (ID de la organización): campo de 32 bits que muestra el sistema que creó la aplicación.
La ID almacena el número internacionalmente exclusivo que le fue atribuido;
© ABNT 2007 - Todos los derechos reservados
39
ABNT NBR 15606-3:2007
⎯ application_id (ID de la aplicación): campo de 16 bits que almacena el número exclusivamente atribuido en el
sistema para identificar la aplicación. Si la aplicación descrita por el descriptor es un servicio adicional a un
programa de televisión o de radio, se utiliza para especificar la aplicación que realmente se asocia al
programa de televisión o radio;
⎯ download_id (ID de download): campo de 32 bits que sirve como rótulo que identifica el carrusel de forma
única. Muestra el carrusel que debía estar montado como configuración estándar;
⎯ ondemand_retrieval_flag (flag de disponibilidad de recepción de audio y video por demanda): área de 1 bit
que indica, para la recepción de la aplicación transmitida por dicho ES, si la adquisición de la aplicación desde
el carrusel en cada caso de la operación de audiencia está prevista. La capacidad de recepción es regulada
por la operación de cada entidad de medios; 0 = No disponible y 1 = Disponible;
⎯ file_storable_flag (flag de archivo almacenable): indica si el almacenamiento del archivo del programa de
transmisión de datos correspondiente es posible. Por ejemplo, el almacenamiento de archivo es difícil si la
información se actualiza durante el programa. La capacidad de almacenamiento es regulada por la operación
de cada entidad de medios. 0 = Archivo no almacenable y 1 = Archivo almacenable;
⎯ event_section_flag (flag de evento de la sección de transmisión): campo de 1 bit que indica si el mensaje de
evento es distribuida por este componente. 0 = El mensaje de evento no es distribuida y 1 = El mensaje de
evento es distribuida;
⎯ carousel_id (ID del carrusel): campo de 32 bits que es el valor de identificación que especifica de forma
exclusiva el carrusel de objetos. Este valor de identificación es especificado por el descriptor carousel_id
(descriptor del identificador del carrusel), que está almacenado en el PMT.
12.7.3 Descriptor de contenidos de los datos en la aplicación Ginga - Sistema de contenido de datos
Si la identificación de la codificación de datos se hace conforme el sistema de codificación Ginga, la estructura
ginga_j_info() mostrada en la Tabla 38 debe ser descrita en el área de selección del descriptor de contenidos de
datos en el EIT. Eso permite que la notificación avanzada de la aplicación Ginga sea programada para uso por la
unidad de evento de programa.
Las informaciones referentes a la aplicación Ginga y señales de controles se almacenan en la AIT. No se presume
que la aplicación sea controlada por la unidad de evento de programa. Como consecuencia de ello, no hay
mecanismo en la AIT que comprenda el cronograma por el cual la aplicación Ginga será utilizada para cada
unidad de programa por adelantado (ver la ABNT NBR 15603-2007, Subsección 8.3.28).
40
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-3:2007
Tabla 38 — Ginga_j_info()
Estructura de datos
ginga_j_info(){
transmission_format
reserved_future_use
document_resolution
default_version_flag
independent_flag
application_identifier_flag
content_id_flag
associated_application_flag
reserved_future_use
update_flag
ISO_639_language_code
if (application_identifier_flag == 1) {
application_identifier()
}
if (content_id_flag== 1) {
content_id
content_version
}
if (default_version_flag==0) {
application_profiles_length
for ( i=0; I<N; i++) {
application_profile
profile_major_version
Profile_minor_version
profile_micro_version
}
}
if (transmission_format == ‘00’ ){
ginga_carousel_info()
ondemand_retrieval_flag
file_storable_flag
reserved_future_use
} else if (transmission_format == ‘01’) {
ginga_stored_carousel_info()
} else if (transmission_format == ‘10’) {
ginga_object_carousel_info()
ondemand_retrieval_flag
file_storable_flag
reserved_future_use
Tasa de bits
2
1
4
1
1
1
1
1
3
1
24
bslbf
String de bits
bslbf
bslbf
bslbf
bslbf
bslbf
bslbf
bslbf
bslbf
bslbf
bslbf
bslbf
32
uimsbf
16
uimsbf
8
uimsbf
16
uimsbf
8
8
8
uimsbf
uimsbf
uimsbf
1
bslbf
1
6
bslbf
bslbf
1
bslbf
1
6
bslbf
bslbf
La descripción de la ginga_j_info( ) debe ser la siguiente:
⎯ transmission_format (formato de transmisión): área de 2 bits que especifica el sistema de transmisión de la
aplicación Ginga (ver Tabla 39);
© ABNT 2007 - Todos los derechos reservados
41
ABNT NBR 15606-3:2007
Tabla 39 – Formato de transmisión
Valor
Descripción
00
Carrusel de datos y mensaje de eventos (excepto
servicio de datos sólo para almacenamiento)
00
Carrusel de datos (servicio de datos sólo para
almacenamiento)
10
Carrusel de objetos
11
Reservado para el futuro
⎯ document_resolution (resolución de documento): resolución de la aplicación Ginga-J y display-aspect-ratio
que son indicadas en la Tabla 40;
Tabla 40 – Resolución de documento
Valor
0
1
10
11
100
101
110
111
1000
1001
1010
1010 - 1111
Descripción
Aplicaciones Ginga con múltiples tamaños y resoluciones
1920 x 1080 (16:9)
1280 x 720 (16:9)
960 x 540 (16:9)
720 x 480 (16:9)
720 x 480 (4: 3)
160x120 (4:3)
160x90 (16:9)
320x240 (4:3
320x180 (16:9)
352x288
Reservado para el futuro
⎯ default_version_flag (flag de utilización de la versión estándar): flag de 1 bit que indica que el valor estándar
especificado por la operación se utiliza como un perfil para la ejecución de la aplicación Ginga-J que debe ser
transmitida por el ES correspondiente. Debe estar de acuerdo con la Tabla 41;
Tabla 41 – default_version_flag
default_version_flag
Descripción
0
No utilizar el valor estándar para el número de la
versión
1
Usar valor estándar para el número de la versión
⎯ independent_flag (flag independiente de disponibilidad de audio y video): indica si se presupone que el
programa de transmisión de datos sea oído y visto independientemente; 0 = Imposible y 1 = Posible;
⎯ application_identifier_flag (flag identificador de la aplicación): flag de 1 bit que indica si el identificador de
aplicación está incluido en el área de selección; 0 = No Incluido y 1 = Incluido;
⎯ content_id_flag (flag de ID de contenidos): flag de 1 bit que indica si la ID de los contenidos y su Versión
están incluidos en el descriptor; 0 = No Incluido y 1 = Incluido;
42
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-3:2007
⎯ associated_application_flag (flag de aplicación asociada): flag de 1 bit que indica los contenidos asociados
al programa de televisión o radio, cuando la aplicación descrita por este descriptor sea un servicio adicional de
datos para el programa de televisión o radio. Para una aplicación que no sea un servicio adicional, el valor
debe siempre ser 0;
⎯ update_flag (flag de actualización): indica si hay distribución diferencial para esta aplicación en el futuro; 0 =
No hay distribución diferencial y 1 = Hay distribución diferencial;
⎯ ISO_639_language_code (código de lenguaje): código de lenguaje usado para la aplicación Ginga;
⎯ application_identifier() (identificador de aplicación): valor para identificar exclusivamente la aplicación (ver
Tabla 42);
Tabla 42 — Estructura del identificador de aplicación
Estructura de datos
Tasa de bits
String de bits
32
bslbf
16
bslbf
application_identifier() {
organization_id
application_id
}
⎯ organization_id (ID de la organización): campo de 32 bits que indica el sistema que preparó la aplicación.
Esta ID almacena el número internacionalmente exclusivo que le fue atribuido;
⎯ application_id (ID de la aplicación): campo de 16 bits que almacena el número que identifica la aplicación. El
número es atribuido de forma exclusiva en el sistema. Cuando la aplicación descrita por el descriptor sea un
servicio adicional al programa de televisión o radio, se utiliza para especificar la aplicación que de hecho se
asocia al programa de televisión o radio;
⎯ content_id (ID de contenidos): campo de 32 bits que es un rótulo que identifica el programa de transmisión
de datos y es atribuido de forma exclusiva en compañía de la transmisión. En caso de almacenamiento de
datos, si el content_id tiene el mismo valor de un programa de transmisión de datos anterior, los datos pueden
ser sobrescritos;
⎯ content_version (versión de los contenidos): campo de 16 bits que indica el número de la versión entre el
programa de transmisión de datos que tiene una ID de contenidos idéntica;
⎯ application_profiles_length (especificación de extensión del perfil de la aplicación): indica la extensión del
campo que especifica el perfil receptor con el cual la aplicación es ejecutable;
⎯ profile_major_version (número principal del perfil): campo de 8 bits que indica que el número principal entre
los números de versión de los perfiles de recepción debe corresponder por lo menos a la ejecución de
aplicación Ginga relevante;
⎯ profile_minor_version (número secundario de perfil): campo de 8 bits que indica el número secundario entre
los números de versión de los perfiles de recepción que debe corresponder a por lo menos la ejecución de
aplicación Ginga relevante;
⎯ profile_micro_version (micronúmero de perfil): campo de 8 bits que indica el micronúmero entre los números
de versión de los perfiles de recepción que debe corresponder a por lo menos la ejecución de aplicación
Ginga relevante;
© ABNT 2007 - Todos los derechos reservados
43
ABNT NBR 15606-3:2007
⎯ ginga_carousel_info( ): estructura de datos especificada en la ARIB STD-B24:2007, Anexo C2;
⎯ ondemand_retrieval_flag (flag de disponibilidad de recepción de audio y video por demanda): área de 1 bit
que indica, para la recepción de la aplicación transmitida por dicho ES, si la adquisición de la aplicación desde
el carrusel en cada caso de la operación de audiencia está prevista. La capacidad de recepción es regulada
por la operación de cada entidad de medios; 0 = No disponible y 1 = Disponible;
⎯ file_storable_flag (flag de archivo almacenable): indica si el almacenamiento del archivo del programa de
transmisión de datos correspondiente es posible. Por ejemplo, el almacenamiento de archivo es difícil si la
información se actualiza durante el programa. La capacidad de almacenamiento es regulada por la operación
de cada entidad de medios;
⎯ ginga_ stored_carousel_info(): estructura de datos especificada en la ARIB STD-B24:2007, Anexo C2;
⎯ ginga_object_carousel_info(): estructura de datos especificada en 12.7.4.2.
12.7.4 Descriptor de componente de datos para transmisión AIT
12.7.4.1
Ait identifier inf
Cuando la ID de la codificación de datos es transmisión AIT, la estructura ait_identifier_info() mostrada en la
abla 43 debe ser descrita dentro del área de selección del descriptor de componente de datos en el PMT
(ver la ABNT NBR 15603-2:2007, Subsección 7.2.3).
Tabla 43 — Ait_identifier_info()
Estructura de datos
ait_identifier_info(){
for ( i=0; i<N; i++ ) {
application_type
reserved_future_use
AIT_version_number
}
}
Tasa de bits
String de bits
16
3
5
uimsbf
bslbf
uimsbf
La descripción de la ait_identifier_info( ) debe ser la siguiente:
⎯ application_type (tipo de aplicación): indica el valor del tipo de aplicación a ser transmitido en la AIT. Como
en el DVB, al DVB-J se le atribuye 0x0001. En el Ginga-J, el valor debe también ser 0x0001;
⎯ AIT_version_number (número de la versión AIT): versión actual version_number almacenada.
12.7.4.2
objetos
Área de selección del descriptor de contenidos de datos en la transmisión del carrusel de
Cuando las informaciones para el control de recepción del carrusel de objetos están dentro del área de selección
del descriptor de contenido de datos, las informaciones mostradas en la Tabla 44 deben ser agregadas en la
posición del área de selección para cada esquema de codificación de datos.
44
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-3:2007
Tabla 44 — Estructura Ginga_object_carousel_info()
Estructura de datos
ginga_object_carousel_info(){
num_of_carousels
for(i=0; i< num_of_carousels; i++) {
association_tag
event_section_flag
reserved_future_use
Component_size_flag
default_transaction_id_flag
Tasa de bits
String de bits
8
uimsbf
16
1
3
1
1
uimsbf
bslbf
bslbf
bslbf
bslbf
default_timeout_DSI_flag
default_leak_rate_flag
1
1
bslbf
bslbf
32
uimsbf
32
uimsbf
32
uimsbf
22
2
uimsbf
bslbf
if (component_size_flag == ‘1’) {
component_size
}
if (default_transaction_id_flag == ‘1’) {
transaction_id
}
if (default_timeout_DSI_flag == ‘1’) {
timeout_value_DSI
}
if (default_leak_rate_flag == ‘1’) {
leak_rate
reserved
}
}
}
La descripción de la ginga_object_carousel_info() debe ser la siguiente:
⎯ num_of_carousels (número de carruseles): campo de 8 bits que indica el número de carruseles de objetos
incluidos en una vuelta del enlace;
⎯ association_tag (tag de asociación): campo de 16 bits que especifica el componente de stream en el cual el
mensaje DSI con el ServiceGatewayInfo del carrusel de objeto es almacenada, por el tag de asociación que
es atribuido por el descriptor association_tag de PMT;
⎯ event_section_flag: con este componente, es indicada la distribución de mensaje de evento;
⎯ component_size_flag (flag de tamaño de componente): campo de 1 bit que indica si el tamaño del
componente se codifica en la estructura de datos. Cuando el valor del campo component_size aún no está
definido, no está codificado (0: no codificado; 1: codificado);
⎯ default_transaction_id_flag: campo de 1 bit que indica si la ID de transacción está codificada en la estructura
de datos. Cuando la adquisición de DLL para ID opcional de transacción está especificada, la ID de
transacción no está codificada (0: no codificada; 1: codificada);
© ABNT 2007 - Todos los derechos reservados
45
ABNT NBR 15606-3:2007
⎯ default_timeoutDSI_flag: campo de 1 bit que indica si el valor de intervalo DSI está codificado en la
estructura de datos. Cuando el valor estándar definido por la operación se utiliza como el valor de intervalo
DSI, no está codificado (0: No codificado; 1: Codificado);
⎯ default_leak_rate_flag: campo de 1 bit que indica si la tasa de flujo está codificado en la estructura de datos.
Cuando el valor estándar definido por la operación se utiliza como valor de tasa de flujo, no está codificado (0:
No codificado; 1: Codificado);
⎯ component_size (tamaño de componente): campo de 32 bits que indica el tamaño total de los datos (unidad:
Byte) a ser transferidos por dicho carrusel de objetos;
⎯ transaction_id (ID de la transacción): valor de ID de la transacción a ser transmitido por el componente. La ID
no codificada de transacción muestra la necesidad de adquisición DSI que tiene ID de transacción opcional;
⎯ time_out_value_DSI (valor de intervalo DSI): campo de 32 bits que indica el valor de intervalo recomendado
(unidad en milisegundos) para la recepción de toda la sección DSI del carrusel relevante. Cuando el valor sea
0xFFFFFFFF, será una indicación de que no es valor de intervalo recomendable;
⎯ leak_rate (tasa de flujo): campo de 22 bits que indica la tasa de flujo del buffer de transporte del receptor. La
unidad es de 50 byte/s.
12.8 Localizador en descripción de aplicación
El localizador en descripción de aplicación debe estar de acuerdo con la GEM 1.0:2005, Subsección 11.3. El
locator descriptor debe estar de acuerdo con la ARIB STD-B23:2004, Sección 14.
12.9 Descripción de aplicación
La descripción de aplicación debe estar de acuerdo con la GEM 1.0:2005, Subsección 10.4. El sistema de
transmisión se describe en 12.3. La estructura de sesión AIT a ser transmitida en el modo de transmisión de
sesión privada debe estar de acuerdo con 12.16. El campo de string en la AIT puede ser codificado por un código
de caracteres de 8 unidades, así como UTF-8. Para la operación, uno de ellos se debe aplicar y la mezcla de
ambos códigos debe ser evitada. Por otro lado, los strings adquiridos por el método getName(), como la API
org.dvb.application, pueden ser automáticamente convertidos en strings utilizables en Java.
Los tipos de aplicaciones deben ser modificados, incluso el tipo de aplicación 0x0008, como aplicación reservada
GINGA, y 0x0009, como aplicación Ginga-NCL, como mostrado en la Tabla 45.
Tabla 45 — Tipo de aplicación
Tipo de aplicación
0x00
0x0001
0x0002
0x0006
0x0007
0x0008
0x0009
0x000A…0x7FFF
46
Descripción
Reservado
DVB-J / Ginga-J
DVB-HTML
ACAP-J
ARIB - BML
Ginga - Bridge
Ginga-NCL
Sujeto a registro con DVB
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-3:2007
12.10
Transmisión y monitoreo de descripción de aplicación
La transmisión y monitoreo de descripción de aplicación debe estar de acuerdo con la GEM 1.0:2005, Subsección
10.4.1. Como para el proceso de transmisión, la tabla de la sección que está de acuerdo con la estructura AIT se
transmite como ES que comprende el modo de transmisión vía sección privada del programa.
Para la operación, el valor 0x0001, 0x0008 y 0x0009 son atribuidos como el application_type de Ginga-J, Ginga y
Ginga-NCL, y 0x0001 es atribuido como el valor de protocol_id para significar el sistema de transmisión de
carrusel de objetos.
El selector_byte en el descriptor de protocolo de transporte para el sistema de transmisión del carrusel de datos
debe ser de la misma sintaxis, como para el caso del “protocolo de transporte de carrusel de datos” (protocol_id
=0x0004). Para los detalles de la estructura, ver Tabla 56.
12.11
Visibilidad de la descripción de aplicación
La visibilidad de la descripción debe estar de acuerdo con la GEM 1.0:2005, Subsección 10.4.2.
12.12
Detalles de la descripción de aplicación
Las descripciones de aplicación se transmiten con base en el sistema de transmisión descrito en 12.3. Los
descriptores de aplicación especificados en 12.17 se deben utilizar para el almacenamiento de las descripciones
de aplicación.
12.13
Tratamiento de la aplicación a partir del servicio previamente seleccionado
El tratamiento de la aplicación a partir del servicio previamente seleccionado debe estar de acuerdo con la GEM
1.0:2005, Subsección 10.4.4.
12.14
Descripción de aplicación específica al Ginga-J
La descripción de aplicación específica debe estar de acuerdo con la GEM 1.0:2005, Subsección 10.5.
12.15
Detalles de la descripción de aplicación Ginga
Las descripciones de aplicación Ginga-J se transmiten con base en el sistema de transmisión descrito en 12.3.
La estructura AIT y la estructura del descriptor en AIT deben estar de acuerdo con 12.6. El DVB-J en MHP debe
ser interpretado como Ginga-J en esta Norma. Los descriptores de aplicación especificados en 12.18 se deben
utilizar para el almacenamiento de los descriptores de la aplicación Ginga.
12.16
12.16.1
Sistema de codificación de información de aplicación
Información de aplicación
En la AIT, todas las informaciones relevantes a la aplicación y exigencias para estatus de partida están
almacenadas. También es posible instruir el receptor para alterar el estatus de partida desde la estación de TV
con los datos en la AIT.
Todas las secciones AIT que tengan el mismo Application_Type en el PID idéntico comprenden una subtabla. El
valor de tag de descripción en la AIT debe ser único en la AIT.
La estructura de datos de la información de aplicación AIT es mostrada en la Tabla 46.
© ABNT 2007 - Todos los derechos reservados
47
ABNT NBR 15606-3:2007
Tabla 46 — Tabla de información de la aplicación (AIT)
Estructura de datos
Tasa de bits
String de bits
application_information_section (){
Table_id
section_syntax_indicator
reserved_future_use
reserved
section_length
application_type
reserved
8
1
1
2
12
16
2
uimsbf
bslbf
bslbf
bslbf
uimsbf
uimsbf
bslbf
version_number
current_next_indicator
5
1
uimsbf
bslbf
section_number
8
uimsbf
last_section_number
reserved_future_use
common_descriptors_length
for (i=0, i<N; i++) {
descriptor ()
8
4
12
uimsbf
uimsbf
4
bslbf
12
uimsbf
8
4
12
uimsbf
bslbf
uimsbf
32
rpchof
}
reserved_future_use
application_loop_length
for (i=0; i<N;i++) {
application_identifier ()
application_control_code
reserved_future_use
application_descriptors_loop_length
for (j=0; j<M; ;j++) {
descriptor ()
}
}
CRC_32
}
La descripción de la application_information_section () debe ser la siguiente:
⎯ table_id (ID tabla): en este campo de 8 bits, 0x74 es almacenado para indicar que ésta es la tabla AIT;
⎯ section_syntax_indicator (indicador de sintaxis de la sección): la indicación de sintaxis de la sección es
siempre “1” en un campo de 1 bit;
⎯ section_length (extensión de la sección): campo de 12 bits. Los primeros 2 bits deben siempre ser “00.” Esto
especifica el número de bits del campo de extensión de sección para la última sección, incluyendo CRC32. El
valor debe ser inferior a 1021 (0x3FD en hexadecimal);
48
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-3:2007
⎯ application_type (tipo de aplicación): campo de 16 bits que indica el valor del tipo de aplicación que está
siendo transmitido por la AIT. En DVB, 0x0001 es atribuido a la aplicación DVB-J y el valor de los tipos de
aplicación se muestra en la Tabla 45;
⎯ version_number (número de la versión): campo de 5 bits que es el número de la versión de la subtabla. Se
debe agregar uno al número de la versión, cuando se haga una alteración en la información dentro de la
subtabla. Cuando el valor alcance “31,” el próximo valor será nuevamente “0.”
⎯ current_next_indicator (próximo indicador actual): esta indicación de 1 bit es siempre “1.”;
⎯ section_number (número de sección): campo de 8 bits que muestra el número de la sección. El número de la
sección de la primera sección en la subtabla es 0x00. Cada adición de una sección que tiene la ID de tabla y
tipo de aplicación idénticos añade “1” al número de la sección;
⎯ last_section_number (número de la última sección): campo de 8 bits que especifica el número de la última
sección en la subtabla a la cual las secciones pertenecen;
⎯ common_descriptors_length (extensión del enlace de descriptores comunes): campo de 12 bits que
especifica la extensión del byte del área común subsiguiente de descriptores. Los descriptores dentro del área
de descriptores son aplicables a todas las aplicaciones en la subtabla AIT;
⎯ application_control_code (código de control de la aplicación): campo de 8 bits que especifica el código de
control del estatus de la aplicación. El campo es dependiente del valor de tipo de aplicación. Ver 12.16.5 para
mayores detalles;
⎯ application_loop_length (extensión del enlace de información de aplicación): campo de 12 bits que
especifica la extensión total del enlace en byte donde es almacenada la información de la aplicación
subsiguiente;
⎯ application_identifier() (identificador de aplicación): ver Tabla 47;
⎯ application_descriptors_loop_length (extensión del enlace de descriptores de información de aplicación):
campo de 12 bits que especifica la extensión del byte del área subsiguiente de descriptores. Estos
descriptores en el área de descriptores se aplican solamente a la aplicación designada.
12.16.2
Application ID – Identificación de codificación de la aplicación
Una aplicación es identificada exclusivamente por el identificador de aplicación mostrado en la Tabla 47. Este
identificador está compuesto por una estructura de 6 bytes (48 bits).
Tabla 47 — Identificador de la aplicación
Estructura de datos
application_identifier () {
organization_id
application_id
}
Tasa de bits
String de bits
32
16
bslbf
bslbf
bslbf
La descripción de la application_identifier () debe ser la siguiente:
⎯ organization_id (ID de la organización): campo de 32 bits que indica la organización que creó la aplicación.
Esta ID almacena el número atribuido exclusivamente en el mundo;
⎯ application_id (ID de la aplicación): campo de 16 bits que almacena el número que identifica la aplicación y
que es atribuido exclusivamente en la ID de la organización. La ID de aplicación se divide en dos bandas. Una
es la banda de aplicación no firmada y la otra es la banda de aplicación firmada. Esta división se realiza para
fines de seguridad (ver Anexo B). La banda del valor es respectivamente mostrada en la Tabla 48.
© ABNT 2007 - Todos los derechos reservados
49
ABNT NBR 15606-3:2007
Tabla 48 — Valor de ID de la aplicación
Valor de ID de la aplicación
0x0000. ..0x3fff
0x40000...0x7fff
0x8000. ..0xfffd
0xfffe
0xffff
Tipo de aplicación
Banda de aplicación no firmada
Banda de aplicación firmada
Reservado por DVB
Wild card value (indica todas las aplicaciones
firmadas de la misma ID de organización)
Wild card value (indica todas las aplicaciones de
la misma ID de organización)
En la ID de la aplicación, los valores 0xffff y 0xfffe son para wild card value. Éstos no se utilizan para especificar la
aplicación, pero, por ejemplo, se usan como descriptor para autorización de aplicación externa. 0xffff corresponde
a todas las aplicaciones que tienen la misma ID de organización (organization_id). 0xfffe corresponde a todas las
aplicaciones firmadas que tienen la misma ID de organización.
Algunas veces el mismo identificador de aplicación se utiliza entre aplicaciones de diferentes tipos, como,
por ejemplo, en el caso de la ejecución de la misma función por diferentes tipos de aplicación.
NOTA
12.16.3
Un sólo tipo aparece en la colección de subtablas AIT del mismo tipo de aplicación en un servicio.
Efecto sobre el ciclo de vida
La directriz básica del efecto sobre el ciclo de vida se presenta para la ocasión en la que el servicio es alterado o
en que las aplicaciones que tienen el mismo identificador de aplicación son iniciadas, de la siguiente manera:
⎯ en el changeover de servicio, si el service_bound_flag en la aplicación activa en el servicio anterior es “0” y el
identificador de la aplicación existe en la AIT del servicio recientemente seleccionado, entonces la aplicación
funciona continuamente, a menos que haya alguna restricción de recurso;
⎯ en el changeover de servicio, si el service_bound_flag en la aplicación activa en el servicio anterior es “0” y si
sólo la aplicación está en la lista de descriptores de autorización de aplicación externa, la aplicación trabaja
continuamente, incluso si la aplicación no forma parte del servicio recientemente seleccionado, a menos que
haya alguna restricción de recurso;
⎯ como para una aplicación que tiene un identificador de aplicación, sólo una instancia es activada. Incluso si
otra aplicación tiene el mismo identificador, no puede ser activada si una aplicación con el mismo identificador
de aplicación ya ha existido;
⎯ eso afecta el comportamiento de la API de inicio de aplicación o inicio automático de la aplicación. Si el
service_bound_flag “1” es configurado para la aplicación, terminará (KILL) a cada selección de servicio.
12.16.4
Autenticación del ID de aplicación
La autenticación del ID de aplicación debe estar de acuerdo con la GEM 1.0:2005, Subsección 12.5. La ID de la
aplicación es autenticada con la ID de la organización (organization_id) almacenada en el campo de sujeto de
certificado.
12.16.5
Control de aplicaciones de ciclo de vida
Para Application Life Cycle Control, mecanismos de señalización se deben suministrar desde la estación de
transmisión, para controlar el ciclo de vida de las aplicaciones del tipo estándar.
50
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-3:2007
12.16.6
Acceso y salida del dominio de la aplicación
Entering and Leaving the Application Domain Application es el dominio definido como una colección de servicios
que tiene aplicaciones listadas en la AIT. Eso significa que las aplicaciones son las listadas en los enlaces de
información de aplicación de AIT o las listadas en los descriptores de autorización de aplicación externa.
Los servicios cuyas aplicaciones no están listadas como arriba mencionado son considerados fuera del dominio de
la aplicación.
12.16.7
Control dinámico del ciclo de vida de las aplicaciones Ginga
El control dinámico del ciclo de vida de las aplicaciones Ginga debe estar de acuerdo con la GEM 1.0:2005,
Subsección 10.4.3 y se extiende a ETSI TS 101 812:2003, Subsección 10.6.2.
Ginga define el “application_control_code” valor 0x07 como aplicaciones UNBOUND (ver Tabla 49).
Tabla 49 — Valores de código de control de aplicación Ginga
Código
0x00
Identificador
0x01
AUTOSTART
0x02
PRESENT
0x03
DESTROY
0x04
KILL
0x05
0x06
REMOTE
0x07
UNBOUND
0x08…0xFF
© ABNT 2007 - Todos los derechos reservados
Semántica
Reservado para uso futuro
Aplicaciones con el código de control
AUTOSTART son iniciadas automáticamente
cuando el receptor cambia para este servicio
Los aplicaciones con código de control
PRESENT no son iniciadas automáticamente,
pero son agregadas a la lista de aplicaciones
disponibles del receptor.
El usuario puede entonces elegir iniciar este
aplicativo seleccionándolo en la lista
Las aplicaciones con DESTROY son
automáticamente eliminadas por el receptor
Los aplicaciones con KILL son
automáticamente eliminados por el receptor.
La diferencia de ese código con el código de
control DESTROY es que una aplicación con
el código de control KILL puede tener opción
de garantía de continuidad de operación si la
aplicación lo elige
Reservado para uso futuro
Identifica una aplicación remota que
solamente es lanzada después de la
selección del servicio
Aplicaciones con código de control
UNBOUND son análogas a las aplicaciones
La diferencia del PRESENT es que el
receptor pregunta al usuario si la aplicación
debe ser almacenada para ejecución
posterior
Reservado para uso futuro
51
ABNT NBR 15606-3:2007
12.17 Descriptores para AIT - Descriptores para transmisión de informaciones de las
aplicaciones
12.17.1
Descriptores comunes
Los descriptores a ser comúnmente utilizados en la AIT, independientemente del tipo de aplicación, se describen
el 12.17.2 a 12.17.11.
12.17.2
Descriptor de aplicación
Un descriptor de aplicación es almacenado en el enlace del descriptor de información de la aplicación AIT para cada
aplicación (ver Tabla 50).
Tabla 50 — Estructura del descriptor de aplicación
Estructura de datos
Tasa de bits
String de bits
application_descriptor () {
descriptor_tag
descriptor_length
application_profiles_length
for ( i=0; i<N ; i++ ) {
application_profile
version.major
version.minor
8
8
8
uimsbf
uimsbf
uimsbf
16
8
8
uimsbf
uimsbf
uimsbf
version.micro
8
uimsbf
service_bound_flag
1
bslbf
visibility
reserved_future_use
application_priority
for ( i=0; i<N ; i++ ) {
transport_protocol_label
2
5
8
bslbf
bslbf
uimsbf
}
8
}
}
La descripción de la application_descriptor () debe ser la siguiente:
⎯ descriptor_tag (tag descriptor): campo de 8 bits; 0x00 es almacenado para indicar que éste es el descriptor
mencionado;
⎯ application_profiles_length (extensión de información del perfil de la aplicación): Campo de 8 bits que indica
la extensión total de información del perfil de la aplicación que está incluida en el enlace subsiguiente;
⎯ application_profile (perfil de la aplicación): campo de 16 bits. El perfil de la aplicación que puede ejecutar la
aplicación es almacenado. Si el perfil es montado en el receptor, significa que la aplicación es ejecutable. Los
detalles de perfil se definen para cada tipo de aplicación;
⎯ version.major (versión principal): campo de 8 bits que indica la versión principal del perfil arriba mencionado;
⎯ version.minor (versión secundaria): campo de 8 bits que indica la versión secundaria del perfil arriba
mencionado;
⎯ version.micro (microversión): campo de 8 bits que indica la microversión del perfil arriba mencionado;
52
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-3:2007
Los cuatro primeros campos descritos arriba comprenden un perfil mínimo para ejecución de esta aplicación.
El terminal Ginga inicia esa aplicación si cualquiera de las siguientes fórmulas teóricas es aplicable y cualquier
perfil evidencial “verdadero” en la información de perfil de la aplicación:
(perfil de la aplicación Є recolecta de los perfiles montados en el terminal)
Y {(versión principal de la aplicación < versión principal del terminal para el perfil)
O [(versión principal de la aplicación – versión principal del terminal para el perfil)
Y ({versión secundaria de la aplicación < versión secundaria del terminal para el perfil }
O {[versión secundaria de la aplicación = versión secundaria del terminal para el perfil]
Y [microversión de la aplicación ~ microversión del terminal para el perfil]} ) ] }
Las definiciones del perfil detallado de la plataforma en aplicación Ginga-J y Ginga-NCL deben estar de
acuerdo con la ABNT NBR 15606-1.
La codificación del perfil en aplicación Ginga-J debe estar de acuerdo con el GEM 1.0.
La codificación del perfil de la aplicación Ginga-NCL debe estar de acuerdo con la ABNT NBR 15606-2.
⎯ service_bound_flag (service bound flag): campo de 1 bit que indica si la aplicación está efectiva apenas en
el presente servicio. Si el campo es “1,” la aplicación es relevante apenas al servicio actual. Cuando el servicio
es alterado para otro servicio, la finalización del procesamiento de la aplicación mencionada será iniciada;
⎯ visibility (visibilidad): campo de 2 bits que indica si la aplicación es visible a los usuarios finales cuando está
activada. Las definiciones de estatus para el valor de visibilidad son mostrados en la Tabla 51;
⎯ application_priority (prioridad de la aplicación): campo de 8 bits que indica la prioridad relativa entre las
aplicaciones notificadas en el servicio;
⎯ transport_protocol_label (rótulo de protocolo de transporte): campo de 8 bits que almacena el valor para
identificación única del protocolo de transporte que transporta la aplicación. El valor corresponde al valor del
campo transport_protocol_label del descriptor del protocolo de transporte.
Tabla 51 — Visibilidad
Valor visible
Descripción
0
Esta aplicación no es visible a las otras aplicaciones vía
enumeración de aplicación API, ni a los usuarios vía
navegador, excepto en caso de error de información de
1
Esta aplicación no es visible para los usuarios, pero es
visible desde otras aplicaciones vía enumeración de
aplicación API
10
Reservado para uso futuro
11
Esta aplicación es visible tanto para los usuarios como para
las otras aplicaciones
© ABNT 2007 - Todos los derechos reservados
53
ABNT NBR 15606-3:2007
12.17.3
Descriptor del nombre de aplicación
Un descriptor de nombre de la aplicación es almacenado para cada aplicación en el enlace del descriptor de
información de la aplicación AIT. El nombre de la aplicación se utiliza para diferenciación y suministra la información a
los usuarios (ver Tabla 52).
Tabla 52 — Estructura del descriptor de nombre de la aplicación
Estructura de datos
Tasa de bits
String de bits
8
8
24
8
uimsbf
uimsbf
uimsbf
bslbf
uimsbf
8
uimsbf
application_name_descriptor () {
descriptor_tag
descriptor_length
for ( i=0; i<N ; i++ ) {
ISO_639_language_code
application_name_length
for ( j=0; j<application_name_length ; j++ ) {
application_name_char
}
}
}
La descripción de la application_name_descriptor () debe ser la siguiente:
⎯ descriptor_tag (descriptor de tag): campo de 8 bits; 0x01 es almacenado para indicar que éste es el
descriptor mencionado;
⎯ ISO_639_language_code (código del lenguaje): campo de 24 bits que identifica el lenguaje del descriptor del
nombre de la aplicación. El código del lenguaje es indicado por el código three-alphabetical-letter como
dispuesto en la ISO 639-2. Cada letra se codifica en 8 bits, de acuerdo con la ISO 8859-1, e inserida de
acuerdo con el orden en el campo de 24 bits;
⎯ application_name_length (descripción de la longitud del nombre de la aplicación): campo de 8 bits que
indica la longitud del byte de la subsiguiente descripción del nombre de la aplicación;
⎯ application_name_char (descripción del nombre de la aplicación): campo de 8 bits que especifica la letra de
descripción del nombre de la aplicación. Esta letra de descripción se utiliza como información por los usuarios.
12.17.4
Descriptor de la información de los iconos de la aplicación
El descriptor de la información de los iconos de la aplicación es almacenado por uno en su mayoría para cada
aplicación (ver Tabla 53). El descriptor indica la información sobre el icono relevante para la aplicación. El formato de
los contenidos del icono se codifica por el PNG y usa un sistema proporcionado de acuerdo con la ABNT NBR 15606-1.
54
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-3:2007
Tabla 53 — Estructura del descriptor de la información de los iconos de la aplicación
Estructura de datos
Tasa de bits
String de bits
8
8
8
uimsbf
uimsbf
uimsbf
8
uimsbf
16
bslbf
8
uimsbf
application_icons_descriptor () {
descriptor_tag
descriptor_length
icon_locator_length
for ( i=0; i<N ; i++ ) {
icon_locator_byte
}
icon_flags
for ( i=0; i<N ; i++ ) {
reserved_future_use
}
}
La descripción de la application application_icons_descriptor () debe ser la siguiente:
⎯ descriptor_tag (descriptor de tag): campo de 8 bits que almacena 0x0B, que indica el descriptor mencionado;
⎯ icon_locator_length (longitud del localizador de icono): campo de 8 bits que indica la longitud de byte del
subsiguiente localizador del icono;
⎯ icon_locator_byte (localizador de icono): campo de 8 bits que almacena el localizador del archivo de imagen
estática como un icono. Este localizador debe ser colocado antes del nombre del archivo de icono y debe
estar de acuerdo con la GEM 1.0:2005, Subsección 10.4.3. Para la aplicación Ginga-J, existen reglas en el
caso en el que application_type sea 0x0008 y hay un camino relativo de la base del directorio definido por la
aplicación Ginga-J almacenado;
⎯ icon_flags (icono de flag): este campo de 16 bits almacena la flag que indica el tamaño y el aspecto de la
relación del icono usable. Los detalles deben estar de acuerdo con la GEM 1.0:2005, Subsección 10.4.3, y la
codificación de cada caso es según mostrado en la Tabla 54. El valor es almacenado después del OR
(dirección lógica) por la unidad.
Tabla 54 — Bits del icono de la flag
Bits de icono de flag
0000 0000 0000 0001
0000.0000.0000.0010
0000.0000.0000.0100
0000.0000.0000.1000
0000.0000.0001.0000
0000.0000.0010.0000
0000.0000.0100.0000
0000.0000.1000.0000
0000 0001 0000 0000
xxxx xxx0 0000 0000
Tamaño de los iconos y relación de aspecto
32 x 32 para exhibir pixels cuadrados
32 x 32 para transmitir pixels en una pantalla 4:3
24 x 32 para transmitir pixels en una pantalla 16:9
64 x 64 para exhibir pixels cuadrados
64 x 64 para transmitir pixels en una pantalla 4:3
48 x 64 para transmitir pixels en una pantalla 16:9
128 x 128 para exhibir pixels cuadrados
128 x 128 para transmitir pixels en una pantalla 4:3
96 x 128 para transmitir pixels en una pantalla 16:9
reserved_future_use
El nombre del archivo del icono se codifica de acuerdo con el valor del icono de la flag descrito arriba. La codificación
del nombre del archivo debe estar de acuerdo con la GEM 1.0:2005, Subsección 10.4.3.
© ABNT 2007 - Todos los derechos reservados
55
ABNT NBR 15606-3:2007
12.17.5
Descriptor de autorización de aplicación externa
El descriptor de autorización de aplicación externa puede ser almacenado en uno o más en el primer enlace
descriptor común del AIT, conforme necesidad. En cada descriptor hay información relevante almacenada de las
aplicaciones externas. Una aplicación externa es aquélla que puede operar continuamente con las aplicaciones
listadas en la subtabla AIT, pero no pueden ser activadas del servicio mencionado.
La autorización externa es aplicable para la aplicación que tiene application_identifier() en la application_type
especificada por la AIT que incluye este descriptor (ver Tabla 55).
Tabla 55 — Estructura del descriptor de autorización de aplicación externa
Estructura de datos
external_application_authorisation_descriptor () {
descriptor_tag
descriptor_length
for ( i=0; i<N ; i++ ) {
application_identifier ()
application_priority
}
}
Tasa de bits
String de bits
8
8
uimsbf
uimsbf
8
uimsbf
La descripción del external_application_authorisation_descriptor () debe ser la siguiente:
⎯ descriptor_tag (descriptor de tag): campo de 8 bits donde 0x05 es almacenado para indicar el descriptor de
autorización de aplicación.
⎯ application_identifier() (identificador de aplicación): campo de 48 bits que indica la aplicación en la que la
referencia externa está disponible. Para detalles de la estructura del campo, ver 12.16.1;
⎯ application_priority (prioridad de la aplicación): campo de 8 bits que indica la prioridad de la presente
aplicación en la suposición del contexto del servicio mencionado. Para detalles de la prioridad, ver 12.17.2.
12.17.6
Transport protocol descriptor (descriptor de protocolo de transporte)
El transport protocol descriptor indica la identificación del protocolo de transporte relevante para el componente del
servicio y almacena información sobre el protocolo. Este protocolo es almacenado en el primer enlace del descriptor
común o enlace del descriptor de la información de la aplicación. Cuando esto es almacenado en el enlace de
descriptor común, es aplicable para todas las subtablas del AIT. El descriptor del protocolo de transporte en el enlace
del descriptor de la información de la aplicación describe el protocolo de transporte adicional para ser usado
específicamente en la aplicación (ver Tabla 56).
Tabla 56 — Estructura del descriptor de protocolo de transporte
Estructura de datos
transport_protocol_descriptor () {
descriptor_tag
descriptor_length
protocol_id
transport_protocol_label
for ( i=0; i<N ; i++ ) {
selector_byte
Tasa de bits
String de bits
8
8
16
8
uimsbf
uimsbf
uimsbf
uimsbf
8
uimsbf
}
}
56
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-3:2007
La descripción del transport_protocol_descriptor () debe ser la siguiente:
⎯ descriptor_tag (descriptor de tag): campo de 8 bits que almacena 0x02, que indica que éste es el actual
descriptor de transporte;
⎯ protocol_id (identificación de protocolo): campo de 16 bits que indica el protocolo que transporta la aplicación
(ver Tabla 57);
Tabla 57 — Valores de la identificación de protocolo
Valores
0x0000
0x0001
0x0002
0x0003
0x0004
0x0005.. . FxFFFF
Descripción
Reservado para el futuro
Protocolo de transporte del carrusel de
objetos
IP a través de DVB Multiprotocolo
Encapsulado conforme definido en la
EN 301 192 y ETSI TR 101 202
Reservado/Data Piping
Protocolo de transporte del carrusel de
datos
reserved_future_use
⎯ transport_protocol_label (rótulo de protocolo de transporte): Campo de 8 bits que indica el valor que
identifica únicamente el protocolo de transporte en la sección AIT. Para el descriptor de la aplicación, ver el
dispositivo de conexión (por ejemplo, el stream elemental del carrusel) que transporta la aplicación con estos
valores;
⎯ selector_byte (selector de área): Campo de 8 bits que almacena información adicional proveída por cada
identificación de protocolo. La estructura de datos descrita en el área se especifica por separado por cada
protocol_id (ver Tabla 58).
Tabla 58 — Estructura del selector_byte
Valores del Protocol_id
0x0000
0x0001
0x0002
0x0003
0x0004 (T.B.D.)
0x0005.. .FxFFFF
12.17.7
Estructura del selector de área
Reservado para el futuro
Ver Tabla 54
Ver 12.17.8
Indefinido / Data Piping
Ver Tabla 54
Reservado para el futuro
Transporte a través del OC (carrusel de objeto)
La estructura de datos se muestra en la Tabla 59 para el protocolo de transporte del carrusel de objetos
(protocol_id=0x0001) y el protocolo de transporte del carrusel de datos (protocol_id=0x0004).
© ABNT 2007 - Todos los derechos reservados
57
ABNT NBR 15606-3:2007
Tabla 59 — Estructura del protocolo de transporte del descriptor del selector
de área (en el caso de protocolo de transporte del carrusel de objetos/protocolo
de transporte de carrusel de datos)
Estructura de datos
remote_connection
reserved_future_use
if (remote_connection == “1”) {
original_network_id
transport_stream_id
service_id
}
component_tag
Tasa de bits
String de bits
1
7
bslbf
bslbf
16
16
16
uimsbf
uimsbf
uimsbf
8
uimsbf
La descripción debe ser la siguiente:
⎯ remote_connection (conexión remota): si este campo de 1 bit está en “1,” esto muestra que el componente
de servicio vigente se transmite de otra fuente distinta a la que transmite para AIT. Un servicio como éste no
se ejecuta automáticamente, pero es visible y viable de iniciarse a través de la API. Además de ello, REMOTE
es almacenado de esa manera en la aplicación en application_control_code;
⎯ original_network_id (identificador de la red original): cuando remote_connection está en “1,” el identificador
de la red original para el servicio de transmisión vigente es almacenado;
⎯ transport_stream_id (identificador de transport stream): cuando remote_connection es “1,” el identificador de
transport stream de la transmisión de servicio actual es almacenado;
⎯ service_id (identificador de servicio): cuando remote_connection está en “1,” el servicio (identificado por el
identificador de servicio) de la transmisión vigente es almacenado;
⎯ component_tag (componente de tag): indica el componente del servicio principal que transmite la aplicación.
En el caso de carrusel de datos, el stream elemental que transmite el carrusel automáticamente montado en
el inicio de la aplicación es indicado. En el caso de carrusel de objetos, el stream elemental que transmite DSI
es indicado.
12.17.8
Transporte a través de IP
Cuando el identificador de protocolo es 0x0002 el selector de bytes en el descriptor del protocolo de transporte
debe estar de acuerdo con la Tabla 60, para proveer toda la información necesaria para la obtención de las
aplicaciones Ginga y componentes de datos de las aplicaciones entregadas por el protocolo de IP.
58
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-3:2007
Tabla 60 — Sintaxis del selector de bytes para el transporte de IP
Estructura de datos
remote_connection
reserved_future_use
if (remote_connection == “1”) {
original_network_id
transport_stream_id
service_id
}
Tasa de bits
1
7
String de bits
bslbf
bslbf
16
16
16
uimsbf
uimsbf
uimsbf
1
7
bslbf
bslbf
8
uimsbf
8
uimsbf
alignment indicator
reserved for future use
for ( i=0; i<N; i++) {
URL_length
for ( j=0; j<URL length; j++) {
URL_byte }
}
La descripción debe ser la siguiente:
⎯ remote_connection: este y los tres campos asociados (original_network_id, transport_stream_id y
service_id) tienen semántica y sintaxis idénticas a los campos con los mismos nombres de acuerdo con
12.17.7;
⎯ alignment_indicator: campo de 1 bit que indica la alineamiento que existe entre los bytes del
datagram_section y los bytes de transporte de stream;
⎯ URL_length: campo de 8 bits que indica el número de bytes en la URL;
⎯ URL_byte: estos bytes forman una URL conforme RFC 2396.
Para la URL usando el campo del “servidor” incluyendo la notación host:port, conforme definido en la RFC 2396,
solamente direcciones numéricas IP serán usadas para identificar las transmisiones de IP transportadas en el
canal de difusión conforme no hay Domain Name Service-Servicio del Nombre de Dominio en el escenario
solamente de difusión a ser usado para nombres en resolución. IP para mapeo MAC se hará tal como se describe
en la RFC 1112.
NOTA
Esta Norma no define el formato de URL a ser mantenido por este descriptor. Por eso, el formato de URL no se
puede usar de manera interoperable.
12.17.9
Descriptor de señalización de IP
El descriptor de señalización IP se define para el uso tanto en el “común” como en la “aplicación” del enlace de la
AIT. Este descriptor indica la identificación de la organización que provee los streams multicast usados por todas
las aplicaciones (cuando está presente en el enlace “común”) o por la aplicación de señalización particular
(cuando está presente en el enlace de la “aplicación”). Para la definición del INT, ver EN 301 192.
Este descriptor y el INT con action_type 0x01 se deben utilizar por las aplicaciones confiando en la presencia de
los streams multicast IP en el link de la difusión. El conocimiento de la identificación presente en el descriptor
habilita la recuperación de la tabla apropiada de notificación de IP (INT) con action_type 0x01 que contiene la
correspondencia entre la dirección del IP multicast, port y localización del stream (ver Tabla 61).
© ABNT 2007 - Todos los derechos reservados
59
ABNT NBR 15606-3:2007
Tabla 61 — Sintaxis del descriptor de señalización de IP
Sintaxis
ip_signalling_descriptor () {
descriptor_tag
descriptor_length
platform_id
Bits
Mnemónicos
8
8
24
uimsbf
uimsbf
uimsbf
La descripción del ip_signalling_descriptor () debe ser la siguiente:
⎯ descriptor_tag: campo de 8 bits que con valor 0x11 identifica el descriptor;
⎯ descriptor_length: campo de 8 bits que identifica el número de bytes, siguiendo la longitud del campo;
⎯ platform_id: campo de 24 bits conteniendo un platform_id de la organización proveyendo streams IP/MAC en
el transporte de streams/servicios. Asignaciones del valor de platform_id son encontradas en el ETSI TR 101
162.
12.17.10 Pre-fetch descriptor (descriptor de pre-busca)
Solamente un descriptor pre-fetch es almacenado en el enlace del descriptor de la información de la aplicación AIT,
conforme necesidad. Este descriptor se define para ser usado por el carrusel de objetos (protocol_id=0x0001).
Cada descriptor es asociado a un descriptor de protocolo de transporte a través del rótulo del protocolo de
transporte (ver Tabla 62).
El terminal Ginga-J puede adquirir anticipadamente módulos denotados por el rótulo terminal para acelerar el
tiempo de inicio de la aplicación. Así como para los rótulos, los descriptores de rótulos especificados por la
transmisión del carrusel de objetos se usan de acuerdo con la ISO/IEC 13818-6:1998, Anexo B, y con la ARIB
STD-B23. La difusión de esta señalización es opcional.
Tabla 62 — Estructura del descriptor de pre-fetch
Estructura de datos
Tasa de bits
String de bits
8
8
8
uimsbf
uimsbf
uimsbf
8
uimsbf
label_char
8
uimsbf
prefetch_priority
8
uimsbf
prefetch_descriptor () {
descriptor_tag
descriptor_length
transport_protocol_label
for ( i=0; i<N ; i++ ) {
label_length
for ( j=0; j<label_length ; j++ ) {
}
}
}
60
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-3:2007
La descripción del prefetch_descriptor () debe ser la siguiente:
⎯ descriptor_tag (descriptor tag): campo de 8 bits donde 0x0C es almacenado para mostrar dicho descriptor;
⎯ transport_protocol_label (rótulo del protocolo de transporte): campo de 8 bits que almacena el rótulo del
protocolo de transporte para especificar el carrusel de objetos que transmite los módulos referidos en el
descriptor pre-fetch arriba. Para el rótulo del protocolo de transporte, ver 12.17.6;
⎯ label_length (longitud de rótulo): campo de 8 bits que indica la longitud de bytes del rótulo de descripción a
ser incluido en el consecuente enlace;
⎯ label_char (descripción de rótulo): campo de 8 bits. Un rótulo del módulo está almacenado. Esto corresponde
a la descripción de rótulo transmitida por el descriptor de rótulos que está almacenado en el userInfo del
moduleInfo del DII en el carrusel de objetos;
⎯ prefetch_priority (prioridad pre-fetch): campo de 8 bits que almacena los valores de 1 a 100. Estos valores
muestran la prioridad del pre-fetch. Mayor valor muestra mayor prioridad.
12.17.11 Descriptor de localización DII
Para cada aplicación solamente un descriptor de localización DII puede ser dado, en caso de ser necesario. Este
descriptor puede ser almacenado tanto en el enlace de descriptor común como en el enlace del descriptor de la
información de la aplicación. Esto se define para ser usado por el sistema de transmisión del carrusel de objetos
(protocol_id=0x0001). Cada descriptor es asociado a un descriptor de protocolo de transporte a través de un rótulo
de protocolo de transporte.
El grupo de módulos como una parte del carrusel de objetos DSM-CC es notificado por el DownloadInfoIndication
(DII). Todos los mensajes DII que muestran la existencia del carrusel de objetos no pueden ser listados en
localización uno por uno.
Es necesario hacer todos los mensajes DII disponibles en orden para encontrar los módulos correspondientes a
los rótulos para hacer el pre-fetch (ver 12.17.10). El descriptor de localización DII lista la localización de estos DII.
En el caso de que el descriptor de localización DII no estuviera incluido, solamente los módulos de indicación DII
que incluyen el ServiceGateway serían encontrados.
Los enlaces de la identificación DII en el descriptor están localizados en orden de importancia. Es decir, DII que
tiene alta prioridad de pre-fetch será localizado en el comienzo del enlace. El receptor montado con mecanismos
de módulos-base de pre-fetch verifica el DII en el orden listado en el descriptor de localización de DII (ver Tabla 63).
Tabla 63 — Estructura del descriptor de localización de DII
Estructura de datos
DII_location_descriptor () {
descriptor_tag
descriptor_length
transport_protocol_label
for ( i=0; i<N ; i++ ) {
reserved_future_use
DII_identification
association_tag
Tasa de
bits
String de
bits
8
8
8
uimsbf
uimsbf
uimsbf
1
15
bslbf
uimsbf
16
uimsbf
}
}
© ABNT 2007 - Todos los derechos reservados
61
ABNT NBR 15606-3:2007
La descripción del DII_location_descriptor () debe ser la siguiente:
⎯ descriptor_tag (descriptor de tag): campo de 8 bits que almacena 0x0D que indica que éste es el
DII_location_descriptor
⎯ transport_protocol_label (rótulo de protocolo de transporte): campo de 8 bits que almacena el rótulo del
protocolo de transporte que especifica el carrusel de objetos que es transmisor del descriptor de pre-fetch
modulesreferredin. Para detalles del rótulo del protocolo de transporte, ver 12.17.6;
⎯ DII_identification (identificación DII): campo de 15 bits que almacena el valor que especifica el DIImessage.
Este valor corresponde al bit 1-15 de la transacción ID en el dsmMessageHeader() del DII message;
⎯ association_tag (asociación de la tag): campo de 16 bits que indica la relación con DII message que se
transmite (por ejemplo, el stream elemental).
12.18
12.18.1
Descriptores de la aplicación Ginga-J
Estructura del descriptor de aplicaciones Ginga
Un descriptor es almacenado en el enlace del descriptor de la información de la aplicación AIT para cada
aplicación Ginga-J. Esto indica el parámetro de información para el inicio de la aplicación (ver Tabla 64).
Tabla 64 — Estructura del descriptor de la aplicación Ginga
Estructura de datos
Tasa de bits
String de bits
8
8
uimsbf
uimsbf
8
uimsbf
8
uimsbf
ginga_j_application_descriptor () {
descriptor_tag
descriptor_length
for ( i=0; i<N ; i++ ) {
parameter_length
for ( j=0; j<parameter_length ; j++ ) {
parameter_byte
}
}
}
La descripción del ginga_j_application_descriptor () debe ser la siguiente:
⎯ descriptor_tag (descriptor de tag): campo de 8 bits donde 0x03 es almacenado para indicar el descriptor de
aplicación Ginga-J y 0x06 es almacenado para indicar en el respectivo descriptor de aplicación Ginga-NCL;
⎯ parameter_length (longitud del parámetro): campo de 8 bits que muestra la longitud de bytes de la
descripción de parámetro subsiguiente;
⎯ parameter_byte (descripción de parámetro): campo de 8 bits. La string a ser dada a la aplicación como
parámetro es almacenada.
12.18.2
Descriptor de la localización de la aplicación Ginga
El descriptor es almacenado en el enlace del descriptor de la información de la aplicación AIT por una de cada
aplicación Ginga-J. Ésta almacena la información de camino necesaria en la aplicación (ver Tabla 65).
62
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-3:2007
Tabla 65 — Estructura del descriptor de aplicación de localización Ginga
Estructura de datos
Tasa de bits
String de bits
8
8
8
uimsbf
uimsbf
uimsbf
8
uimsbf
8
uimsbf
8
uimsbf
8
uimsbf
ginga_j_application_location_descriptor () {
descriptor_tag
descriptor_length
base_directory_length
for ( i=0; i<N ; i++ ) {
base_directory_byte
}
classpath_extension_length
for ( i=0; i<N ; i++ ) {
classpath_extension_byte
}
for ( i=0; i<N ; i++ ) {
initial_class_byte
}
}
La descripción del ginga_j_application_location_descriptor () debe ser la siguiente:
⎯ descriptor_tag (descriptor de tag): Campo de 8 bits donde 0x04 es almacenado para indicar descriptor de
localización de aplicación Ginga-J y 0x07 es almacenado para indicar en el respectivo descriptor de aplicación
Ginga-NCL;
⎯ base_directory_length (longitud del directorio base): Campo de 8 bits que indica la longitud de los bytes a
ser incluidos en los enlaces subsiguientes. El valor almacenado será 1 o mayor;
⎯ base_directory_byte (byte del directorio base): Campo de 8 bits. El nombre del directorio del camino del
archivo del sistema debe ser almacenado por una letra delimitadora, usando “/” (0x2F). Este nombre de
directorio es usado por el directorio-base en el camino relativo. Si el directorio de camino del archivo del
sistema es designado conforme un directorio-base, “/” debe ser almacenado;
⎯ classpath_extension_length (longitud adicional del camino de clase): Campo de 8 bits que indica la longitud
del byte del camino de clase adicional subsiguiente;
⎯ classpath_extension_byte (camino de clase adicional): Campo de 8 bits. Cuando un camino de clase es
designado por un directorio distinto al directorio-base, el nombre del camino de clase es almacenamiento.
El nombre del directorio del camino del archivo del sistema es almacenado por la letra delimitadora usando “/”
(0x2F). Si hay más de un camino, deben ser almacenados por enumeración con “;” (0x3B);
⎯ initial_class_byte (clase de activación inicial): campo con 8 bits. El nombre del objeto en el archivo del
sistema de la interfaz de clase montada Xlet es almacenada.
13 Especificación de la transmisión del mensaje del evento
13.1 Mensaje de evento
La especificación de la transmisión del mensaje del evento provee un medio para enviar mensajes de información
inmediatamente o en horas específicas para una aplicación operada en una unidad de receptor de una estación de
difusión.
© ABNT 2007 - Todos los derechos reservados
63
ABNT NBR 15606-3:2007
La especificación de la transmisión del mensaje del evento definido en esta Norma es extendida para negociar los
distintos tiempos apuntando métodos por la aplicación con base en la especificación del descriptor de stream y su
especificación de la transmisión de sección DSM-CC especificada en la ISO/IEC 13818-6.
13.2 Descriptores de stream
13.2.1 Descriptor de stream DSM-CC
Esta sección está de acuerdo con los requisitos de la ISO/IEC 13818-6.
Los descriptores de stream se pueden usar para proveer información DSM-CC que está correlacionada con un
transport stream o program stream MPEG-2. Estos descriptores están en formato de programas y elementos de
programas descriptores conforme definido en ISO/IEC 13818-1. Los descriptores de stream DSM-CC deben ser
solamente cargados en una DSMCC_section (ver a ISO/IEC 13818-6:1998, Sección 9). Esto crea un espacio
identificador único (de aquel definido por ISO/IEC 13818-1) para valores de descriptor de tag. El formato general
de todos los descriptores de stream definidos en esta especificación está mostrado en la Tabla 66.
Tabla 66 — Descriptor de stream DSM-CC
Sintaxis
Número de bits
Mnemónico
8
8
uimsbf
uimsbf
dsmccStreamDescriptor () {
descriptorTag
descriptorLength
descriptor()
}
La descripción del dsmccStreamDescriptor () debe ser la siguiente:
⎯ descriptorTag: campo de 8 bits que identifica cada descriptor. La extensión de posibles valores para el
descriptorTag se muestra en la Tabla 67;
⎯ descriptorLength: éste es un campo de 8 bits que especifica el número de bytes del descriptor
inmediatamente después del campo descriptorLength.
Tabla 67 — Valor del campo DescriptorTag
Descriptor de tag
Descripción
0x00
0x01
0x02
ISO/IEC 13818-6 reservado
Descriptor de referencia NPT
Descriptor de endpoint NPT
0x03
Descriptor de modo stream
0x04
Descriptor de evento de stream
0x05 – 0xFF
ISO/IEC 13818-6 reservado
13.2.2 Descriptor de referencia NPT
Para activar la determinación de tiempo del NPT de un evento, se define el descriptor de referencia NPT. El formato del
descriptor de referencia se muestra en la Tabla 68.
64
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-3:2007
Tabla 68 — Descriptor de referencia NPT
Sintaxis
Número de bits
Mnemónico
8
8
1
7
7
33
uimsbf
uimsbf
bslbf
uimsbf
bslbf
uimsbf
reserved
NPT_Reference
31
33
bslbf
tcimbsf
scaleNumerator
16
tcimbsf
scaleDenominator
16
tcimbsf
NPTReferenceDescriptor () {
descriptor_tag
descriptor_length
postDescontinuityIndicator
dsm_contentId
Reserved
STC_Reference
}
La descripción del NPTReferenceDescriptor () debe ser la siguiente:
⎯ descriptorTag: campo de 8 bits que identifica el tipo del descriptor de stream. El valor del campo
descriptorTag para el descriptor de referencia NPT se muestra en la Tabla 62;
⎯ descriptorLength: campo de 8 bits que especifica el número de bytes del descriptor inmediatamente
después del campo descriptorLength;
⎯ postDiscontinuityIndicator: campo de 1 bit. Un valor de 0 indica que el descriptor de referencia NPT es
válido en la recepción. Un valor de 1 indica que el descriptor de referencia NPT torna válido en el próximo
tiempo la base de discontinuidad del sistema, conforme definido en la ISO/IEC 13818-1;
⎯ dsm_contentId: campo de 7 bits que identifica que un conjunto anidado de contenido está siendo presentado.
El campo satisfecho se puede usar para indicar la transición para una base de tiempo diferente NPT dentro de
una base de tiempo existente NPT. Por ejemplo, este campo puede ser cambiado cuando un comercial es
presentado dentro de un programa de televisión y después nuevamente cambiado cuando el programa de
televisión es reiniciado;
⎯ STC_Reference: entero sin signo de 33 bits, que indica el valor de STC para el cual NPT iguala el campo
NPT_Reference. El valor del campo STC_Reference se especifica en unidades de períodos del sistema de
frecuencia de reloj, conforme definido en la ISO/I EC 13818-1, dividido entre 300, rindiendo unidades de
90 kHz. STC_Reference es derivado de un sistema de frecuencia de reloj, según mostrado en la ecuación
siguiente:
STC_Referencek = (STCNPT(k) / 300) % 233
donde
STCNPT(k) es el valor del sistema de tiempo del reloj “System Time Clock” cuando el NPT iguala el valor de
NPT_Reference;
⎯ NPT_Reference: entero con signo de 33 bits indicando el valor de NPT en el valor dado de STC en el campo
STC_Reference field;
© ABNT 2007 - Todos los derechos reservados
65
ABNT NBR 15606-3:2007
⎯ scaleNumerator: entero con signo de 16 bits usado con el scaleNumerator, un entero sin signo de 16 bits,
para definir la extensión del cambio de NPT con relación al STC. Un valor de 1 para scaleNumerator con un
valor de 1 para scaleDenominator indica que el NPT está cambiando en una tasa equivalente al STC,
rindiendo la tasa estándar de la presentación. Un valor de 0 para scaleNumerator con un valor no cero para
scaleDenominator indica que NPT no está cambiando con relación al STC, rindiendo un valor constante del
NPT. Un valor de 0 para scaleNumerator con un valor de 0 para scaleDenominator indica que los campos
scaleNumerator y scaleDenominator no están provistos en el descriptor de referencia NPT. Un valor no-cero
para scaleNumerator con un valor de 0 para scaleDenominator no será usado (ver Tabla 69).
Tabla 69 — ScaleNumerator
scaleNumerator
scaleDenominator
Semántica
0
0
0
Otro además de 0
Indica que el scaleNumerator y el scaleDenominator no
se usan
NPT continúa el valor constante irrelevante para STC
1
1
NPT y STC avanzan en la misma tasa
Otro además de 0
0
Tal combinación no se debe usar
13.3 Descriptor de modo de stream
El descriptor de modo de stream contiene información sobre el modo de la máquina de estado del stream,
permitiendo que los clientes sincronicen mejor sus acciones con los cambios de estado del stream. El formato del
descriptor de modo del stream se muestra en la Tabla 70.
Tabla 70 — Descriptor de modo de stream
Sintaxis
StreamModeDescriptor () {
descriptorTag
descriptorLength
streamMode
reserved
}
Número de bits
Mnemónico
8
8
8
8
uimsbf
uimsbf
uimsbf
bslbf
La descripción del StreamModeDescriptor () debe ser la siguiente:
⎯ descriptorTag: campo de 8 bits que identifica el tipo del descriptor del stream. El valor del campo
descriptorTag para el descriptor de modo del stream se muestra en la Tabla 65;
⎯ descriptorLength: campo de 8 bits que especifica el número de bytes del descriptor inmediatamente
después del campo descriptorLength;
⎯ streamMode: campo de 8 bits cuyo valor indica el estado actual de la máquina de estado del stream. Los
valores para streamMode se muestran en la Tabla 71. Los estados de la máquina de estado de stream se
definen en la ISO/IEC 13818-6:1998, Sección 5.
66
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-3:2007
Tabla 71 — Valores del campo StreamMode
Descriptor de modo
Descripción
0
1
2
Abierto
Pausa
Transporte
3
Pausa en el transporte
4
Transporte de busca
5
Pausa de transporte de busca
6
Transporte de pausa de la busca
7
8
Fin de stream
Transporte de pre-busca
9
Pausa de transporte de pre-busca
10 - 255
ISO/IEC 13818-6 reservado
13.4 Descriptores de evento de stream
El descriptor de evento de stream contiene información que permite la transmisión de eventos específicos,
conforme definido en la ISO/IEC 13818-6:1998, Sección 5, de modo que puedan ser sincronizados con el stream.
La definición de evento en este contexto no es la misma si el evento está relacionado con NPT. El formato del
descriptor de evento de stream se muestra en la Tabla 72.
Tabla 72 — Descriptor de evento de stream
Sintaxis
StreamEventDescriptor () {
descriptorTag
descriptorLength
eventId
reserved
eventNPT
for(i=0;i<N;i++){
privateDataByte
}
}
Número de bits
Mnemónico
8
8
16
31
33
uimsbf
uimsbf
uimsbf
bslbf
uimsbf
8
uimsbf
La descripción del StreamEventDescriptor () debe ser la siguiente:
⎯ descriptorTag: campo de 8 bits que identifica el tipo del descriptor de stream. El valor del campo descriptorTag
para el descriptor de evento de stream se muestra en la Tabla 72;
⎯ descriptorLength: campo con 8 bits que especifica el número de bytes del descriptor inmediatamente después
del campo descriptorLength;
⎯ eventid: campo de 8 bits cuyo valor es un tipo de evento específico de la aplicación;
⎯ eventNPT: entero sin signo, cuyo valor es el valor de NPT cuando el evento ocurrió, o el valor de NPT cuando
el evento ocurra;
⎯ privateDataByte: campos que permiten la inclusión de datos específicos de aplicación en el descriptor de
eventos de stream.
© ABNT 2007 - Todos los derechos reservados
67
ABNT NBR 15606-3:2007
13.5 Descriptor de evento general
El descriptor de evento general (general_event_descriptor) es un descriptor para comunicar información aplicables
a mensajes de eventos.
La estructura de datos del descriptor de evento general se muestra en la Tabla 73.
Tabla 73 — Descriptor de evento general
Sintaxis
General_event_descriptor () {
descriptor_tag
descriptor_length
event_msg_group_id
reserved_future_use
time_mode
if(time_mode == 0){
reserved_future_use
}
Número de bits
Mnemónico
8
8
12
4
8
uimsbf
uimsbf
uimsbf
bslbf
uimsbf
40
bslbf
40
bslbf
7
33
bslbf
uimsbf
7
36
bslbf
bslbf
8
16
uimsbf
uimsbf
8
uimsbf
else if(time_mode == 0x01 || time_mode == 0x05){
event_msg_MJD_JST_time
}
else if(time_mode == 0x02){
reserved_future_use
event_msg_NPT
}
else if(time_mode == 0x03){
reserved_future_use
event_msg_relative_time
}
event_msg_type
event_msg_id
for(i=0;i<N;i++){
private_data_byte
}
}
La descripción del General_event_descriptor () debe ser la siguiente:
⎯ event_msg_group_id (identificador de grupo de mensaje de evento): campo de 12 bits que identifica el grupo
de mensajes a ser recibidas por el aplicador. Detalles de las operaciones se especifican en cada identificador
de codificación de datos. Cuando está operando un evento de mensaje con la identificación de más de un
grupo de mensajes al mismo tiempo, solamente los descriptores de evento general con el identificador del
mismo grupo de mensajes deben ser incluidos en una sección DSM-CC;
⎯ time_mode (modo de tiempo): campo de 8 bits que indica el método para designar el tiempo cuando un
evento de mensaje es generado (ver Tabla 74);
68
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-3:2007
Tabla 74 — Modo de tiempo
Time_mode
Método de
designación de tiempo
0x00
Ninguno
0x01
mjd_utc_time
0x02
NPT
0x03
eventRelative Time
0x04
---
0x05
MJD_UTC_time
0x06-0xFF
---
Semántica
El mensaje de evento es generado inmediatamente
después de la recepción
El mensaje de evento es generado en el tiempo
absoluto indicado por el tiempo MJD UTC. El mensaje
de evento también es generado cuando el contenido
grabado del stream es reproducido refiriéndose al
tiempo de reproducción
El mensaje de evento es generado en el tiempo
específico con los datos de tiempo NPT
El mensaje de evento es generado cuando el período
se especifica en este campo (en milésimos de
segundo) después del tiempo de inicio del programa
Reservado para el futuro
El mensaje de evento es generado en el tiempo
absoluto indicado por el tiempo MJD UTC. Cuando el
contenido grabado del stream es reproducido, el
mensaje de evento también es generado refiriéndose al
tiempo en el aire
Reservado para el futuro
⎯ event_msg_MJD_UTC_time: campo de 40 bits se codifica en el caso del modo de tiempo = 0 x 01 ó 0x05
e indica el tiempo cuando el evento de mensaje es generado en el UTC y MJD (se refiere a
ARIB STD-B10:2003, Parte 2, Anexo C). Este campo contiene una copia de los 16 bits más bajos de MJD
y es seguido por seis representaciones de 4 bits decimal codificado en binario (BCD);
⎯ event_msg_NPT: campo de 33 bits que se codifica en el caso del modo de tiempo = 0 x 02 e indica el tiempo
usando el Normal Play Time de DSM-CC (ver 7.1), cuando el evento de mensaje es generado;
⎯ event_msg_relativeTime: campo de 36 bits que se codifica en el caso del modo de tiempo = 0 x 03 e indica
que el evento de mensaje es generado cuando el período especificado en este campo pasa después del
horario de inicio del programa. El valor de este campo se describe en el orden de hora (2 dígitos), minuto
(2 dígitos), segundo (2 dígitos) milésimos de segundo (3 dígitos), para formar nueve representaciones de 4 bits
decimales codificados en binario (BCD);
⎯ event_msg_type (tipo de mensaje de evento): un identificador que indica el tipo de mensaje de evento.
El uso y la semántica son especificados en cada especificación de codificación de datos.
⎯ event_msg_id (identificador de mensaje de evento): campo de 16 bits que contiene el identificador para
identificar cada mensaje de evento. El uso y la semántica son especificados en cada especificación de
codificación de datos.
⎯ private_data_byte (datos privados): campo de 8 bits que almacena información relacionada al evento de
mensaje requerido por la especificación de codificación de datos especificado en el event_msg_type.
13.6 Sintaxis de sección de DSM-CC transmitiendo el descriptor de stream
El descriptor de stream se transmite en la sección DSM-CC mostrada en la Tabla 75.
© ABNT 2007 - Todos los derechos reservados
69
ABNT NBR 15606-3:2007
Tabla 75 — Sección DSM-CC (transmisión de descriptor de stream)
Sintaxis
Número de bits
Mnemónico
8
1
1
2
12
4
uimsbf
bslbf
bslbf
bslbf
uimsbf
uimsbf
event_msg_group_id
Reserved
12
2
uimsbf
bslbf
version_number
5
uimsbf
current_next_indicator
section_number
last_section_number
if(table_id == 0x3D){
for(i=0;i<N;i++){
stream_descriptor()
}
}
if(section_syntax_indicator == ‘0’){
Checksum
}
Else{
CRC_32
}
1
8
8
bslbf
uimsbf
uimsbf
32
uimsbf
32
rpchof
DSMCC_section () {
table_id
section_syntax_indicator
private_indicator
Reserved
dsm_cc_section_length
data_event_id
}
La descripción de la DSMCC_section () debe ser la siguiente:
⎯ table_id (tabla de identificación): campo de 8 bits que es regulado para 0x3D, para indicar que el descriptor
de stream está almacenado en el payload de la sección DSM-CC;
⎯ section_syntax_indicator: campo de 1 bit que indica que CRC32 existe al final de la sección cuando es 1.
Cuando es 0, esto indica que existe verificación de suma. Para transmitir un evento de mensaje, este campo
debe ser regulado en 1;
⎯ private_indicator: campo de 1 bit que almacena el valor complementario de la sección de valor indicador de
sintaxis;
⎯ dsmcc_section_length: campo de 12 bits que indica la longitud de byte del área de posición inmediatamente
siguiente a este campo al fin de la sección. Este valor de campo no debe exceder 4 093;
⎯ data_event_id: campo de 4 bits que es el identificador para identificar el evento de datos entre los datos
precedentes y siguientes que usan el evento de mensaje para permitir el contenido local pretendido, a pesar
de ser precedidos y/o seguidos otros contenidos locales, para recibir el evento de mensaje. Contenidos
locales adyacentes, cuando están transmitiendo, son asignados con diferentes identificadores;
70
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-3:2007
⎯ event_msg_group_id (identificador de grupos de mensaje): campo de 12 bits que contiene el campo para
identificar el evento de mensajes a ser recibidos por la aplicación. La semántica detallada se detalla en cada
especificación de codificación de datos;
⎯ version_number: campo de 5 bits que es el número de la versión de la subtabla. El número de versión se
incrementa en 1 cuando cualquier pieza de información en la subtabla sea cambiada. Los valores disponibles
son de 0 a 31. El valor 0 se utiliza para actualizar el 31;
⎯ current_next_indicator: indicador de 1 bit que indica que la subtabla es la actual subtabla cuando es '1'.
Cuando es '0', la subtabla enviada no es aún aplicada y usada como la próxima subtabla;
⎯ section_number: campo de 8 bits que indica el número de la sección;
⎯ last_section_number: campo de 8 bits que indica el número de la última sección (que es la sección con el
número máximo de secciones de la subtabla a la que las secciones participantes pertenecen).
14 Sistema de archivo de difusión y transporte de disparador
El sistema de archivo de difusión y transporte de disparador debe estar de acuerdo con la GEM 1.0:2005, Anexo B.
© ABNT 2007 - Todos los derechos reservados
71
ABNT NBR 15606-3:2007
Anexo A
(normativo)
Video y audio PES
A.1 Formato de transmisión de datos a través de la PES de video MPEG-2 codificado
En el caso del uso de PES de video codificado con el video MPEG-2 (ver ISO/IEC 13818-2) para transmitir datos,
se deberá utilizar el campo de datos del usuario (user_data_area), de conformidad con el encabezamiento de la
pantalla del stream de video. La sintaxis del campo de datos del usuario se muestra en la Tabla A.1. El uso más
detallado de este área depende del modo de operación de las emisoras.
Tabla A.1 — Sintaxis del campo de datos del usuario del stream de video
Sintaxis
Número de bits
Mnemónico
32
bslbf
8
uimsbf
User Data () {
user_data_start_code
while (nextbits() != 0x000001){
user_data
}
next_start_code()
}
NOTA
Código de inicio de datos de usuarios: 0x000001b2.
A.2 Formato de transmisión de datos del audio PES codificado con MPEG-2 BC audio
En la utilización de paquetes PES de audio MPEG-2 BC audio (ver ISO/IEC 13818-3) para transmisión de datos, el
área de datos jerárquicos (ancillary data area), que puede contener otros datos que no sean audio MPEG, se debe
utilizar. La sintaxis del área de datos jerárquicos se muestra en la Tabla A.2 Un uso más detallado de ese área
depende de los operadores de servicio.
Tabla A.2 — Área de datos subordinada al stream de audio
Sintaxis
MPEG1_ancillary_data() {
if(ext_bit_stream_present == 1){
for(b=0; b<8*n_ad_bytes;b++)
ancillary_bit
}
}
72
Número de bits
Mnemónico
1
bslbf
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-3:2007
A.3 Formato de transmisión de datos del audio PES codificado con MPEG-2 AAC audio
En la utilización de paquetes PES de audio MPEG-2 AAC audio (ver ISO/IEC 1381 8-3) para transmisión de datos,
el área data_stream_element se debe usar para permitir que otros datos, además de datos de audio MPEG,
puedan estar contenidos en cada bloque de datos puro (raw_data_block). La sintaxis del área se muestra en la
Tabla A.3. Un uso más detallado de ese área depende de los operadores de servicio.
Tabla A.3 — Área base de datos de stream del audio stream (MPEG-2 AAC audio)
Sintaxis
data_stream_element () {
element_instance_tag
data_byte_align_flag
cnt = count
if(cnt == 255){
cnt += esc_count
}
Número de bits
Mnemónico
4
1
8
8
uimsbf
uimsbf
uimsbf
uimsbf
8
bslbf
if(data_byte_align_flag)
byte_alignment()
for(i=0;i<cnt;i++)
data_stream_byte[element_instance_tag][i]
}
© ABNT 2007 - Todos los derechos reservados
73
ABNT NBR 15606-3:2007
Anexo B
(normativo)
Información PSI/SI para transmisión de carruseles de datos
y mensajes de eventos
B.1 Especificación de la codificación de datos con base en el carrusel de datos y
esquema de evento de mensaje
En adición a la especificación de codificación de datos aplicada, la transmisión de datos con base en el carrusel de
datos y el esquema de evento de mensaje serán definidos; una sintaxis adicional depende del formato de
transmisión de datos a ser insertada en el data_component_descriptor en PMT y data_content_descriptor en EIT
especificados en la ARIB STD-B23.
Esta Norma se basa en las siguientes suposiciones sobre operación de transmisión para servicios de difusión de
datos, de la siguiente manera:
— el DII y DDB pertenecientes a un carrusel se transmiten en un ES;
— un servicio de difusión de datos puede consistir en dos o más carruseles. Eventos de mensajes se pueden
transmitir.
B.2 Contenido
de
enlace
data_component_descriptor
de
additional_data_component_info
y
Para insertar la información para control de recepción del carrusel de datos y el posible evento de mensajes en el
enlace que contiene additional_data_component_info al final de data_component_descriptor, la siguiente
estructura de datos debe ser colocada en el enlace, según determinado por la especificación de codificación de
datos (ver Tabla B.1).
Tabla B.1 – Additional ginga carousel info
Sintaxis
Número de bits
Mnemónico
4
1
3
uimsbf
bslbf
bslbf
additional_ginga_carousel_info() {
data_event_id
event_section_flag
reserved
}
La descripción de la additional_ginga_carousel_info() debe ser la siguiente:
⎯ data_event_id: identificador de 4 bits que reconoce los eventos de datos precedentes y siguientes, usando el
carrusel de datos y mensajes del posible evento para evitar defecto al recibir el contenido local apropiado
transmitido en el carrusel de datos y mensajes de posibles eventos. En el caso de todos los bits de este
campo regulados en 1, eso significa que los DIIs tienen un identificador de data_event_id entregado en este
servicio y el evento de mensajes es válido;
74
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-3:2007
⎯ event_section_flag: campo de 1 bit indica si un evento de mensajes fue o no enviado con este componente,
de la siguiente manera:
0: mensajes del evento no fueron transmitidos;
1: mensajes del evento fueron transmitidos;
⎯ reserved: reservado.
B.3 Byte selector de data_contents_descriptor
B.3.1 Data structure
Para insertar información para control de recepción de carrusel de datos en el byte selector de descriptor de
contenidos de datos como EIT, una estructura de datos debe ser colocada en el campo selector_byte, según
determinado por la especificación de codificación de datos participante.
B.3.2 Estructura de datos para control de recepción de carrusel de datos para servicios de
datos no almacenados
Para servicios de datos no almacenados, insertar las informaciones contenidas en la Tabla B.2.
Tabla B.2 — Servicios de datos no almacenados
Sintaxis
Número de bits
Mnemónico
ginga_carousel_info () {
num_of_carousels
for(i=0;i<num_of_carrousels;i++){
component_tag
event_section_flag
reserved_future_use
component_size_flag
8
uimsbf
8
1
3
1
uimsbf
bslbf
bslbf
bslbf
default_transaction_id_flag
default_timeout_DII_flag
1
1
bslbf
bslbf
default_leak_rate_flag
1
bslbf
32
uimsbf
32
uimsbf
22
2
uimsbf
bslbf
if(component_size_flag == ‘1’){
component_size
}
if(default_transaction_id_flag == ‘1’){
timeout_value_DII
}
if(default_leak_rate_flag == ‘1’){
leak_rate
reserved
}
}
}
© ABNT 2007 - Todos los derechos reservados
75
ABNT NBR 15606-3:2007
La descripción de la ginga_carousel_info() debe ser la siguiente:
⎯ num_of carousels: campo de 8 bits que indica el número de carruseles, incluidos en el enlace siguiente;
⎯ component_tag: campo de 8 bits que designa el componente del stream transmitiendo los carruseles con el
componente de tag dado por el descriptor identificador de stream en el PMT;
⎯ event_section_flag: campo que indica si el evento de mensajes fue o no enviado usando este componente;
⎯ component_size_flag: campo de 1 bit que indica si la estructura de datos contiene o no el componente de
tamaño. Cuando el valor del campo component_size no está disponible, debe ser regulado a “0”:
0: no codificado;
1: codificado;
⎯ default_transaction_id_flag: campo de 1 bit que indica si el identificador de transacción está codificado o no
en esta sintaxis. Para designación de manera que se obtenga todo de la identificación de transacción opcional,
la identificación de transacción no debe ser codificada (0: no codificado; 1: codificado);
⎯ default_timeout DII_flag: campo de 1 bit que indica si el valor de explosión de tiempo de DII está codificado
en esta sintaxis. Cuando el valor estándar especificado en esta operación como valor de explosión de DII se
utiliza, no está codificado (0: no codificado; 1: codificado);
⎯ default_leak_rate_flag: campo de 1 bit que indica si la tasa de dispersión está codificada o no en esta
sintaxis. Cuando el valor estándar especificado en esta operación como valor de dispersión de DII se utiliza,
no está codificado (0: no codificado; 1: codificado);
⎯ component_size: campo de 32 bits que indica el tamaño total (en bytes) de los datos transmitidos en los
carruseles de este componente;
⎯ transaction_id: identificación del valor de la transacción DII transmitida en este componente. En el caso de
que la identificación de transacción no esté presente, debe obtenerse una DII con la identificación de
transacción;
⎯ time_out_value_DII: campo de 32 bits que indica el valor de intervalo recomendado (en milésimas de
segundo) para recibir la sección completa de DII de este carrusel. Cuando el valor es 0 x FFFFFFFF, eso
significa que no existe valor de intervalo recomendado;
⎯ leak_rate: campo de 22 bits que indica la tasa de dispersión del transporte de buffer de la unidad del receptor
en una unidad de 50 bytes/s.
B.3.3 Estructura de datos para el control de la recepción del carrusel de datos para el servicio
de datos almacenados
Para el servicio de datos almacenados, insertar las informaciones contenidas en la Tabla B.3.
76
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-3:2007
Tabla B.3 — Servicio de datos almacenados
Sintaxis
Número de bits
Mnemónico
8
uimsbf
8
1
1
1
uimsbf
bslbf
bslbf
bslbf
compressed_component_size_flag
component_size_flag
1
1
bslbf
bslbf
default_transaction_id_flag
1
bslbf
default_timeout_DII_flag
default_leak_rate_flag
if(num_dataEvent_flag == ‘1’){
num_dataEvent
}
if(num_modules_flag == ‘1’){
num_modules
}
if(num_resources_flag == ‘1’){
num_resources
}
if(compressed_component_size_flag == ‘1’){
compressed_component_size
1
1
bslbf
bslbf
16
uimsbf
32
uimsbf
32
uimsbf
32
uimsbf
ginga_stored_carousel_info () {
num_of_carousels
for(i=0;i<num_of_carrousels;i++){
component_tag
num_dataEvent_flag
num_modules_flag
num_resources_flag
}
}
La descripción de la ginga_stored_carousel_info () debe ser la siguiente:
⎯ num_of carousels: campo de 8 bits que indica el número de carruseles incluyendo el del enlace siguiente;
⎯ component_tag: campo de 8 bits que designa el componente de stream transmitiendo los carruseles con el
componente de la tag dado por el descriptor identificador de stream en PMT;
⎯ num_dataEvent_flag: campo de 1 bit indica si la estructura de datos contiene o no un número de eventos de
datos. Cuando el valor del campo num_dataEvent no está disponible, debe ser regulado a 0 (0: no codificado;
1: codificado);
⎯ num_modules_flag: campo de 1 bit que indica si la estructura de datos contiene o no un número total de
módulos. Cuando el valor del campo num_modules no está disponible, debe ser regulado a 0 (0: no
codificado; 1: codificado);
⎯ num_resources_flag: campo de 1 bit que indica si la estructura de datos contiene o no un número total de
recursos. Cuando el valor del campo num_resources no está disponible, debe ser regulado a 0 (0: no
codificado; 1: codificado);
⎯ compressed_component_size_flag: campo de 1 bit que indica si la estructura de datos contiene o no el
tamaño comprimido del componente. Cuando el valor del campo compressed_component_size no está
disponible, debe ser regulado a 0 (0: no codificado; 1: codificado);
© ABNT 2007 - Todos los derechos reservados
77
ABNT NBR 15606-3:2007
⎯ component_size_flag: campo de 1 bit que indica si la estructura de datos contiene o no el tamaño del
componente. Cuando el valor del campo component_size no está disponible, debe ser regulado a 0 (0: no
codificado; 1: codificado);
⎯ default_transaction_id_flag: campo de 1 bit que indica si el identificador de la transacción está codificada o
no en la sintaxis. Para designar la ganancia de DII de identificación de transacción opcional, la identificación
de la transacción no debe estar codificada (0: no codificado; 1: codificado);
⎯ default_timeout DII_flag: campo de 1 bit que indica si el valor de intervalo está o no codificado en la sintaxis.
Cuando el valor básico especificado en la operación conforme el valor de intervalo DII se utiliza, no se codifica
(0: no codificado; 1: codificado);
⎯ default_leak_rate_flag: campo de 1 bit que indica si la tasa de dispersión está o no codificada en la sintaxis.
Cuando el valor básico especificado en la operación como el valor de la tasa de dispersión se utiliza, no se
codifica (0: no codificado; 1: codificado);
⎯ num_dataEvent: campo de 32 bits que indica el número total de eventos de datos en el componente
participante;
⎯ num_modules: campo de 32 bits que indica el número total de módulos en los eventos de datos en el
componente participante;
⎯ num_resources: campo de 32 bits que indica el número total de recursos en los eventos de datos en el
componente participante;
⎯ compressed_component_size: campo de 32 bits que indica el tamaño total (en bytes) de los datos en los
eventos de datos en los carruseles de datos de este componente. El tamaño del módulo comprimido es
calculado con base en el estado comprimido, no en el estado expandido;
⎯ component_size: campo de 32 bits que indica el tamaño total (en bytes) de los datos en los eventos de datos
en los carruseles de datos de este componente. El tamaño del módulo comprimido es calculado con base en
el estado extraído, no en el estado comprimido;
⎯ transaction_id: transacción de identificación del valor DII transmitido en este componente. En el caso de la
identificación de la transacción no estar definida, debe obtenerse la DII con la identificación de la transacción;
⎯ time_out_value_DII: campo de 32 bits que indica el valor de intervalo recomendado (en milésimas de
segundos) para recibir la sección completa de DII en este carrusel. Cuando el valor sea 0xFFFFFFFF, ello
significa que no existe valor de intervalo recomendado;
⎯ leak_rate: campo de 22 bits que indica la tasa de dispersión del transporte de buffer de la unidad del receptor
en una unidad de 50 byte/s.
78
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-3:2007
Anexo C
(informativo)
Relación entre el descriptor PMT/EIT y AIT
La Figura C.1 muestra la relación de AIT para el descriptor componente de datos PMT y el descriptor de
contenidos de datos EIT en Ginga.
Los ítems de extensión para Ginga son los siguientes:
⎯ nueva atribución para la identificación de valor a ser usado en Ginga (por ejemplo, componentes de datos ID,
transport_id, application_id);
⎯ para el componente ES que transmite la aplicación Ginga o para el componente ES que transmite AIT,
las áreas del selector son especificadas para los descriptores de componentes de datos que almacenan
información adicional a no ser transmitida a través de AIT;
⎯ las áreas de selector son especificadas para los descriptores de contenidos de datos en orden para
almacenar los detalles de la aplicación Ginga en la base del evento del programa;
⎯ en un descriptor, es regulada application_identifier_flag en vez de entry_point_flag en orden para almacenar
información especificando una aplicación que es un punto de entrada en PMT/EIT.
Las informaciones adicionales son para las áreas del selector de los descriptores de componentes de datos, así
como descriptores de contenidos de datos relevantes para transmisión Ginga y AIT. El resto está supuesto para
estar de conformidad con la transmisión AIT bajo MHP1.0.
Para el carrusel de datos que no transmite aplicación Ginga, es posible referir a los contenidos especificando el
asignador de la aplicación Ginga.
© ABNT 2007 - Todos los derechos reservados
79
ABNT NBR 15606-3:2007
Figura C.1 — Relación de a transmisión AIT y descriptor de componente de datos
80
© ABNT 2007 - Todos los derechos reservados
ABNT NBR 15606-3:2007
Anexo D
(informativo)
Informaciones adicionales sobre trasmisiones utilizando independientes
PES
Un data_identifier debe estar presente en el inicio de PES_packet_data_byte para identificar el tipo de datos. (ver
EN 301 192, ATSC DVS 161 y DAVIC 1.4:1998, parte 9).
NOTA
la PMT.
En Japón, el Ministerio de Telecomunicaciones (Notification Hei 10/260) estipula el uso de data_component_id en
Para asegurar la conformidad DVB, ATSC y DAVIC, el campo data_identifier contiene una copia del valor
asignado para el área del usuario definido en esos estándares.
Las razones para emplear las especificaciones independientes PES como un estándar para el método de
transmisión PES son las siguientes:
⎯ tamaño (menor de restricciones) permite una libertad mayor;
⎯ se permite que datos de video y audio sean producidos por separado antes de ser multiplexados por menos
esfuerzo;
⎯ es permitido compartir datos en múltiples piezas de datos de video y audio para un acceso más fácil.
La transmisión de carrusel de datos se basa en el download U-N (carrusel de datos DSM-CC) estipulado en la
ISO/IEC 13818-6, en el cual fue agregado lo siguiente:
⎯ con relación al área de datos del módulo, asumiendo su uso para la transmisión de archivos etc., fueron
agregados los descriptores de Activation time, de Expire y de Compression Type.
excepto por los servicios de download asumidos cuando el original ISO/IEC 13818-6 fue desarrollado, estas
estipulaciones permiten el uso de las transmisiones del carrusel de datos que son eficientes y que tienen la
recepción mínima procesando cargas en una amplia variedad de aplicaciones, como servicios de multimedia.
© ABNT 2007 - Todos los derechos reservados
81
ABNT NBR 15606-3:2007
Bibliografia
[1]
ITU-T X.208: 1988, Specification of abstraction construction describing format (ASN. 1)
[2]
ITU-T X.209: 1988, Specification of basic encryption rule of abstraction construction describing format
(ASN.1)
[3]
ITU-T X.234: 1994, Encryption key management and authenticating system for audio visual service
[4]
ITU-T X.509: 1997, Directory – Frame of authentication
[5]
JIS X 5055:1996, Security technology – Data completeness function using encryption inspection function by
block encryption algorithm
[6]
JIS X 5056-3:1996, Security technology – Entity authentication function – Part 3: Authentication function
using open key algorithm
[7]
JIS X 5057-1:1996, Security technology – Hash function – Part 1: Introduction
[8]
JIS X 5057-2:1996, Security technology – Hash function – Part 2: Hush function using n bitblock encryption
algorithm
[9]
JIS X 5060:1994, Data encryption technology – Registration procedure of encryption algorithm
[10] http://www.nist.gov/aes (1999-3) “Advanced Encryption Standard”
[11] FIPS PUB 46-2:1993, http://www.itl.nist.gov/div897/pubs/fip46-2.htm – Data encryption standard (DES)
[12] RC5, RFC2040:1996, The RC5 Encryption algorithm
[13]
FIPS PU B 140-1:1994, http://www-09.nist.gov/div897/pubs/fip140-1 .htm, Security requirements for
cryptographic modules
[14]
FIPS PU B 180-1:1995, http://www.itl.nist.gov/div897/pubs/fip180-1 .htm, Secure hash standard
[15]
MD5, RFC1321:1992, The MD5 Message-Digest Algorithm
[16]
MD2, RFC1319:1992, The MD2 Message-Digest Algorithm
[17]
RFC 2246:1999, The TLS Protocol Version 1.0
[18]
RFC 1590:1994, J.Postel, Media Type Registration Procedure, RFC 1590, ISI
[19]
The Notification No. 260 of Ministry of Posts and Telecommunications in 1998 – JAPAN
[20]
RFC 1877:1995, PPP Internet Protocol Control Protocol Extensions for Name Server Addresses
[21]
RFC 1954:1996, Transmission of Flow Labelled IPv4 on ATM Data Links Ipsilon Version 1.0
[22]
RFC 768:1980, User Datagram Protocol
[23]
RFC 1334: 1992, PPP Authentication Protocols
[24]
RFC 1332: 1992, The PPP Internet Protocol Control Protocol (IPCP)
[25]
RFC 1034:1987, Domain names - concepts and facilities
[26]
RFC 1035:1987, Domain names - implementation and specification
82
© ABNT 2007 - Todos los derechos reservados
NORMA
BRASILEÑA
ABNT NBR
15606-5
Primera edición
05.03.2008
Válida a partir de
05.04.2008
Versión corregida
18.06.2009
Televisión digital terrestre — Codificación de
datos y especificaciones de transmisión para
radiodifusión digital
Parte 5: Ginga-NCL para receptores portátiles –
Lenguaje de aplicación XML para codificación
de aplicaciones
Palabras clave: Televisión digital terrestre. Middleware. Ginga. NCL. Receptores
portátiles. Perfil one-seg.
ICS 33.160.01
ISBN 978-85-07-00917-7
Número de referencia
ABNT NBR 15606-5:2008
118 páginas
© ABNT 2008
ABNT NBR 15606-5:2008
© ABNT 2008
Todos los derechos reservados. A menos que se especifique de otro modo, ninguna parte de esta publicación puede ser
reproducida o utilizada por cualquier medio, electrónico o mecánico, incluyendo fotocopia y microfilm, sin permiso por escrito de
la ABNT.
ABNT
Av.Treze de Maio, 13 - 28º andar
20031-901 - Rio de Janeiro - RJ
Tel.: + 55 21 3974-2300
Fax: + 55 21 2220-1762
abnt@abnt.org.br
www.abnt.org.br
Impresso en Brasil
ii
© ABNT 2008 - Todos los derechos reservados
ABNT NBR 15606-5:2008
Índice
Página
Prefacio........................................................................................................................................................................v
Introducción ...............................................................................................................................................................iv
1
Alcance ...........................................................................................................................................................1
2
Referencias normativas ................................................................................................................................1
3
Términos y definiciones................................................................................................................................1
4
Abreviaturas...................................................................................................................................................7
5
5.1
5.2
Arquitectura Ginga ........................................................................................................................................8
Ginga main modules .....................................................................................................................................8
Interacción con el ambiente nativo..............................................................................................................9
6
6.1
6.2
6.3
6.3.1
6.3.2
Objetos XHTML incorporados en presentaciones NCL.............................................................................9
NCL como lenguaje cola ...............................................................................................................................9
Formato de contenido XHTML ...................................................................................................................10
XHTML para el perfil portátil.......................................................................................................................10
Marcaciones XML ........................................................................................................................................10
Hojas de estilo .............................................................................................................................................15
7
7.1
7.1.1
7.1.2
7.1.3
7.2
7.3
7.3.1
7.3.2
7.3.3
7.3.4
7.3.5
NCL - Lenguaje declarativo XML para especificación de presentaciones multimedia interactivas ...19
Lenguajes modulares y perfiles de lenguajes..........................................................................................19
Módulos NCL................................................................................................................................................19
Identificadores para módulos y perfiles de lenguaje de la NCL 3.0.......................................................22
Informaciones sobre versiones de NCL....................................................................................................24
Módulos NCL................................................................................................................................................24
Perfiles del lenguaje NCL para el SBTVD..................................................................................................24
Módulos de perfiles .....................................................................................................................................24
Esquema del perfil NCL 3.0 DTV avanzado...............................................................................................24
Esquema do perfil NCL 3.0 CausalConnector ..........................................................................................34
Atributos y elementos del perfil NCL 3.0 DTV básico..............................................................................34
Esquema del perfil NCL 3.0 DTV Básico ...................................................................................................37
8
8.1
8.2
8.3
8.5
Objetos de media en presentaciones NCL................................................................................................45
Implementación modular de Ginga-NCL ...................................................................................................45
Comportamiento esperado de los exhibidores de media .......................................................................46
Comportamiento esperado de los exhibidores de media después de instrucciones aplicadas a los
objetos de composición..............................................................................................................................46
Relación entre la máquina de estado de eventos de presentación de un nudo y la máquina de
estado del evento de presentación de su nudo de composición padre................................................46
Comportamiento esperado de los exhibidores procedurales Lua.........................................................46
9
Transmisión de contenido y eventos de flujo NCL..................................................................................48
10
10.1
10.2
10.3
10.3.1
10.3.2
10.3.3
10.3.4
10.3.5
Objetos procedurales Lua en presentaciones NCL .................................................................................48
Lenguaje Lua - Funciones retiradas de la biblioteca Lua .......................................................................48
Modelo de ejecución ...................................................................................................................................49
Módulos adicionales ...................................................................................................................................49
Módulos obligatorios ..................................................................................................................................49
Módulo canvas.............................................................................................................................................49
Módulo event................................................................................................................................................61
Módulo settings ...........................................................................................................................................74
Módulo persistent........................................................................................................................................74
11
Objetos procedurales Java en documentos NCL ....................................................................................75
12
Requisitos de codificación de media y métodos de transmisión instados en documentos NCL ......77
8.4
© ABNT 2008 - Todos los derechos reservados
iii
ABNT NBR 15602-2:2007
13
Seguridad .....................................................................................................................................................77
Anexo A (normativo) Esquemas de los módulos NCL 3.0 que se utilizan en los perfiles TVD Básico y TVD
Avanzado......................................................................................................................................................78
A.1
Módulo Structure: NCL30Structure.xsd ....................................................................................................78
A.2
Módulo Layout: NCL30Layout.xsd ............................................................................................................79
A.3
Módulo Media: NCL30Media.xsd................................................................................................................80
A.4
Módulo Context: NCL30Context.xsd .........................................................................................................81
A.5
Módulo MediaContentAnchor: NCL30MediaContentAnchor.xsd ...........................................................82
A.6
Módulo CompositeNodeInterface: NC30CompositeNodeInterface.xsd.................................................84
A.7
Módulo PropertyAnchor: NCL30PropertyAnchor.xsd .............................................................................85
A.8
Módulo SwitchInterface: NCL30SwitchInterface.xsd...............................................................................86
A.9
Módulo Descriptor: NCL30Descriptor.xsd ................................................................................................87
A.10 Módulo Linking: NCL30Linking.xsd ..........................................................................................................89
A.11 Módulo ConnectorCommonPart: NCL30ConnectorCommonPart.xsd ..................................................90
A.12 Módulo ConnectorAssessmentExpression: NCL30ConnectorAssessmentExpression.xsd .............91
A.13 Módulo ConnectorCausalExpression: NCL30ConnectorCausalExpression.xsd .................................93
A.14 Módulo CausalConnector: NCL30CausalConnector.xsd ........................................................................96
A.15 Módulo ConnectorBase: NCL30ConnectorBase.xsd...............................................................................97
A.16 NCL30CausalConnectorFunctionality.xsd................................................................................................98
A.17 Módulo TestRule: NCL30TestRule.xsd....................................................................................................101
A.18 Módulo TestRuleUse: NCL30TestRuleUse.xsd ......................................................................................103
A.19 Módulo ContentControl: NCL30ContentControl.xsd .............................................................................104
A.20 Módulo DescriptorControl: NCL30DescriptorControl.xsd ....................................................................105
A.21 Módulo Timing: NCL30Timing.xsd ..........................................................................................................106
A.22 Módulo Import: NCL30Import.xsd............................................................................................................107
A.23 Módulo EntityReuse: NCL30EntityReuse.xsd ........................................................................................108
A.24 Módulo ExtendedEntityReuse: NCL30ExtendedEntityReuse.xsd........................................................109
A.25 Módulo KeyNavigation: NCL30KeyNavigation.xsd................................................................................110
A.26 Módulo TransitionBase: NCL30TransitionBase.xsd..............................................................................111
A.27 Módulo Animation: NCL30Animation.xsd...............................................................................................112
Bibliografía ..............................................................................................................................................................118
iv
© ABNT 2008 - Todos os direitos reservados
ABNT NBR 15606-5:2008
Prefacio
La Associação Brasileira de Normas Técnicas (ABNT) es el Fórum Nacional de Normalización. Las Normas
Brasileñas, cuyo contenido es responsabilidad de los Comités Brasileños (ABNT/CB), de los Organismos de
Normalización Sectorial (ABNT/ONS) y de las Comisiones de Estudios Especiales (ABNT/CEE), son elaboradas
por Comisiones de Estudio (CE), formadas por representantes de sus sectores implicados de los que forman
parte: productores, consumidores y neutrales (universidades, laboratorios y otros).
Los Documentos Técnicos ABNT se elaboran de acuerdo con las reglas de Directivas ABNT, Parte 2.
La Associação Brasileira de Normas Técnicas (ABNT) llama la atención sobre la posibilidad de que algunos de los
elementos de este documento pueden ser objeto de derechos de patente. La ABNT no debe ser considerada
responsable por la identificación de cualesquiera derechos de patente.
La ABNT NBR 15606-5 fue elaborada por la Comisión de Estudio Especial de Televisión Digital
(ABNT/CEE-00:001.85). El Proyecto circuló en Consulta Nacional según Edicto nº 12, de 13.12.2007 a 11.02.2008,
con el número de Proyecto 00:001.85-006/5.
En caso que surja cualquier duda con relación a la interpretación de la versión en español siempre deben
prevalecer las prescripciones de la versión en portugués
Esta Norma está basada en los trabajos del Fórum del Sistema Brasileiro de Televisão Digital Terrestre, según
establece el Decreto Presidencial nº 5.820, de 29/06/2006.
La ABNT NBR 15606, bajo el título general “Televisión digital terrestre – Codificación de datos y especificaciones
de transmisión para radiodifusión digital”, está previsto que contenga las siguientes partes:
 Parte 1: Codificación de datos;
 Parte 2: Ginga-NCL para receptores fijos y móviles – Lenguaje de aplicación XML para codificación de
aplicaciones;
 Parte 3: Especificación de transmisión de datos;
 Parte 4: Ginga-J – Ambiente para la ejecución de aplicaciones procedurales;
 Parte 5: Ginga-NCL para receptores portátiles – Lenguaje de aplicación XML para codificación de aplicaciones.
Esta versión en español es equivalente a la versión corregida 2 de la ABNT NBR 15606-5:2008, de 14.04.2009.
Esta versión corregida de la ABNT NBR 15606-5:2008 incorpora la Errata 1 de 18.06.2009.
© ABNT 2008 - Todos los derechos reservados
v
ABNT NBR 15606-5:2008
Introducción
La Associação Brasileira de Normas Técnicas (ABNT) llama la atención para el hecho de que la exigencia de
conformidad con este documento ABNT puede involucrar el uso de una patente relacionada a NCL, tal como
mencionado en 5.1.
La ABNT no toma posición con respecto a evidencias, validez y alcance de estos derechos de patente.
El propietario de este derecho de patente aseguró a ABNT que él está preparado para negociar licencias sobre
términos y condiciones razonables y no discriminatorias con los solicitantes. Sobre esto, una declaración del
propietario de esta patente está registrada en ABNT. Informaciones se pueden obtener en:
Pontificia Universidad Católica de Río de Janeiro, Departamento de Transferencia de Tecnología
Rua Marquês de São Vicente, 225 – Gávea, 22451-900 - Rio de Janeiro - RJ - Brasil.
ABNT llama la atención para la posibilidad de que algunos de los elementos de este documento ABNT puedan ser
objeto de otros derechos de patente además de los identificados anteriormente. La ABNT no se debe considerar
responsable por la identificación de cualesquiera derechos de patente.
Esta Norma estandariza un lenguaje de aplicación XML que permite a los autores escribir presentaciones
multimedia interactivas. Este componente de ABNT NBR 15606 es parte de las especificaciones de codificación de
datos para el sistema brasileño de televisión digital terrestre (SBTVD) y comprende la especificación del lenguaje
utilizado por la máquina de presentación Ginga-NCL del middleware SBTVD, denominado Ginga.
Por medio de ese lenguaje, denominado NCL (Nested Context Language - Lenguaje de Contextos Anidados), un
autor puede describir el comportamiento temporal de una presentación multimedia, asociar hyperlinks (interacción
del usuario) a objetos de media, definir alternativas para presentación (adaptación) y describir el layout de la
presentación en múltiples dispositivos.
Esta Norma se destina fundamentalmente a las entidades que están especificando terminales y/o estándares
basados en el Ginga. También se destina a los desarrolladores de aplicaciones que utilizan las funcionalidades del
Ginga y de sus API. El middleware Ginga tiene como objeto garantizar la interoperabilidad de las aplicaciones en
diferentes implementaciones de plataformas que lo soportan.
Las aplicaciones Ginga se clasifican en dos categorías, dependiendo si la aplicación inicialmente procesada posee
contenido de naturaleza declarativa o imperativa. Esas categorías de aplicaciones son denominadas aplicaciones
declarativas y aplicaciones procedurales, respectivamente. Los ambientes de aplicación se clasifican del mismo
modo en dos categorías, dependiendo si procesan aplicaciones declarativas o procedurales, siendo entonces
denominados Ginga-NCL y Ginga-J, respectivamente.
Una implementación únicamente Ginga-NCL es permitida para receptores portátiles, siendo que, en ese caso, la
implementación del ambiente Ginga-J es opcional. Al ser implementado solamente con el Ginga-NCL, el
middleware Ginga brinda soporte a códigos procedurales a través del lenguaje Lua.
Esta Norma no especifica la forma de implementación de los ambientes de aplicación en un receptor.
vi
© ABNT 2008 - Todos os direitos reservados
NORMA BRASILEÑA
ABNT NBR 15606-5:2008
Televisión digital terrestre — Codificación de datos y especificaciones de
transmisión para radiodifusión digital
Parte 5: Ginga-NCL para receptores portátiles – Lenguaje de aplicación XML
para codificación de aplicaciones
1
Alcance
Esta parte de la ABNT NBR 15606 especifica un lenguaje de aplicación XML denominado NCL (Nested Context
Language), el lenguaje declarativo del middleware Ginga, la codificación y la transmisión de datos para
radiodifusión digital.
2
Referencias normativas
Los documentos indicados a continuación son indispensables para la aplicación de este documento. Para las
referencias fechadas, se aplican solamente las ediciones citadas. Para las referencias sin fecha, se aplican las
ediciones más recientes del documento citado (incluyendo enmiendas).
ABNT NBR 15603-2:2007, Televisión digital terrestre — Multiplexación y servicios de información (SI) — Parte 2:
Estructura de datos y definiciones de la información básica de SI
ABNT NBR 15606-1, Televisión digital terrestre — Codificación de datos y especificaciones de transmisión para
radiodifusión digital — Parte 1: Codificación de datos
ABNT NBR 15606-2: 2007, Televisión digital terrestre — Codificación de datos y especificaciones de transmisión
para radiodifusión digital — Parte 2: Ginga-NCL para receptores fijos y móviles — Lenguaje de aplicación XML
para codificación de aplicaciones
ISO/IEC 13818-1:2008, Information technology — Generic coding of moving pictures and associated audio
information: Systems
ECMA 262, ECMAScript language specification
3
Términos y definiciones
Para los efectos de esta parte de la ABNT NBR 15606, se aplican los siguientes términos y definiciones.
3.1
ambiente de aplicación
contexto o ambiente de software en el cual se procesa una aplicación
3.2
ambiente de aplicación declarativa
ambiente que brinda soporte al procesamiento de aplicaciones declarativas
NOTA
Un formateador (user agent) NCL es un ejemplo de ambiente de aplicación declarativa.
3.3
ambiente de aplicación procedural
ambiente que brinda soporte al procesamiento de aplicaciones procedurales
© ABNT 2008 - Todos los derechos reservados
1
ABNT NBR 15606-5:2008
3.4
API DON
API que define la estructura lógica de un documento XML y la forma de acceder, o manejar, un documento XML
NOTA
Esta API es una interfaz independiente de plataformas y lenguajes y sigue el Modelo DOM (Document Object Model).
3.5
aplicación
información que expresa un conjunto específico de comportamientos observables
3.6
aplicación declarativa
aplicación que utiliza principalmente, y como punto de partida, información declarativa para expresar su
comportamiento
NOTA
Una instancia de documento NCL es un ejemplo de aplicación declarativa.
3.7
aplicación híbrida
aplicación híbrida declarativa o aplicación híbrida procedural
3.8
aplicación híbrida declarativa
aplicación declarativa que contiene contenido de objeto activo
NOTA
Un documento NCL con un Java Xlet embutido es un ejemplo de aplicación híbrida declarativa.
3.9
aplicación híbrida procedural
aplicación procedural con contenido declarativo
NOTA
Un Java Xlet que crea y causa la exhibición de una instancia de documento NCL es un ejemplo de aplicación híbrida
procedural.
3.10
aplicación nativa
función intrínseca implementada por una plataforma receptora
NOTA
Una exhibición en closed caption es un ejemplo de aplicación nativa.
3.11
aplicación procedural
aplicación que utiliza principalmente, y como punto de partida, informaciones procedurales para expresar su
comportamiento
NOTA
Un programa en Java es un ejemplo de una aplicación procedural.
3.12
almacenamiento persistente
memoria disponible que puede ser leída o grabada por una aplicación y puede ser mantenida por más tiempo que
el tiempo de vida de la misma aplicación
NOTA
El almacenamiento persistente puede ser volátil o no volátil.
3.13
atributo
parámetro que representa la modalidad de una propiedad
2
© ABNT 2008 - Todos los derechos reservados
ABNT NBR 15606-5:2008
3.14
atributo de un elemento
propiedad de un elemento XML
3.15
autor
persona que escribe documentos NCL
3.16
canal de interactividad
canal de retorno
mecanismo de comunicación que suministra conexión entre el receptor y un servidor remoto
3.17
carácter
"letra" específica u otro símbolo identificable
EJEMPLO
“A”
3.18
carrusel de datos
método que envía cualquier conjunto de datos en forma cíclica, para que esos datos se puedan obtener, vía
radiodifusión, en un intervalo de tiempo tan largo como sea necesario
[ISO/IEC 13818-6:2001]
3.19
codificación de caracteres
mapeo entre un valor de entrada entero y el carácter textual, representado por ese mapeo
3.20
contenido de objeto activo
tipo de contenido que toma la forma de un programa ejecutable
NOTA
Un Xlet Java compilado es un ejemplo de contenido de objeto activo.
3.21
contenido NCL
conjunto de informaciones que consiste en un documento NCL y en un grupo de datos, incluyendo objetos (de
media o de ejecución), que acompañan el documento NCL
3.22
digital storage media command and control
DSM-CC
método de control que suministra acceso a un archivo o flujo en servicios digitales interactivos
[ISO/IEC 13818-6:2001]
3.23
document type definition
DTD
declaración que describe un tipo de documento XML
3.24
ECMAScript
lenguaje de programación definido en la ECMA 262
© ABNT 2008 - Todos los derechos reservados
3
ABNT NBR 15606-5:2008
3.25
elemento
unidad de estructuración del documento delimitada por tags
NOTA
Por lo general, un elemento es delimitado por una tag inicial y una tag final, excepto un elemento vacío que es
delimitado por una tag de elemento vacío.
3.26
elemento property
elemento NCL que define un nombre de propiedad y su valor asociado
3.27
entidad de la aplicación
unidad de información que expresa alguna parte de una aplicación
3.28
evento
ocurrencia en el tiempo que puede ser instantánea o tener duración mensurable
3.29
exhibidor de media
media player
componente identificable de un ambiente de aplicación que decodifica o ejecuta un tipo específico de contenido
3.30
eXtensible HTML
XHTML
versión extendida del HTML como aplicación XML
NOTA
En la especificación XHTML, un documento HTML es reconocido como aplicación XML.
3.31
herramienta de autoría
herramienta para ayudar a los autores a crear documentos NCL
3.32
fuente
mecanismo que permite la renderización específica de un carácter
EJEMPLO
NOTA
Tiresias, 12 puntos.
En la práctica, un formato de fuente incorpora aspectos de la codificación de un carácter.
3.33
formateador NCL
componente de software responsable por recibir la especificación de un documento NCL y controlar su presentación,
intentando garantizar que se respeten las relaciones entre los objetos de media, especificados por el autor
NOTA
Renderizador (renderer) de documentos, agente del usuario (user agent) y exhibidor son otros nombres que se
utilizan con el mismo significado del formateador de documentos.
3.34
flujo de transporte
se refiere a la sintaxis del flujo de transporte MPEG-2 para empaquetado y multiplexación de video, audio y
señales de datos en sistemas de radiodifusión digital
4
© ABNT 2008 - Todos los derechos reservados
ABNT NBR 15606-5:2008
3.35
flujo elemental
elementary stream
ES
flujo básico que contiene datos de video, audio, o datos privados
NOTA
Un único flujo elemental se transporta en una secuencia de paquetes PES con un, y sólo un, identificador
(stream_id).
3.36
gestor de aplicaciones
entidad responsable por la administración del ciclo de vida de las aplicaciones y que administra las aplicaciones,
funcionando tanto en la máquina de presentación como en la máquina de ejecución
3.37
identificador de paquete
PID
valor entero único, utilizado para asociar los flujos elementales de un programa, tanto en un flujo de transporte
único como multiprograma
3.38
información de servicio
SI
datos que describen programas y servicios
3.39
informaciones específicas del programa
program specific information
PSI
datos normativos necesarios para demultiplexar los flujos de transporte y regenerar los programas
3.40
Interfaz de programación de la aplicación
API
bibliotecas de software que ofrecen acceso uniforme a los servicios del sistema
3.41
lenguaje de marcación
formalismo que describe una clase de documentos que emplean marcación para delinear la estructura, apariencia
u otros aspectos del documento
3.42
lenguaje de script
lenguaje utilizado para describir un contenido de objeto activo incorporado en documentos NCL y en documentos
HTML
3.43
localizador
identificador que suministra una referencia a una aplicación o recurso
3.44
máquina de presentación
subsistema en un receptor que analiza y presenta aplicaciones declarativas, con contenidos como audio, video,
gráficos y texto, con base en reglas definidas en la máquina de presentación
NOTA
Una máquina de presentación es responsable por el control del comportamiento de la presentación y por iniciar
otros procesos en respuesta a entradas del usuario y otros eventos.
EJEMPLO
Navegador HTML y formateador NCL.
© ABNT 2008 - Todos los derechos reservados
5
ABNT NBR 15606-5:2008
3.45
máquina de ejecución
subsistema en un receptor que evalúa y ejecuta aplicaciones procedurales, compuestas por instrucciones en
lenguaje de computadora, contenido de media asociados y otros datos
NOTA
Una máquina de ejecución se puede implementar con un sistema operativo, compiladores de lenguaje de
computadora, interpretadores e interfaces de programación de aplicaciones (API), que una aplicación procedural puede utilizar
para presentar contenido audiovisual, interactuar con el usuario o ejecutar otras tareas que no sean evidentes para el usuario.
EJEMPLO
Ambiente de software JavaTV, utilizando lenguaje de programación Java e interpretador bytecode, API
JavaTV y máquina virtual Java para ejecución del programa.
3.46
método
función asociada a un objeto autorizado para manejar los datos del objeto
3.47
nudo NCL
elemento <media>, <context>, <body> o <switch> de NCL
3.48
normal play time
NPT
coordenada temporal absoluta que representa la posición en un flujo
3.49
objeto de media
colección de pedazos de datos identificados por nombre que puede representar un contenido de media o un
programa escrito en lenguaje específico
3.50
perfil
especificación de una clase de capacidades, ofreciendo diferentes niveles de funcionalidades en un receptor
3.51
perfil one-seg
caracteriza el servicio que puede ser recibido por un sintonizador de banda estrecha (430 KHz) y por lo tanto con
ahorro en el consumo de batería
NOTA
El perfil one-seg también es conocido como perfil portátil.
3.52
perfil full-seg
caracteriza el servicio que necesita necesariamente un demodulador de banda ancha (5,7 MHz) para ser recibido
NOTA
Dependiendo de las configuraciones de transmisión y de funcionalidad específicas del receptor, se puede recibir en
movimiento o sólo por receptores fijos, aunque sin el beneficio del ahorro de energía. La resolución del video transmitido puede
ser o no de alta definición.
3.53
plug-in
conjunto de funcionalidades que se puede agregar a una plataforma genérica para suministrar funcionalidad
adicional
3.54
plataforma receptora
plataforma
hardware, sistema operativo y bibliotecas de software nativas del receptor, elegidos por el fabricante
6
© ABNT 2008 - Todos los derechos reservados
ABNT NBR 15606-5:2008
3.55
recurso
objeto de datos o un servicio de la red que es identificado unívocamente
3.56
sistema de archivos local
sistema de archivos suministrado por la plataforma receptora local
3.57
tiempo de vida de una aplicación
período de tiempo entre el momento en que una aplicación se carga y el momento en que se destruye
3.58
uniform resource identifier
URI
método de encaminamiento que permite el acceso a objetos en una red
3.59
user agent
cualquier programa que interpreta un documento NCL
NOTA
Un user agent puede exhibir un documento, intentando garantizar que se respeten las relaciones especificadas por el
autor entre objetos de media, pronunciarlo en audio sintetizado, convertirlo en otro formato etc.
3.60
usuario
persona que interactúa con un formateador para visualizar, oír o utilizar de otra forma un documento NCL
3.61
usuario final
individuo que opera o interactúa con un receptor
4
Abreviaturas
Para los efectos de esta parte de la ABNT NBR 15606, se aplican las siguientes abreviaturas:
API
BML
CLUT
CSS
DOM
DSM-CC
DTD
DTV
DVB
GIF
HTML
HTTP
JPEG
MIME
MNG
MPEG
Application Programming Interface
Broadcast Markup Language
Color Look-up Table
Cascading Style Sheets
Document Object Model
Digital Storage Media Command and Control
Document Type Definition
Digital Television
Digital Video Broadcasting
Graphics Interchange Format
Hypertext Markup Language
Hypertext Transfer Protocol
Joint Photographic Expert Group
Multipurpose Internet Mail Extensions
Multiple Network Graphics
Moving Picture Expert Group
© ABNT 2008 - Todos los derechos reservados
7
ABNT NBR 15606-5:2008
NCL
NCM
NPT
OS
PAT
PES
PID
PMT
PNG
PSI
SBTVD
SMIL
TS
UCS
URI
URL
XHTML
XML
W3C
5
Nested Context Language
Nested Context Model
Normal Play Time
Operating System
Program Association Table
Packetized Elementary Stream
Packet Identifier
Program Map Table
Portable Network Graphics
Program Specific Information
Sistema Brasileño de Televisión Digital Terrestre
Synchronized Multimedia Integration Language
Transport Stream
Universal (Coded) Character Set
Universal Resource Identifier
Universal Resource Locator
eXtensible HTML
Extensible Markup Language
World-Wide Web Consortium
Arquitectura Ginga
5.1 Ginga main modules
El universo de las aplicaciones Ginga se puede dividir en un conjunto de aplicaciones declarativas y un conjunto
de aplicaciones procedurales. Una aplicación declarativa es aquella donde el tipo del contenido de la entidad inicial
es declarativo. Por otro lado, una aplicación procedural es aquella cuyo tipo del contenido de la entidad inicial es
procedural. Una aplicación declarativa pura es aquella en la cual el contenido de todas las entidades es del tipo
declarativo, y una aplicación procedural pura es aquella en la cual el contenido de todas las entidades es del tipo
procedural. Una aplicación híbrida es aquella cuyo conjunto de entidades posee tanto contenido del tipo
declarativo como procedural. Una aplicación Ginga no necesita ser puramente declarativa o procedural.
En particular, las aplicaciones declarativas frecuentemente utilizan scripts, cuyo contenido es de modalidad
procedural. Además de ello, una aplicación declarativa puede hacer referencia a un código Java TV Xlet
incorporado. Del mismo modo, una aplicación procedural puede hacer referencia a una aplicación declarativa,
conteniendo, por ejemplo, contenido gráfico, o puede construir e iniciar la presentación de aplicaciones con
contenido declarativo. Por lo tanto, ambos tipos de aplicación Ginga pueden utilizar las facilidades de los
ambientes de aplicación: declarativo y procedural.
Ginga-NCL, ambiente obligatorio para receptores portátiles, es un subsistema lógico del sistema Ginga
responsable por el procesamiento de documentos NCL. Un componente clave del Ginga-NCL es la máquina de
interpretación del contenido declarativo (formateador NCL). Otros módulos importantes son el exhibidor
(user agent) XHTML y la máquina de presentación Lua, que es responsable por la interpretación de los scripts Lua
(ver la ABNT NBR 15606-2:2007, Anexo B).
NOTA
NCL es marca registrada y su especificación es propiedad intelectual de la PUC-Rio (INPI Departamento de
Transferencia Tecnológica - No. 0007162-5; 20/12/2005).
Ginga-J, ambiente obligatorio para receptores portátiles, es un subsistema lógico del sistema Ginga, responsable
por el procesamiento de contenidos activos. Un componente clave del ambiente de aplicación procedural es la
máquina de ejecución del contenido procedural, compuesta por una máquina virtual Java.
Decodificadores de contenido comunes sirven tanto para las aplicaciones procedurales con respecto a las
declarativas que necesitan decodificar y presentar tipos comunes de contenido como PNG, JPEG, MPEG y otros
formatos. El núcleo común Ginga (Ginga Common Core) está compuesto por los decodificadores de contenido
8
© ABNT 2008 - Todos los derechos reservados
ABNT NBR 15606-5:2008
comunes y por procedimientos para obtener contenidos transportados en flujos de transporte (transport streams)
MPEG-2 y a través del canal de interactividad. El Núcleo Común Ginga también debe soportar obligatoriamente el
modelo conceptual de exhibición, tal como se describe en la ABNT NBR 15606-1.
La arquitectura (ver Figura 1) y facilidades Ginga fueron proyectadas para ser aplicadas a sistemas de
radiodifusión y receptores terrestres de radiodifusión. Adicionalmente, la misma arquitectura y facilidades se
pueden aplicar a sistemas que utilizan otros mecanismos de transporte de datos (como sistemas de televisión vía
satélite o por cable).
Figura 1 — Arquitectura Ginga
5.2 Interacción con el ambiente nativo
Por lo general, el Ginga es ajeno a cualesquiera aplicaciones nativas que pueden también optar por utilizar el
plano gráfico. Eso incluye, pero no se limita a aplicaciones como: closed caption, mensajes del sistema de acceso
condicional (CA), menús del receptor y guías de programación nativos.
Las aplicaciones nativas pueden tener prioridad sobre las aplicaciones Ginga. El closed caption y los mensajes de
emergencia deben tener obligatoriamente prioridad sobre el sistema Ginga.
Algunas aplicaciones nativas, como el closed caption, representan un caso especial en el cual la aplicación nativa
puede estar activa por largos períodos en conjunto con las aplicaciones Ginga.
6
Objetos XHTML incorporados en presentaciones NCL
6.1 NCL como lenguaje cola
Diferentemente de XHTML o HTML, NCL define una separación bien delimitada entre el contenido y la estructura
de un documento (o aplicación), probando un control no invasivo del enlace entre el contenido y su presentación y
layout.
El foco del lenguaje declarativo NCL es más amplio que el ofrecido por la XHTML. La sincronización espaciotemporal, definida genéricamente por los enlaces NCL; adaptabilidad, definida por los elementos switch y
descriptor switch de NCL; y soporte a múltiples dispositivos de exhibición, definidos por regiones NCL, es el foco
de ese lenguaje declarativo. La interacción del usuario se trata sólo como un caso particular de sincronización
temporal.
Como la NCL tiene una separación más exacta entre el contenido y la estructura, la misma no define ninguna
media en sí. Al contrario, define la cola que sujeta la media en presentaciones multimedia.
Un documento NCL sólo define cómo los objetos de media son estructurados y relacionados en el tiempo y
espacio. Como un lenguaje de cola, la misma no restringe o prescribe los tipos de contenido de los objetos de
© ABNT 2008 - Todos los derechos reservados
9
ABNT NBR 15606-5:2008
media. En ese sentido, es posible tener objetos de imagen (GIF, JPEG etc.), de video (MPEG, MOV etc.), de audio
(MP3, WMA etc.), de texto (TXT, PDF etc.), de ejecución (Xlet, Lua etc.), entre otros, como objetos de media NCL.
Cuáles objetos de media son soportados depende de los exhibidores de media que están acoplados al
formateador NCL (exhibidor NCL). Uno de esos exhibidores es el decodificador/exhibidor MPEG-4, normalmente
implementado en hardware en el receptor de televisión digital. De esa forma, el video y el audio MPEG-4 principal
se tratan como todos los demás objetos de media que pueden estar relacionados utilizando NCL.
Otro objeto de media NCL que debe ser obligatoriamente soportado es el objeto de media basado en XHTML. La
NCL no reemplaza, pero incorpora documentos (u objetos) basados en XHTML. Como ocurre con otros objetos de
media, qué lenguaje basado en XHTML tiene soporte en un formateador NCL es una elección de implementación
y, por lo tanto, depende de qué navegador XHTML, incorporado en el formateador NCL, actúa como exhibidor de
esa media.
Aunque un navegador XHTML deba ser obligatoriamente soportado, se recomienda evitar la utilización de
elementos XHTML para definir relaciones (incluso enlaces XHTML) en la autoría de documentos NCL. Se
recomienda que la autoría con base en la estructura sea priorizada por razones conocidas y ampliamente
divulgadas en la literatura.
Durante la exhibición del contenido de objetos de media se generan varios eventos. Algunos ejemplos son la
presentación de parte del contenido de un objeto de media, la selección de parte del contenido de un objeto etc.
Los eventos pueden generar acciones sobre otros objetos de media, como iniciar o terminar sus presentaciones.
Por lo tanto, los eventos deben ser obligatoriamente relatados por los exhibidores de media al formateador NCL
que, a su vez, puede generar acciones a ser aplicadas a ésos u otros exhibidores. Ginga-NCL define la API (ver
Sección 8) de un adaptador con el objetivo de estandarizar la interfaz entre el formateador Ginga-NCL y cada
exhibidor específico.
Para que cualquier exhibidor de media, en particular un navegador XHTML, sea acoplado al formateador
Ginga-NCL, debe brindar soporte obligatoriamente a la API de los adaptadores. Así, para algunos exhibidores de
media, incluso navegadores XHTML, puede ser necesario un módulo adaptador para alcanzar la integración.
Para edición en vivo, el Ginga-NCL también define eventos de flujo NCL para ofrecer soporte a los eventos
generados en vivo sobre flujos de media, en particular sobre el flujo de video del programa principal. Esos eventos
son una generalización del mismo concepto encontrado en otras normas, como, por ejemplo, los b-events de BML
Aunque un navegador XHTML deba ser obligatoriamente soportado, se recomienda evitar la utilización de
elementos XHTML para definir relaciones (incluso eventos de flujo) durante la creación de documentos NCL, por la
misma razón, es decir, se recomienda que la autoría con base en la estructura sea priorizada por razones
conocidas y ampliamente divulgadas en la literatura.
6.2 Formato de contenido XHTML
Formatos comunes de contenido deben ser obligatoriamente adoptados para la producción e intercambio de
contenido multimedia, como definido en la ABNT NBR 15606-1. Además de ello, en el ambiente de aplicación
declarativa también se exige la especificación de formatos comunes de contenidos XHTML para las aplicaciones
de televisión interactiva.
De este modo, esta Norma también especifica los elementos obligatorios de los objetos de media XHTML
incorporados en aplicaciones NCL, así como las propiedades de hojas de estilo obligatorias.
6.3 XHTML para el perfil portátil
6.3.1
NOTA
10
Marcaciones XML
Objetos de media NCL basados en XHTML siguen la recomendación W3C “Modularization of XHTML”.
© ABNT 2008 - Todos los derechos reservados
ABNT NBR 15606-5:2008
Las colecciones de atributo XHTML se definen de acuerdo con la Tabla 1. Las marcaciones XML que deben ser
soportadas obligatoriamente por cualquier implementación, se listan en la Tabla 2.
Tabla 1 — Colecciones de atributos
Nombre de la
colección
Core
Atributos en la
colección
class (NMTOKENS)
Requerido
Id (ID),
Requerido
title (CDATA)
I18N
Events
–
xml:lang (CDATA)
Requerido (default)
onclick (Script)
-
ondblclick (Script)
–
onmousedown (Script)
–
onmouseup (Script)
–
onmouseover (Script)
–
onmousemove (Script)
–
onmouseout (Script)
–
onkeypress (Script)
–
onkeydown (Script)
-
onkeyup (Script)
-
Style
style (CDATA)
Common
Core + Events + I18N
+ Style
© ABNT 2008 - Todos los derechos reservados
Condición del
atributo
Requerido
11
ABNT NBR 15606-5:2008
Tabla 2 — Elementos de marcación XML obligatorios
Módulo
Elemento
Condición del
elemento
body
Requerido
head
Requerido
html
title
abbr
acronym
address
blockquote
br
cite
code
dfn
div
em
h1
h2
h3
h4
h5
h6
kbd
p
pre
q
samp
span
strong
var
Requerido
Requerido
–
–
–
–
Requerido
–
–
–
Requerido
–
Requerido
Requerido
Requerido
Requerido
Requerido
Requerido
–
Requerido
–
–
–
Requerido
–
–
Structure
Text
Core
12
Hypertext
a
Requerido
List
dl
dt
dd
ol
ul
li
–
–
–
–
–
–
Atributo
Condición del
atributo
%Common.attrib
%Core.attrib
%I18n.attrib
%Events.attrib
%I18n.attrib
profile
Requerido
Requerido
–
Requerido
–
%I18n.attrib
Requerido
%Core.attrib
Requerido
%Common.attrib
Requerido
%Common.attrib
%Common.attrib
%Common.attrib
%Common.attrib
%Common.attrib
%Common.attrib
Requerido
Requerido
Requerido
Requerido
Requerido
Requerido
%Common.attrib
Requerido
%Common.attrib
Requerido
%Common.attrib
accesskey
charset
href
hreflang
rel
rev
tabindex
type
Requerido
Requerido
Requerido
Requerido
–
–
–
–
–
© ABNT 2008 - Todos los derechos reservados
ABNT NBR 15606-5:2008
Tabla 2 (continuación)
applet
param
b
big
hr
i
small
sub
sup
tt
del
ins
Condición del
elemento
–
–
–
–
–
–
–
–
–
–
–
–
Bi-directional
text
bdo
–
Basic forms
form
input
label
select
option
textarea
–
–
–
–
–
–
Módulo
Elemento
Applet
Presentation
Text extension
Edit
form
Requerido
input
Requerido
select
option
textarea
button
fieldset
label
legend
optgroup
Requerido
Requerido
Requerido
–
–
–
–
–
Forms
Forms
© ABNT 2008 - Todos los derechos reservados
Atributo
Condición del
atributo
%Common.attrib
action
method
enctype
accept-charset
accept
name
%Common.attrib
accesskey
checked
disabled
readonly
maxlength
alt
name
size
src
tabindex
accept
type
value
Requerido
Requerido
Requerido
Requerido
Requerido
Requerido
Requerido
Requerido
Requerido
–
Requerido
Requerido
Requerido
–
–
Requerido
–
–
–
Requerido
Requerido
13
ABNT NBR 15606-5:2008
Tabla 2 (continuación)
Módulo
Elemento
Basic tables
Table
Tables
Image
Client side map
Server side image map
Object
Frames
Target
IFrame
14
caption
table
td
th
tr
caption
table
td
th
tr
col
colgroup
tbody
thead
tfoot
img
a&
area
img&
input&
map
object&
img&
Input&
Condición del
elemento
–
Requerido
Requerido
–
Requerido
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
object
Requerido
param
frameset
frame
noframe
a&
area&
base&
link&
form&
iframe
–
–
–
–
–
–
–
–
–
–
Atributo
Condición del
atributo
%Common.attrib
archive
classid
codebase
codetype
data
declare
height
name
standby
tabindex
type
width
Requerido
–
–
–
–
Requerido
–
Requerido
–
–
–
Requerido
Requerido
© ABNT 2008 - Todos los derechos reservados
ABNT NBR 15606-5:2008
Tabla 2 (continuación)
Módulo
Elemento
Intrinsic events
a&
area&
frameset&
form&
body&
label&
input&
select&
textarea&
button&
Metainformation
meta
Condición del
elemento
–
–
–
–
–
–
–
–
–
–
Requerido
Atributo
Condición del
atributo
%I18n.attrib
http-equiv
name
content
scheme
–
–
Requerido
Requerido
–
charset
type
src
defer
%I18n.attrib
id
type
media
title
Requerido
–
Requerido
Requerido
–
noscript
Scripting
Stylesheet
Style attribute
Link
Base
6.3.2
script
–
style
Requerido
link
base
Requerido
Requerido
–
Hojas de estilo
Las propiedades de hojas de estilo que deben ser soportadas obligatoriamente por cualquier implementación
están listadas en la Tabla 3.
© ABNT 2008 - Todos los derechos reservados
15
ABNT NBR 15606-5:2008
Tabla 3 — Propiedades de hojas de estilo CSS 2 obligatorias
Propiedad
Condición de la propiedad
Value assignment/Inheritance
@import
–
!important
–
Media type
@media
Requerido
box model
margin-top
–
margin-right
–
margin-bottom
–
margin-left
–
margin
Requerido
padding-top
Requerido
padding-right
Requerido
padding-bottom
Requerido
padding-left
Requerido
padding
Requerido
border-top-width
–
border-right-width
–
border-bottom-width
–
border-left-width
–
border-width
Requerido
border-top-color
–
border-right-color
–
border-bottom-color
–
border-left-color
–
border-color
Requerido
border-top-style
–
border-right-style
–
border-bottom-style
–
border-left-style
–
border-style
Requerido
border-top
–
border-right
–
border-bottom
–
border-left
–
border
Requerido
Visual formatting model
position
Requerido
left
Requerido
top
Requerido
width
Requerido
height
Requerido
z-index
Requerido
line-height
Requerido
vertical-align
–
display
Requerido
bottom
–
right
–
float
–
clear
–
direction
–
16
© ABNT 2008 - Todos los derechos reservados
ABNT NBR 15606-5:2008
Tabla 3 (continuación)
Propiedad
Condición de la propiedad
unicode-bidi
–
min-width
–
max-width
–
min-height
–
max-height
–
Other visual effects
visibility
Requerido
overflow
Requerido
clip
–
Generated content/Auto numbering/List
content
–
quotes
–
counter-reset
–
counter-increment
–
marker-offset
–
list-style-type
–
list-style-image
–
list-style-position
–
list-style
–
Page media
"@page"
–
size
–
marks
–
page-break-before
–
page-break-after
–
page-break-inside
–
page
–
orphans
–
widows
–
Background
background
–
background-color
–
background-image
Requerido
background-repeat
Requerido
background-position
–
background-attachment
–
Font
color
Requerido
font-family
Requerido
font-style
Requerido
font-size
Requerido
font-variant
Requerido
font-weight
Requerido
font
Requerido
font-stretch
–
font-adjust
–
Text
text-indent
–
text-align
Requerido
text-decoration
–
© ABNT 2008 - Todos los derechos reservados
17
ABNT NBR 15606-5:2008
Tabla 3 (continuación)
Propiedad
Condición de la propiedad
text-shadow
–
letter-spacing
Requerido
word-spacing
–
text-transform
–
white-space
Requerido
Pseudo class/ Pseudo element
:link
–
:visited
–
:active
Requerido
:hover
–
:focus
Requerido
:lang
–
:first-child
–
:first-line
–
:first-letter
–
:before
–
:after
–
Table
caption-side
–
border-collapse
–
border-spacing
–
table-layout
–
empty-cells
–
speak-header
–
User interface
outline-color
–
outline-width
–
outline-style
–
outline
–
cursor
–
Voice style sheet
volume
–
speak
–
pause-before
–
pause-after
–
pause
–
cue-before
–
cue-after
–
cue
–
play-during
–
azimuth
–
elevation
–
speech-rate
–
voice-family
–
pitch
–
pitch-range
–
stress
–
richness
–
speak-punctuation
–
peak-numeral
–
18
© ABNT 2008 - Todos los derechos reservados
ABNT NBR 15606-5:2008
Tabla 3 (continuación)
Propiedad
Extended property
clut
color-index
background-color-index
border-color-index
border-top-color-index
border-right-color-index
border-bottom-color-index
border-left-color-index
outline-color-index
resolution
display-aspect-ratio
grayscale-color-index
nav-index
nav-up
nav-down
nav-left
nav-right
used-key-list
Condición de la propiedad
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
–
Las siguientes restricciones se deberán aplicar obligatoriamente a las propiedades de exhibición:

Solamente elementos de bloque se pueden aplicar para <p>, <div>, <body>, <input> y <object>;

solamente valores definidos en el mismo elemento HTML se pueden aplicar para <br>, <a> y <span>.
Además de ello, las siguientes restricciones se deberán aplicar obligatoriamente a las propiedades de posición:

solamente valores absolutos se pueden aplicar para <p>, <div>, <input> y <object>;

solamente valores estáticos se pueden aplicar para <br>, <span> y <a>.
Los selectores CSS que deben ser soportados obligatoriamente por cualquier implementación son los siguientes:
 universal;
 type;
 class;
 id.
7 NCL - Lenguaje declarativo XML para especificación de presentaciones multimedia
interactivas
7.1 Lenguajes modulares y perfiles de lenguajes
7.1.1
Módulos NCL
El abordaje modular ha sido utilizado en varios lenguajes recomendados por el W3C.
Módulos son colecciones de elementos, atributos y valores de atributos XML semánticamente relacionados que
representan una unidad de funcionalidad. Módulos se definen en conjuntos coherentes. Esa coherencia se
expresa por medio de la asociación de un mismo namespace a los elementos de esos módulos.
NOTA
Namespaces se discuten en Namespaces
© ABNT 2008 - Todos los derechos reservados
in XML:1999 .
19
ABNT NBR 15606-5:2008
Un perfil de lenguaje es una combinación de módulos. Los módulos son atómicos, es decir, no se pueden
subdividir cuando incluidos en un perfil de lenguaje. Además de ello, la especificación de un módulo puede incluir
un conjunto de requisitos para integración, con el cual los perfiles de lenguaje, que incluyen el módulo, deben ser
compatibles obligatoriamente.
NCL fue especificada de forma modular, permitiendo la combinación de sus módulos en perfiles de lenguaje. Cada
perfil puede agrupar un subconjunto de módulos NCL, permitiendo la creación de lenguajes orientados hacia las
necesidades específicas de los usuarios. Además de ello, los módulos y perfiles NCL se pueden combinar con
módulos definidos en otros lenguajes, permitiendo la incorporación de características de la NCL en esos lenguajes
y viceversa.
Normalmente, hay un perfil de lenguaje que incorpora casi todos los módulos asociados a un único namespace.
Ése es el caso del perfil Lenguaje NCL.
Otros perfiles de lenguaje se pueden especificar como subconjuntos de un perfil mayor o incorporar una
combinación de módulos asociados a diferentes namespaces. Ejemplos del primer caso son los perfiles TVD
Básico (perfil BDTV) y TVD Avanzado (perfil EDTV) de la NCL.
Subconjuntos de los módulos del perfil Lenguaje NCL utilizados en la definición de los perfiles TVD Básico y TVD
Avanzado se definen para ajustar el lenguaje a las características del ambiente de radiodifusión de televisión, con
sus varios dispositivos de presentación: Aparato de televisión, dispositivos móviles etc.
NOTA
Un abordaje análogo también se encuentra en otros lenguajes (SMIL 2.1 Specification:2005 y XHTML 1.0:2002).
El principal objetivo de la conformidad con perfiles de lenguaje es aumentar la interoperabilidad. Los módulos
obligatorios se definen de tal forma que cualquier documento, especificado de conformidad con un perfil de
lenguaje, da como resultado una presentación razonable cuando es presentado en un perfil distinto de aquél para
el cual fue especificado. El formateador de documentos, soportando el conjunto de módulos obligatorios, ignoraría
todos los otros elementos y atributos desconocidos.
NOTA
Renderizador de documentos, agente del usuario y exhibidor son otros nombres atribuidos al formateador de
documentos.
El perfil BDTV es el perfil mínimo exigido para dispositivos portátiles. En forma alternativa, se puede usar el perfil
EDTV.
La versión NCL 3.0 revisa las funcionalidades contenidas en la NCL 2.3 (NCL Main Profile: 2005) y se divide
en 15 áreas funcionales, que se subdividen nuevamente en módulos. A partir de las 15 áreas funcionales, 14 se
utilizan para definir los perfiles TVD Avanzado y TVD Básico. Dos áreas funcionales tienen módulos con la misma
semántica definida por SMIL 2.0. Las 14 áreas funcionales utilizadas y sus módulos correspondientes son:
1)
Structure
Módulo Structure
2)
Layout
Módulo Layout
3)
Components
Módulo Media
Módulo Context
4)
20
Interfaces
© ABNT 2008 - Todos los derechos reservados
ABNT NBR 15606-5:2008
Módulo MediaContentAnchor
Módulo CompositeNodeInterface
Módulo PropertyAnchor
Módulo SwitchInterface
5)
Presentation Specification
Módulo Descriptor
6)
Linking
Módulo Linking
7)
Connectors
Módulo ConnectorCommonPart
Módulo ConnectorAssessmentExpression
Módulo ConnectorCausalExpression
Módulo CausalConnector
Módulo CausalConnectorFunctionality
Módulo ConnectorBase
8)
Presentation Control
Módulo TestRule
Módulo TestRuleUse
Módulo ContentControl
Módulo DescriptorControl
9)
Timing
Módulo Timing
10)
Reuse
Módulo Import
Módulo EntityReuse
Módulo ExtendedEntityReuse
11)
Navigational Key
Módulo KeyNavigation
12)
Animation
Módulo Animation
13) Transition Effects
Módulo TransitionBase
Módulo Transition
14) Meta-Information”
Módulo Metainformation
© ABNT 2008 - Todos los derechos reservados
21
ABNT NBR 15606-5:2008
7.1.2
Identificadores para módulos y perfiles de lenguaje de la NCL 3.0
Se recomienda que cada perfil NCL declare explícitamente el URI del namespace que será usado para identificarlo.
Los documentos creados en perfiles de lenguaje que incluyen el módulo Structure de NCL se pueden asociar con
el tipo MIME “application/x-ncl+xml”. Los documentos que utilizan el tipo MIME “application/x-ncl+xml” deben
obligatoriamente estar de conformidad con el lenguaje hospedero.
Los identificadores de namespace XML para el conjunto completo de módulos, elementos y atributos NCL 3.0
están contenidos en el siguiente namespace: http://www.ncl.org.br/NCL3.0/
Cada módulo NCL tiene un identificador único asociado a él. Los identificadores de los módulos NCL 3.0 deben
estar de acuerdo obligatoriamente con la Tabla 4.
Los módulos también pueden ser identificados colectivamente. Las siguientes colecciones de módulos se definen:
 módulos utilizados por el perfil Lenguaje NCL 3.0: http://www.ncl.org.br/NCL3.0/LanguageProfile
 módulos utilizados por el perfil Conector Causal NCL 3.0:
http://www.ncl.org.br/NCL3.0/CausalConnectorProfile
 módulos utilizados por el perfil DTV Avanzado NCL 3.0: http://www.ncl.org.br/NCL3.0/EDTVProfile
 módulos utilizados por el perfil DTV Básico NCL 3.0: http://www.ncl.org.br/NCL3.0/BDTVProfile
22
© ABNT 2008 - Todos los derechos reservados
ABNT NBR 15606-5:2008
Tabla 4 — Identificadores de los módulos de NCL 3.0
Módulos
Identificadores
Animation
http://www.ncl.org.br/NCL3.0/Animation
CompositeNodeInterface
http://www.ncl.org.br/NCL3.0/CompositeNodeInterface
CausalConnector
http://www.ncl.org.br/NCL3.0/CausalConnector
CausalConnectorFunctionality
http://www.ncl.org.br/NCL3.0/CausalConnectorFunctionality
ConnectorCausalExpression
http://www.ncl.org.br/NCL3.0/ConnectorCausalExpression
ConnectorAssessmentExpression
http://www.ncl.org.br/NCL3.0/ConnectorAssessmentExpression
ConnectorBase
http://www.ncl.org.br/NCL3.0/ConnectorBase
ConnectorCommonPart
http://www.ncl.org.br/NCL3.0/ConnectorCommonPart
ContentControl
http://www.ncl.org.br/NCL3.0/ContentContro