Xem mẫu
- TIÊU CHUẨN QUỐC GIA
TCVN 11523-2:2016
ISO/IEC 24752-2:2014
CÔNG NGHỆ THÔNG TIN - GIAO DIỆN NGƯỜI SỬ DỤNG - BỘ ĐIỀU KHIỂN TỪ XA PHỔ DỤNG –
PHẦN 2: MÔ TẢ SOCKET GIAO DIỆN NGƯỜI SỬ DỤNG
Information technology User interfaces - Universal remote console - Part 2: User interface socket
description
Lời nói đầu
TCVN 11523-2:2016 hoàn toàn tương đương với ISO/IEC 24752-2:2014
TCVN 11523-2:2016 do Tiểu Ban kỹ thuật tiêu chuẩn quốc gia TCVN/JTC 1/SC 35 Giao diện người sử
dụng biên soạn, Tổng cục Tiêu chuẩn Đo lường Chất lượng đề nghị, Bộ Khoa học và Công nghệ công
bố.
Bộ tiêu chuẩn TCVN 11523 Công nghệ thông tin - Giao diện người sử dụng - Bộ điều khiển từ xa phổ
dụng gồm sáu phần:
- TCVN 11523-1:2016 (ISO/IEC 24752-1:2014), Phần 1: Khung tổng quát chung
- TCVN 11523-2:2016 (ISO/IEC 24752-2:2014), Phần 2: Mô tả socket giao diện người sử dụng
- TCVN 11523-3:2016, Phần 3: Khuôn mẫu trình bày
- TCVN 11523-4:2016 (ISO/IEC 24752-4:2014), Phần 4: Mô tả đích
-TCVN 11523-5:2016 (ISO/IEC 24752-5:2014), Phần 5: Mô tả tài nguyên
- TCVN 11523-6:2016 (ISO/IEC 24752-6:2014), Phần 6: Tích hợp dịch vụ web
CÔNG NGHỆ THÔNG TIN - GIAO DIỆN NGƯỜI SỬ DỤNG - BỘ ĐIỀU KHIỂN TỪ XA PHỔ DỤNG –
PHẦN 2: MÔ TẢ SOCKET GIAO DIỆN NGƯỜI SỬ DỤNG
Information technology User interfaces - Universal remote console - Part 2: User interface
socket description
1 Phạm vi áp dụng
Bộ tiêu chuẩn này hỗ trợ việc vận hành các sản phẩm thông tin và điện tử thông qua các giao diện từ
xa, thay thế và các tác nhân thông minh.
Socket giao diện người sử dụng là một giao diện người sử dụng trừu tượng mô tả chức năng và trạng
thái của thiết bị hoặc dịch vụ (đích) theo cách máy có thể hiểu được mà độc lập với việc trình diễn và
các khả năng nhập của thiết bị tương tác người sử dụng. Tiêu chuẩn này xác định ngôn ngữ dựa trên
Ngôn ngữ đánh dấu mở rộng (XML) để mô tả socket giao diện người sử dụng. Mục đích của socket
giao diện người sử dụng là tiết lộ thông tin liên quan đến đích sao cho người sử dụng có thể hiểu được
trạng thái của nó và điều hành nó. Socket giao diện người sử dụng bao gồm dữ liệu đưa ra cho người
sử dụng, các biến được người dùng sử dụng, các lệnh mà người sử dụng có thể kích hoạt và các
ngoại lệ mà người sử dụng được thông báo. Đặc tả socket giao diện người sử dụng thích hợp với việc
xây dựng và thích nghi của các giao diện người sử dụng.
2 Sự phù hợp
Tệp XML phù hợp với tiêu chuẩn này (là mô tả socket giao diện người sử dụng) nếu thực hiện tất cả
các yêu cầu sau đây:
a) Tệp XML có kiểu MIME như đã quy định trong điều 6.1, nếu thích hợp:
b) Tệp XML được mã hóa trong UCS (xem điều 6.1);
c) Thẻ gốc của nó là thẻ (với uis biểu diễn vùng tên “http://
openurc.org/ns/uisocketdesc-2”),. như đã quy định trong Điều 6;
d) Tệp XML chứa tất cả các thẻ và thuộc tính yêu cầu với các giá trị riêng, như đã quy định trong Điều
6;
- e) Nếu tệp XML chứa các thẻ hoặc thuộc tính được khuyến cáo hoặc tùy chọn với các giá trị của chúng
thì sẽ được trình bày như đã quy định trong Điều 6.
CHÚ THÍCH 1 Sự phù hợp chặt chẽ về ngôn ngữ (không có các thẻ hoặc thuộc tính bổ sung nào được
phép) không được yêu cầu bởi vì các phiên bản tương lai của tiêu chuẩn này có thể thêm vào các thẻ,
các thuộc tính hoặc các giá trị mới. Do đó, các nhà sản xuất URC được khuyến khích cài đặt các URC
của họ sao cho việc đánh dấu sẽ được bỏ qua mà không gây ra lỗi
CHÚ THÍCH 2 Các nhà sản xuất đích mong muốn thêm vào thông tin về nhà sản xuất cho mô tả socket
ngoại trừ các thẻ, các thuộc tính và các giá trị quy định trong tiêu chuẩn này, điều này có thể thực hiện
bằng cách cung cấp bên ngoài các mô tả tài nguyên hướng vào cấu trúc của mô tả socket. Để biết
thêm chi tiết tham khảo TCVN 11523-5 (ISO/IEC 24752-5).
3 Tài liệu viện dẫn
Các tài liệu viện dẫn sau là rất cần thiết cho việc áp dụng tiêu chuẩn. Đối với các tài liệu viện dẫn ghi
năm công bố thì áp dụng bản được nêu. Đối với các tài liệu viện dẫn không ghi năm công bố thì áp
dụng phiên bản mới nhất, bao gồm cả các sửa đổi.
TCVN 11523-1 (ISO/IEC 24752-1) Công nghệ thông tin - Giao diện người sử dụng - Bộ điều khiển từ
xa phổ dụng - Phần 1: Khung tổng quát
TCVN 11523-4 (ISO/IEC 24752-4) Công nghệ thông tin - Giao diện người sử dụng - Bộ điều khiển từ
xa phổ dụng - Phần 4: Mô tả đích
TCVN 7980:2015 (ISO 15836:2009) Thông tin tư liệu - Bộ yếu tố siêu dữ liệu Dublin Core
ISO/IEC 10646:20111 Information technology - Universal coded character set (Công nghệ thông tin - Bộ
ký tự mã hóa chung)
ISO/IEC 14977:1996, Information technology - Syntactic metalanguage - Extended BNF (Công nghệ
thông tin - Siêu ngôn ngữ cú pháp)
W3C Recommendation: XML Path Language (XPath) 2.0 (Second Edition), W3C Recommendation 14
December 2010 (Link errors corrected 3 January 2011) (Khuyến cáo W3C: Ngôn ngữ đường truyền
XML 2.0 (Xuất bản lần 2), Khuyến cáo W3C ngày 14 tháng 10 năm 2010 (các lỗi đã hiệu chỉnh ngày 3
tháng 1 năm 2011))2
W3C Recommendation: XQuery 1.0 and XPath 2.0 Functions and Operators (Second Edition), W3C
Recommendation 14 December 2010 (Khuyến cáo W3C: XQuery 1.0 và Xpath 2.0 Chức năng và toán
tử (xuất bản lần 2), Khuyến cáo W3C ngày 14 tháng 10 năm 2010 3)
W3C Recommendation: XML Schema Part 1: Structures Second Edition, W3C Recommendation 28
October 2004) (Khuyến cáo W3C: Lược đồ XML Phần 1: Các cấu trúc xuất bản lần 2, Khuyến cáo
W3C ngày 28 tháng 10 năm 20044)
W3C Recommendation: XML Schema Part 2: Datatypes Second Edition, W3C Recommendation 28
October 2004 (Khuyến cáo W3C: Lược đồ XML Phần 2: Các kiểu dữ liệu xuất bản lần 2, Khuyến cáo
W3C ngày 28 tháng 10 năm 20045)
4 Thuật ngữ và định nghĩa
Tiêu chuẩn này áp dụng các thuật ngữ và định nghĩa trong TCVN 11523-1 (ISO/IEC 24752-1) và TCVN
11523-4 (ISO/IEC 24752-4) và áp dụng thuật ngữ và định nghĩa sau đây
4.1
Thẻ ngữ cảnh (context element)
Thẻ có phần phụ thuộc gắn liền với nó.
5 Liên quan đến các tiêu chuẩn khác
5.1 Liên quan đến XML
Đặc tả này xác định ngôn ngữ dựa trên Ngôn ngữ đánh dấu mở rộng (XML). Đánh dấu trong XML có
phân biệt chữ hoa, chữ thường.
Các tên thẻ, các tên thuộc tính và các giá trị không thể định vị được, tức là chúng đồng nhất với tất cả
các ngôn ngữ quốc tế. Tuy nhiên, nội dung văn bản giữa các thẻ có thể là ngôn ngữ cụ thể. Với tất cả
các ngôn ngữ dựa vào XML, các ký tự khoảng trắng bao quanh các thẻ là không có nghĩa.
- Đặc tả này tận dụng khái niệm vùng tên XML để kích hoạt việc nhập các tên thẻ hoặc thuộc tính đã xác
định ở nơi khác.
Tất cả các tên của thẻ hoặc thuộc tính sử dụng trong tiêu chuẩn này mà không có tiền tố vùng tên
được xác định bởi bộ tiêu chuẩn này và là một phần của vùng tên với tham chiếu URI
http://openurc.org/ns/uisocketdesc-2. Nếu không được xác định như vùng tên mặc định thì nên sử
dụng định danh vùng tên ‘uis’.
Trong tiêu chuẩn này, các tiền tố vùng tên sau đây và các định danh vùng tên tương ứng được sử
dụng để tham chiếu các vùng tên nước ngoài:
- dc: Vùng tên của bộ phần tử siêu dữ liệu Dublin Core (http://purl.org/dc/elements/1.1/) (Bộ phần tử
xác định trong TCVN 7980 (ISO 15836));
- dcterms: Vùng tên về các thuật ngữ siêu dữ liệu DCMI (http://purl.oro/dc/terms);
- xsd: Vùng tên về lược đồ XML (http://www.w3.org/2001/XMLSchema):
- xsi: Vùng tên về đối tượng lược đồ XML (http://www.w3.org/2001/XMLSchema-instance).
Đối với định nghĩa lược đồ XML cho mô tả socket giao diện người sử dụng, xem Phụ lục A.
5.2 Biểu thức XPath
5.2.1 Khái quát
Đặc tả này sử dụng ngôn ngữ đường truyền (XPath) phiên bản 2.0 để ghi địa chỉ các thẻ trong socket.
Cụ thể, Xpath được sử dụng trong việc mô tả các phụ thuộc giữa các thẻ của socket.
Cú pháp XPath 2.0 được sử dụng không tương thích Xpath 1.0.
5.2.2 Sử dụng cú pháp và các ngữ nghĩa của XPath 2.0
Bộ tiêu chuẩn này sử dụng cú pháp và các ngữ nghĩa của XPath 2.0 với các bổ sung và các loại bỏ
sau đây:
a) Các biểu thức XPath phải được sử dụng trong UCS.
b) Ngữ cảnh biểu thức tĩnh (xem điều 2.1.1 trong XPath 2.0) phải được khởi tạo với các thành phần
sau đây:
1) “Chế độ tương thích với XPath 1.0” là false.
2) “Các vùng tên đã biết tĩnh” là các khai báo vùng tên nằm trong phạm vi đối với thẻ XML chứa biểu
thức XPath.
3) “Vùng tên của kiểu/thẻ mặc định” phải là vùng tên rỗng (liên quan đến các kiểu được xác định trong
mô tả socket, xem Điều 11).
4) “Vùng tên chức năng mặc định” phải là vùng tên chức năng chuẩn của XPath 2.0:
http://www.w3.org/2005/xpath-functions.
5) “Các định nghĩa lược đồ trong phạm vi” chỉ chứa “các kiểu lược đồ trong phạm vi” với nội dung sau
đây: Tất cả các kiểu vùng tên http://www.w3.org/2001/XMLSchema, như đã xác định trong điều 2.5.1
của XPath 2.0; và các kiểu cục bộ xác định trong phần của mô tả socket (xem Điều 11).
CHÚ THÍCH XPath 2.0 thêm vào các kiểu xác định trước sau đây cho các kiểu xác định trước của Định
nghĩa lược đồ XML Phần 2: sd:untyped, xsd:untypedAtomic, xsd:anyAtomicType,
xsd:dayTimeDuration, xsd:yearMonthDuration.
6 “Các biến trong phạm vi” là trống.
7 “Các chữ ký chức năng” phải là các chức năng của vùng tên http://www.w3.org/2005/ xpath-
functions, như đã xác định trong Xquery 1.0 và XPath 2.0 Các chức năng và các toán tử với các loại bỏ
như đã quy định trong điều 5.2.4; các chức năng xây dựng cho tất cả kiểu nguyên tử trong “các định
nghĩa lược đồ trong phạm vi”; và các chức năng bổ sung xác định trong 5.2.5.
CHÚ THÍCH Các thành phần sau đây của ngữ cảnh biểu thức tĩnh XPath 2.0 không được sử dụng
trong tiêu chuẩn này: “kiểu tĩnh mục ngữ cảnh”, “các đối chiếu đã biết tĩnh”, “các đối chiếu mặc định”,
“URI cơ sở”, “các tài liệu đã biết tĩnh”; và các chức năng bổ sung xác định trong điều 5.2.5.
c) Ngữ cảnh biểu thức động (xem điều 2.1.2 trong Xpath 2.0) phải được khởi tạo với các thành phần
- sau đây:
1) “Mục ngữ cảnh” phải là tập hoặc thẻ socket mà biểu thức Xpath được quy định là độc lập.
2) “Các giá trị biến” là trống.
3) “Các cài đặt chức năng” phải bao gồm việc cài đặt các chức năng của vùng tên
http://www.w3.org/2005/xpath-functions, như đã xác định trong Xquery 1.0 và XPath 2.0 Các chức
năng và các toán tử; các chức năng xây dựng đối với tất cả các kiểu nguyên tử trong “các định nghĩa
lược đồ trong phạm vi”; và các chức năng bổ sung xác định trong điều 5.2.5.
4) “dateTime hiện tại” phải là thời gian hiện tại với múi giờ địa phương của URC, biểu diễn như giá trị
của kiểu xsd:dateTime.
5) “múi giờ ngầm định” phải là múi giờ địa phương của URC.
CHÚ THÍCH Các thành phần sau đây của ngữ cảnh biểu thức động Xpath 2.0 không được sử dụng
trong tiêu chuẩn này: “mục ngữ cảnh”, “vị trí ngữ cảnh”, “kích cỡ ngữ cảnh”, “các tài liệu sẵn có”, “các
tập hợp sẵn có”, “tập hợp mặc định”.
d) Không có mô hình dữ liệu (đối tượng XDM). Các biểu thức và chức năng mà liên quan đến đối
tượng mô hình dữ liệu không được sử dụng trong các mô tả socket. Biểu thức mục ngữ cảnh (xem
điều 3.1.4 trong Xpath 2.0) không được sử dụng. Các biểu thức đường truyền (xem điều 3.2 trong
Xpath 2.0) không được sử dụng. Các thao tác tại nút như là so sánh nút (xem điều 3.5.3 trong Xpath
2.0) và các toán tử phép hợp, phép nhân logic và loại trừ
e) Việc đánh giá các biểu thức logic (AND/OR) phải chặt chẽ từ trái qua phải và không được đánh giá
toán hạng phải nếu kết quả được xác định bởi toán hạng trái. Tức là, với biểu thức có dạng “A và B”,
thì B không được đánh giá nếu A sai và trong trường hợp “A hoặc B” thì B không được đánh giá nếu A
sai. Ngoài ra, Các thao tác boolean phải thừa nhận giá trị “không xác định” (xem điều 5.2.3).
f) Cài đặt Xpath 2.0 phải dựa trên XML 1.0 và các vùng tên trong XML.
g) Cài đặt Xpath 2.0 có thể hỗ trợ trục vùng tên.
5.2.3 Giá trị không xác định
Bộ tiêu chuẩn này thêm vào giá trị “không xác định” như một giá trị đặc biệt cho tất cả các kiểu từ
Xpath 2.0 (xem điều 5.2.2) và các kiểu xác định (xem Điều 11).
Nếu mọi phần của biểu thức Xpath là không xác định thì toàn bộ biểu thức phải không xác định. Quy
tắc này không được áp dụng nếu kết quả của biểu thức được xác định mà không đánh giá mọi phần
không xác định của nó, dựa trên logic đánh giá.
VÍ DỤ Biểu thức sau đây sẽ không bao giờ đánh giá một kết quả không xác định. Nó cho kết quả đúng
nếu thẻ với id ‘myvar’ là sẵn có và có giá trị 4, nếu không thì nó cho kết quả sai.
uis:hasDefinedValue(‘myvar’) and uis:value(‘myvar’) eq 4
CHÚ THÍCH Các cài đặt có thể khác nhau miễn sao kết quả được đảm bảo. Ví dụ, sự loại trừ lỗi có thể
tăng để báo hiệu rằng biểu thức Xpath cho kết quả là “không xác định”.
5.2.4 Các chức năng XPath
Các chức năng Xpath sau đây có thể được sử dụng:
- Các chức năng của vùng tên http://www.w3.org/2005/xpath-functions như đã xác định trong các chức
năng và toán tử của Xquery 1.0 và Xpath 2.0
- Các chức năng của nhà xây dựng cho tất cả các kiểu nguyên từ trong “các định nghĩa lược đồ trong
phạm vi”
Với các loại trừ sau đây:
- Chức năng string [] chỉ được sử dụng với một đối số.
- Chức năng resolve-uri () không được sử dụng.
- Các chức năng liên quan đến Qname (Điều 11 của các chức năng và toán tử của Xquery 1.0 và xpath
2.0), các toán tử trên ký pháp (Điều 13) và các chức năng và toán tử trên các nút (Điều 14) không
được sử dụng.
- - Các chức năng ngữ cảnh sau đây (Điều 13 của các chức năng và toán tử của Xquery 1.0 và Xpath
2.0) không được sử dụng: vị trí, lần cuối, sự đối chiếu mặc định, uri cơ sở tĩnh.
Xpath 2.0 quy định các quy tắc chuyển đổi ngầm định giữa các kiểu áp dụng.
5.2.5 Các chức năng thêm vào
5.2.5.1 Khái quát
Bộ tiêu chuẩn này xác định các chức năng thêm vào sau đây được sử dụng trong việc thể hiện các phụ
thuộc socket.
CHÚ THÍCH Các chức năng này được xác định trong vùng tên http://openurc.org/ns/uisocketdesc-2.
Tiền tố vùng tên cho vùng tên này (ví dụ: “uis”) cần được khai báo trên một trong các thẻ XML chứa
biểu thức Xpath. Chú ý rằng tiền tố vùng tên cho “http://openurc.org/ns/uisocketdesc-2” phải luôn được
sử dụng cho các chức năng này vì vùng tên chức năng mặc định là “http://www.w3.org/2005/xpath-
functions” (vùng tên chức năng Xpath 2.0). Sử dụng thuộc tính “xmlns” để khai báo vùng tên XML mặc
định không thay đổi vùng tên chức năng mặc định.
5.2.5.2 xsd:anyType uis:value (đường truyền String)
Đây là chức năng mà lấy đối số đường truyền của biến, lệnh, thông báo socket hoặc thành phần có chỉ
số của nó và trả về giá trị hiện thời của biến, lệnh hoặc thông báo (thành phần) đó.
CHÚ THÍCH Kiểu giá trị trả về của chức năng uis:value [] giống với kiểu thẻ socket tham chiếu tới bởi
đổi số ‘đường truyền’. Chú ý rằng, mặc dù kiểu trả về tĩnh là xsd:anyType nhưng kiểu giá trị trả về động
luôn là giá trị cụ thể hơn (dẫn xuất từ kiểu tĩnh); nó có thể được truy vấn bởi toán tử boolean ‘đối tượng
của’.
Cú pháp sau đây được xác định cho đường truyền (trong ký pháp BNF mở rộng, xem ISO/IEC 14977)
— path = absolutePath | relativePath | shortcutPath;
— absolutePath = “/” , { setPath , “/” } elementPath;
— relativePath = ( “./” | ( “../” , { “../” } ) ) , { setPath, “/” } elementPath;
— shortcutPath = elementPath;
— setPath = setId , { “[“ , setIndex “]” };
— elementPath = normalElementPath | basicCommandPath | timedCommandPath | notifyPath;
— normalElementPath = elementId , { “[“ , elementIndex , “]” };
— basicCommandPath = elementId , { “[“ , elementIndex, “]” };
— timedCommandPath = elementId, { “[“, elementIndex , “]” }, [ “[ttc]”];
— notifyPath = elementld, {“[“, elementIndex, “]”} [ “[ttc]” ];
Đường truyền phải là đường truyền tuyệt đối, đường truyền tương đối hoặc đường truyền tắt.
Đường truyền tuyệt đối phải là một danh mục phân chia bằng dấu gạch chéo của các id của tập và id
của thẻ, đi trên đường truyền từ thẻ gốc (xem điều 6.1) xuống thẻ socket, với các chỉ số
trong các dấu ngoặc vuông bất cứ khi nào một tập hoặc thẻ có các thứ nguyên. Đường truyền tuyệt đối
phải bắt đầu với ký tự gạch chéo (“/”) thay thế cho thẻ gốc.
Đường truyền tương đối phải có mục ngữ cảnh (nút) như là thẻ hoặc tập socket xác định phần phụ
thuộc. Các đường truyền bắt đầu với “./” có mục ngữ cảnh như điểm bắt đầu cho đường truyền tiếp
theo. Các đường truyền bắt đầu với “./” tham chiếu đến cha của mục ngữ cảnh như đoạn đầu
tiên trong đường truyền. Mỗi “./” tiếp theo trong đường truyền tham chiếu đến nút cha kế tiếp về
phía gốc. Không có chỉ mục nào được quy định cho mọi tập hoặc thẻ thứ nguyên mà được tham chiếu
bởi “./” hoặc “../”. Tại thời gian chạy, các chỉ mục thiếu (bắt đầu từ gốc) sẽ được lấy từ tập/thẻ sở hữu
phần phụ thuộc. Mặt khác được quy định trong đường truyền tương đối. Điều đó có nghĩa là các
đường truyền tương đối xảy ra trên các tập hoặc thẻ thứ nguyên đang tham chiếu các thẻ với cùng một
tập các chỉ mục hoặc tập con từ đó (tức là chúng đang tham chiếu đến cùng “slice (phiến)” của các
thành phần).
Đường truyền tắt phải bỏ qua các id của tập và chỉ sử dụng id và các chỉ số của thẻ, nếu có. Nó không
có ký tự gạch chéo ở đầu (“/”). Đường truyền tắt không được sử dụng nếu đường truyền bao gồm tập
- thứ nguyên.
setld là phần giữ chỗ cho thuộc tính ‘id’ của thẻ (là một hình thức sơ khai của thẻ socket yêu
cầu). Đối với các thẻ thứ nguyên (tức là các thẻ với thuộc tính không trống ‘dim’) setIndex
là phần giữ chỗ cho giá trị chỉ số của thẻ với giá trị chỉ số tương thích với kiểu chỉ số liên quan.
Các thuộc tính không có thứ nguyên sẽ không có setIndex.
elementld là phần giữ chỗ với thuộc tính ‘id’ của (xem điều 8.1), thẻ (xem điều
9.1), hoặc phần tử . Đối với các thẻ thứ nguyên, elementIndex phải được sử dụng như một
phần giữ chỗ cho giá trị chỉ số của thẻ, với giá trị chỉ số thương thích với kiểu chỉ số liên quan. Các thẻ
không có thứ nguyên sẽ không có elementIndex.
- Đối với các thẻ của kiểu uis:timedCommand, bộ chọn “[ttc]” có thể được thêm vào tại
lúc kết thúc đường truyền.
- Đối với các thẻ với thuộc tính ‘timeout’, bộ chọn “[ttc]” có thể được thêm vào tại lúc kết thúc
đường truyền.
Đối số đường truyền phải là dạng chuỗi. Các ký tự sau đây phải được thoát ra ngoài nếu được sử
dụng là một phần của setIndex hoặc elementIndex. ‘^’ phải được sử dụng như ký tự thoát.
- “[“phải được mã hóa là “^[“
- “]”phải được mã hóa là “^]”
- “^” phải được mã hóa là “^^”
CHÚ THÍCH 2 Đối với các đường truyền mã hóa cứng (nghĩa là đường truyền được biết đến tại thời
điểm biên soạn), người thực thi có thể sử dụng chuỗi ký tự mà được bao quanh bởi dấu ngoặc đơn (‘)
hoặc dấu ngoặc kép (“). Đối với các đường truyền mà tính tại thời gian chạy (ví dụ khi tham chiếu các
biến như các giá trị chỉ số) thì người thực thi có thể sử dụng các thao tác chuỗi Xpath hợp lệ (xem điều
5.2) để móc nối chuỗi đường truyền khả thi. Xem các ví dụ bên dưới.
Giá trị trả về phải là giá trị hiện thời của thẻ socket đã quy định (hoặc thành phần của nó nếu nó là thẻ
thứ nguyên hoặc có tập thứ nguyên như một hình thức sơ khai). Đối với các kiểu lệnh mà không có
thông tin trạng thái (uis:voidCommand), thì chuỗi trống phải được trả về. Đối với lệnh kiểu
uis:basicCommand hoặc uis:timedCommand và không có elementIndex thì trạng thái (là chuỗi) của
lệnh hoặc thành phần của nó phải được trả về (xem điều 9.3). Đối với các lệnh của kiểu
uis:timedCommand và elementIndex của “ttc”, thời điểm hoàn thành (là chuỗi trong định dạng
xsd:duration) của lệnh hoặc thành phần của nó phải được trả về nếu nó được xác định, nếu không thì
chuỗi trống phải được trả về. Đối với thông báo mà không có elementIndex quy định thì trạng thái của
nó (là chuỗi) hoặc trạng thái của thành phần của nó phải được trả về (các giá trị trả về hợp lệ là “hoạt
động”, “không hoạt động” và “xếp chồng”). Đối với thông báo mà có elementIndex “ttc” thì giá trị cho
biết thời gian còn lại đến thời gian chờ (tính bằng giây) hoặc trạng thái của thành phần của nó phải
được trả về.
uis:value (đường truyền chuỗi) phải ước tính cho kết quả không xác định về các thẻ socket (hoặc các
thành phần của chúng) mà có giá trị/trạng thái không xác định. Trong trường hợp này, toàn bộ biểu
thức (uis:value (đường truyền) là một phần của) phải có kết quả không xác định.
VÍ DỤ 1 Biến của kiểu xsd:string với id “var” được xếp lồng vào bên trong hai tập với các id “outerSet”
và “innerSet”. Cả biến và mọi tập xếp lồng đều không có thứ nguyên. Một tập có thể tìm kiếm giá trị của
nó bởi một trong các biểu thức Xpath sau đây:
uis:value(“/outerSet/innerSet/var”)
uis:value(“var”)
VÍ DỤ 2 Lệnh của kiểu uis:timedCommand với id “cmd” được xếp lồng trong tập với id “setld”. Một tập
có thể tìm kiếm trạng thái của nó bởi một trong các biểu thức XPath sau đây:
uis:value(“/setld/cmd”)
uis:value(“cmd”)
Và một tập có thể tìm kiếm giá trị của thành phần “ttc” của nó bằng một trong các biểu thức XPath sau
đây:
uis:value(“/setld/cmd[ttc]”)
- uis:value(“cmd[ttc]”)
VÍ DỤ 3 Thông báo với id “notifyld” được xếp lồng trong tập với id “setld”. Một tập có thể tìm kiếm trạng
thái của nó bằng một trong các biểu thức XPath sau đây:
uis:value(“/setld/notifyld”)
uis:value(“notifyld”)
VÍ DỤ 4 Biến của kiểu xsd:string với id “var” có một thứ nguyên với kiểu chỉ số xsd:string. Nó được xếp
lồng trong thẻ tập phi thứ nguyên với id “setld”.
Một tập có thể tìm kiếm giá trị của thành phần với chỉ số “alpha” bằng một trong các biểu thức Xpath
sau đây:
uis:value(“/setld/var[alpha]”)
uis:value(“var[alpha]”)
Và giá trị của thành phần với chỉ số “3*[2^3]” bằng một trong các biểu thức XPath sau đây (chú ý rằng
“[“, “^” và “]” cần được thoát ra);
uis:value(“/setId/var[3*^[2^^3^]]”)
uis:value(“var[3*^[2^^3^]]”)
VÍ DỤ 5 Giống như ví dụ 4, nhưng việc tìm kiếm giá trị của thẻ với giá trị chỉ mục lấy từ biến trừ
id=”index”:
uis:value(concat(“/setId/var[“, uis:value(“index”), ”]”))
uis:value(concat(“var[“, uis:value(“index”), ”]”))
VÍ DỤ 6 Lệnh của kiểu uis:timedCommand với id “cmd” có một thứ nguyên với kiểu chỉ số xsd:integer.
Nó được xếp lồng trong thẻ tập phi thứ nguyên với id “setId”. Một tập có thể tìm kiếm trường “ttc” của
lệnh với chỉ số 0 bằng một trong các biểu thức XPath sau đây:
uis:value(“/setld/cmd[0][ttc]”)
uis:value(“cmd[0][ttc]”)
VÍ DỤ 7 Biến của kiểu xsd:string với id “var” có hai thứ nguyên với các kiểu chỉ số xsd:integer và
xsd:string. Nó được xếp lồng trong thẻ tập phi thứ nguyên với id “setld”. Một tập có thể tìm kiếm giá trị
của thành phần với các chỉ số “3” và “none” bằng một trong các biểu thức XPath sau đây:
uis:value(“/setId/var[3][none]”)
uis:value(“var[3][none]”)
VÍ DỤ 8 Biến của kiểu xsd:string với id “var” có hai thứ nguyên với các kiểu chỉ số xsd:integer và
xsd:string. Nó được xếp lồng trong thẻ tập ngoài 1 thứ nguyên với id “outerSet” và kiểu chỉ số
xsd:boolean, và thẻ tập bên trong phi thứ nguyên với id “innerSet”. Một tập có thể tìm kiếm giá trị của
thành phần với các chỉ số “true” (đối với thẻ outerSet), “3” và “none” (đối với thẻ var) bằng biểu thức
Xpath sau đây:
uis:value(“/outerSet[true]/innerSet/var[3][none]”)
VÍ DỤ 9 Giống với ví dụ 8, nhưng sử dụng các giá trị của ba biến khác (với các id “index1”, “index2” và
“index3”) như các giá trị chỉ số:
uis:value(concat(“/outerSet[“, uis:value(“index1”), ”]/innerSet/var[“, uis:value(“index2”), ”][“,
uis:value(“index3”), ”]”))
VÍ DỤ 10 Ví dụ này minh họa việc sử dụng các đường truyền tương đối. Socket cực tiểu sau đây xác
định một tập 1- thứ nguyên với kiểu chỉ số xsd:integer. Đối với mỗi đối tượng của tập, biến “power” và
biến “dimmer” được xác định. Giá trị “dimmer” chỉ có thể được thay đổi nếu công tắc của đèn bật.
(đường truyền “../power” trong phần phụ thuộc ghi của biến dimmer liên quan đến biến “power” với chỉ
số cho tập cha phải giống với biến “dimmer” mà chứa phần phụ thuộc ghi).
- VÍ DỤ 11 Ví dụ này sử dụng đường truyền tương đối bên trong phần phụ thuộc của tập. Đối
với mỗi đối tượng của tập, một đối tượng của biến (với id=“isRelevant’) bên trong đối tượng của tập
đang điều khiển xem liệu đối tượng của tập có được đưa ra cho người sử dụng hay không.
5.2.5.3 boolean uis:hasDefinedValue (đường truyền chuỗi)
Đây là chức năng mà lấy đối số đường truyền của biến hoặc lệnh socket và phải trả về giá trị “true”.
Nếu giá trị hiện thời của biến hoặc lệnh đó được xác định, ngược lại là “false”. Đối với các kiểu lệnh mà
không có thông tin trạng thái (uis:voidCommand), “false” phải được trả về.
Đường truyền đối số biểu thị biểu thức Xpath mà phải đánh giá một chuỗi.
CHÚ THÍCH Bởi vì Xpath biểu thị các toán tử “hoặc” và “và” cho nên toán hạng phải không được đánh
giá nếu toán hạng trái xác định trước kết quả. XPath có thể kiểm tra các giá trị/trạng thái không xác
định bằng cách gọi uis:hasDefinedValue(id) trước khi gọi uis:value(id).
VÍ DỤ Biểu thức sau đây sẽ không bao giờ đánh giá giá trị không xác định. Nó cho giá trị true nếu lệnh
với id ‘reset’ có trạng thái không xác định hoặc trạng thái ‘thành công’.
not(uis:hasDefinedValue(‘reset’)) or uis:value(‘reset’) eq ‘succeeded’
5.2.5.4 boolean uis:isAvailable(đường truyền chuỗi)
- Đây là chức năng mà lấy đối số của nó là đường truyền của thẻ socket (biến, lệnh hoặc thông báo) và
phải trả về giá trị “true” nếu thẻ socket là sẵn có tại thời gian chạy, cách khác là “false”.
Đường truyền đối số biểu thị biểu thức Xpath mà phải đánh giá một chuỗi.
CHÚ THÍCH 1 Các thẻ socket có thể được đánh dấu là tùy chọn trong mô tả socket. Đối với các thẻ
socket đó, đường truyền đối số có thể được xác định tại thời gian chạy bằng cách gọi uis:Available ()
liệu chúng có sẵn có hay không.
CHÚ THÍCH 2 Bởi vì Xpath biểu thị các toán tử “hoặc” và “và” cho nên toán hạng phải không được
đánh giá nêu toán hạng trái xác định trước kết quả, đường truyền đối số có thể kiểm tra tính sẵn có
của thẻ socket bằng cách gọi uis:hasAvailable(id) trước khi gọi uis:hasDefinedValue(id).
VÍ DỤ Biểu thức sau đây chỉ đánh giá là true nếu biến ‘powerstate’ là sẵn có, xác định và có giá trị
“standby”
uis:isAvailable(‘powerstate’) and uis:hasDefinedValue(‘powerstate’) and uis:value(‘reset’) eq ‘standby
5.2.5.5 boolean uis:isNotifyActive()
Chức năng này không lấy đối số và phải trả về Boolean. Nó phải trả về giá trị “true” nếu mọi thẻ
trong socket hoạt động, và “false” nếu không có thẻ hoạt động.
CHÚ THÍCH Biểu thức Xpath “not(uis:isNotifyActive())” có thể có ích để kiểm tra chế độ thông thường
(tức là không có thông báo nào hoạt động)
5.2.5.6 boolean uis:sessionForward (kiểu string, uri chuỗi)
Chức năng này trình bày việc chuyển tiếp phiên (xem TCVN 11523-1 (ISO/IEC 24752-1)). Giá trị của
đối số kiểu phải là “destructive” hoặc “spawn”. Giá trị của đối số uri phải là tên (URI) của socket mà
URC được chuyển tiếp đến. Giá trị trả về phải là “true”. Nếu đích gửi sự kiện chuyển tiếp phiên đã quy
định đến URC, mặt khác là “false”. Chức năng này có thể được sử dụng trong các điều kiện sau các
lệnh socket (xem điều 9.9.5), để cung cấp một gợi ý cho URC mà lệnh có thể kích khởi việc chuyển
tiếp phiên.
6 Cấu trúc của mô tả socket
6.1 Khái quát
Mô tả socket phải là tài liệu XML với thẻ là thẻ gốc của vùng tên
“http://openurc.org/ns/uisocketdesc-2”.
Tài liệu mô tả socket phải được mã hóa trong UCS theo TCVN 8271 (ISO/IEC 10646). Đối với việc mã
hóa ký tự thì “UTF-8” hoặc “UTF-16” phải được sử dụng.
Mô tả socket phải có kiểu MIME “application/urc-uisocketdesc+xml” nếu thích hợp. Thông số ‘charset’
(xem IETF RFC 3023) nên được sử dụng để quy định việc mã hóa ký tự của mô tả socket. Giá trị của
nó phải là “UTF-8” hoặc “UTF-16”. Nếu thông số ‘charset’ vắng mặt thì thủ tục quy định trong “Ngôn
ngữ đánh dấu mở rộng (XML) 1.0 (xuất bản lần 5)” điều 4.3.3 phải được làm theo để xác định việc mã
hóa ký tự.
Các đoạn sau đây mô tả chi tiết hơn các thuộc tính và các thẻ con của thẻ .
VÍ DỤ Xem đoạn sau đây:
- 6.2 Thuộc tính ‘about’
Thẻ phải có thuộc tính ‘about’. Thuộc tính ‘about’ tham chiếu socket được mô tả bởi mô tả
socket. Giá trị của thuộc tính ‘about’ phải được quy định là nội dung thẻ và phải là tên của socket biểu
diễn như một URI. URI có thể hoặc không thể giải quyết được.
CHÚ THÍCH 1 Các nhà sản xuất đích được khuyến khích tạo các mô tả socket của các sản phẩm của
họ sẵn có bằng cách gửi mô tả socket tại tên URI của socket.
Điển hình, URI này được dẫn xuất từ URI của đích bởi sự ghép nối với nhau.
VÍ DỤ http://example.com/taraet/socket: nếu URI của đích là http://example.com/target.
CHÚ THÍCH 2 Cùng một URI được sử dụng như tham chiếu socket trong mô tả socket (thuộc tính
‘about’ của thẻ ) và tên của socket trong mô tả socket (thuộc tính ‘name’ của thẻ
tương ứng). Tham chiếu phần 4 của bộ tiêu chuẩn này để biết thêm chi tiết về mô tả đích.
6.3 Thuộc tính ‘id’
Thẻ phải có thuộc tính ‘id’ mà quy định định danh là duy nhất trong số tất cả các id trong
mô tả socket.
CHÚ THÍCH Định danh được sử dụng để quy định các tài nguyên bên ngoài cho thẻ gốc mô tả socket,
như đã lấy ví dụ minh họa trong phần 5 của bộ tiêu chuẩn này.
6.4 Thuộc tính ‘sufficient’
Thẻ phải có thuộc tính ‘sufficient’ của kiểu Boolean. Giá trị mặc định của nó phải là ‘false’.
Giá trị ‘true’ cho biết tất cả các lệnh trong mô tả socket mà không có thuộc tính ‘sufficient’, được quy
định đầy đủ trong điều 9.5.
CHÚ THÍCH Thuộc tính ‘sufficient’ cho được cung cấp để thuận tiện cho người thực thi. Nó
được ghi chèn bởi các thuộc tính ‘sufficient’ riêng biệt trên các thẻ đơn lẻ (xem điều 9.1).
6.5 Thuộc tính ‘complete’
Thẻ có thể có thuộc tính ‘complete’ của kiểu Boolean. Giá trị mặc định phải là “false”.
Giá trị ‘true’ cho biết tất cả các lệnh trong mô tả socket mà không có thuộc tính ‘complete’, được quy
định đầy đủ trong điều 9.6.
CHÚ THÍCH Thuộc tính ‘complete’ cho được cung cấp để thuận tiện cho người thực thi. Nó
được ghi chèn bởi các thuộc tính ‘complete’ riêng biệt trên các thẻ đơn lẻ (xem điều 9.1).
6.6 Thuộc tính ‘extends’
Socket có thể mở rộng một hoặc nhiều socket khác (tức là kế thừa từ một hoặc nhiều socket). Socket
mà là phần mở rộng của một hoặc nhiều socket khác được gọi là “socket con” và các socket mà nó mở
rộng được gọi là “siêu socket”.
Một socket con phải kế thừa các mục sau đây từ các siêu socket của nó:
- Tất cả các tập
- Tất cả các biến, lệnh và thông báo (với các kiểu của chúng)
- Tất cả các xác định kiểu và thẻ bên trong (từ phần )
CHÚ THÍCH 1 Bộ chứa socket (thẻ ) không được kế thừa.
CHÚ THÍCH 2 Các tham chiếu vùng tên không được kế thừa. Nếu socket con thêm vào một biến với
xác định kiểu biên ngoài thì nó phải khai báo vùng tên cho kiểu bên ngoài dù là vùng tên được khai báo
trong siêu socket rồi.
- Thẻ phải có thuộc tính ‘extends’ với danh mục phân cách bằng khoảng trống các tên
socket (URIs), quy định một danh mục các siêu socket có thứ tự mà siêu socket kế thừa từ đó.
VÍ DỤ Socket với tên “http://example.com/thermometerplus/socker mở rộng socket với tên
http://example.com/thermometer/socket. Cá hình elip cho biết sự bỏ qua mã.
…
Trong trường hợp mà cùng một định danh (giá trị của thuộc tính ‘id’) xuất hiện trên các thẻ socket của
một hoặc nhiều siêu socket và/hoặc socket con, lần xuất hiện cuối cùng phải ghi chèn lên các lần xuất
hiện trước đó, tức là các lần xuất hiện trước đó của các thẻ socket không được kế thừa bởi socket con.
Các siêu socket đến trước theo thứ tự của chúng sau đó là socket con. Thứ tự giữa các siêu socket
được xác định bởi thứ tự mà các tên (URIs) của các socket xuất hiện trong giá trị của thuộc tính
‘extends’.
Nếu thẻ của socket con ghi chèn lên thẻ của siêu socket (bằng cách sử dụng cùng một định danh), thẻ
của siêu socket tương ứng không được kế thừa thành socket con, tức là socket con cuối cùng chỉ
chứa thẻ tương ứng như đã quy định trong mô tả socket con.
Nếu thẻ của siêu socket ghi chèn lên một hoặc nhiều thẻ của siêu socket khác bằng cách sử dụng
cùng một định danh thì các thẻ được ghi chèn (tất cả trừ thẻ cuối cùng) được xem là không tồn tại và
chỉ một thẻ tương ứng của siêu socket cuối cùng phải được kế thừa thành siêu socket (trừ khi có một
thẻ với cùng một định danh xác định trong socket con nếu vậy, thẻ socket con sẽ ghi chèn lên tất cả
các thẻ siêu socket với cùng một định danh).
6.7 Thẻ
Thẻ phải có thẻ con quy định một tham chiếu đến chuẩn đã thiết
lập mà socket phù hợp với nó. Giá trị được cung cấp như nội dung thẻ URI. Giá trị
http://openurc.org/ns/uisocketdesc-2/isoiec24752-2-2013 cho biết socket đã mô tả phù hợp với tiêu
chuẩn này.
CHÚ THÍCH 1 Giá trị của thẻ có thể được sử dụng khi kiểm tra sự phù hợp của
mô tả socket.
CHÚ THÍCH 2 phù hợp với việc lọc thẻ siêu dữ liệu Dublin Core conformsTo,
http://purl.org/dc/terms/conformsTo là việc lọc thẻ Dublin Core http://purl.Org/dc/elements/1.t/relation.
VÍ DỤ http://openurc.org/ns/ uisocketdesc-2/isoiec24752-2-
2013/dcterms:conformsTo
6.8 Thẻ
Thẻ có thể bao gồm thẻ . Điều này cho biết rằng tài liệu mô tả socket
được sửa đổi từ phiên bản gốc của nó trong khi vẫn sử dụng cùng socket tham chiếu URI trong thuộc
tính ‘about’ của nó.(xem điều 6.2). Nội dung của nó là kiểu xsd:date hoặc xsd:dateTime.
CHÚ THÍCH phù hợp với việc lọc thẻ siêu dữ liệu Dublin Cor modified http.//purl.
oro/dc/terms/modified.
VÍ DỤ 2004-01-30
Mô tả socket nên giữ ổn định nhất có thể. Tài liệu mô tả socket mà được thay đổi phải được gán một
cái mới về URI (như đã quy định trong điều 6.2) hoặc phải thay đổi giá trị của thẻ .
6.9 Các đặc tính mô tả socket từ DCMI
Mọi thẻ và việc lọc thẻ (ngoại trừ và ) mà được tham chiếu
ở trên) từ TCVN 7980 (ISO 15836), Bộ phần tử Dublin Core, hoặc tập các thuật ngữ siêu dữ liệu của
sáng kiến siêu dữ liệu Dublin Core (DCMI) có thể được sử dụng để mô tả mô tả socket nếu thích hợp.
Mỗi thuật ngữ có thể xuất hiện nhiều lần như các thẻ con của thẻ .
- Cụ thể, các thẻ siêu dữ liệu Dublin Core sau đây có thể được áp dụng:
- - quy định người thực thi mô tả socket
- - quy định người cung cấp mô tả socket
- - quy định người cùng thực thi mô tả socket
-- quy định tên của socket thay thế để truy cập cùng một chức năng hoặc chức
năng tương tự
- - quy định tên của socket chính trong số tập socket thay thế để truy cập cùng
một chức năng hoặc chức năng tương tự
6.10 Các thẻ , , và
Thẻ phải chứa tập hoàn thiện các thẻ (xem Điều 8), (xem Điều 9)
và (xem Điều 10) thu nạp tất cả các thông tin mà được người sử dụng nhận biết hoặc vận
dụng và tất cả các lệnh sẵn có cho người sử dụng đích. Các thẻ này có thể được kết cấu qua thẻ
(xem Điều 7) mà có thể được xếp lồng, sắp xếp thứ tự ngầm định phải được bao hàm bởi thứ tự
các thẻ xuất hiện trong tài liệu mô tả socket.
6.11 Các thẻ lược đồ kiểu XSD
Mô tả socket có thể chứa khai báo lược đồ kiểu XSD. Nó được sử dụng để xác định các kiểu bên trong
trong socket như đã mô tả trong Điều 11.
6.12 Thông tin ánh xạ về nền tảng cho các socket
Thẻ có thể được sử dụng số lần như thẻ con của để bao gồm thông tin ánh xạ
về nền tảng liên quan đến socket.
Thẻ phải có thuộc tính ‘platform’ mà giá trị của nó không được giới hạn bởi bộ tiêu chuẩn
này.
Thẻ có thể có nội dung thẻ và các thẻ con bất kỳ. Tuy nhiên, các thẻ con từ các vùng tên
trừ vùng tên uis.
CHÚ THÍCH 1 Các mô tả socket mà chứa thông tin ánh xạ về nền tảng số mất tính trung lập của
chúng. Mặc dù nhiều ánh xạ có thể được quy định trong mô tả socket (một ánh xạ cho mỗi nền tảng)
nhưng nó được khuyến cáo xem xét các cơ chế khác về việc quy định sự liên kết với các công nghệ
đặc trưng cho nền tảng. Ví dụ, thông tin ánh xạ có thể được cung cấp trong tệp bên ngoài với các tham
chiếu tới các thẻ của mô tả socket.
CHÚ THÍCH 2 Nhà cung cấp và nhà vận tải nền tảng bị ngăn sử dụng thẻ để gắn nội dung
có thể thực hiện được trong mô tả socket. Điều này đưa ra một rủi ro an toàn cho các thành phần phân
tích mô tả socket và thực thi nội dung.
7 Các tập
7.1 Khái quát
Các tập trình bày cấu trúc phân cấp bên trong của socket giao diện người sử dụng. Các tập có thể
được xếp lồng (tức là thẻ có thể xuất hiện trong thẻ khác).
CHÚ THÍCH Thẻ xác định trong bộ tiêu chuẩn này nhằm cung cấp cấu trúc phân cấp bên trong
socket. “Các tài nguyên tạo nhóm” (như đã xác định trong TCVN 11523-5 (ISO/IEC 24752-5)) có thể
được sử dụng để quy định các cấu trúc tạo nhóm biểu diễn (có thể không phải phân cấp), hoặc tạo
nhóm trình diễn có thể được chứa trong mô tả cài đặt giao diện người sử dụng (UIID, xem TCVN
11523-1 (ISO/IEC 24752-1)).
7.2 Thuộc tính ‘id’
Thẻ phải có thuộc tính ‘id’
Thuộc tính ‘id’ phải là kiểu ID như đã xác định bởi Lược đồ XML Phần 2 : Các kiểu dữ liệu. Thuộc tính
id cung cấp định danh mà được sử dụng để tham chiếu đến thẻ trong mô tả socket và là phương tiện
liên kết bên ngoài các tài nguyên xác định như là các nhãn. Giá trị ‘id’ phải là duy nhất trong số tất cả
các thuộc tính ‘id’ và ‘name’ trong mô tả socket.
CHÚ THÍCH Các giá trị thuộc tính ‘id’ không được đưa ra cho người sử dụng và con người cũng không
- cần hiểu nó.
VÍ DỤ
7.3 Thuộc tính ‘dim’
Thuộc tính ‘dim’ quy định tập thứ nguyên (với một hoặc nhiều thứ nguyên). Tại thời gian chạy, tập
được tạo đối tượng một lần cho mỗi kết hợp các giá trị chỉ số của nó. Điều này dẫn tới nhiều giá trị cho
mỗi thẻ socket mà được chứa (trực tiếp hoặc gián tiếp) tập thứ nguyên.
CHÚ THÍCH 1 Không có việc sắp xếp thứ tự rõ ràng xác định cho các đối tượng do tập thứ nguyên.
Tuy nhiên, việc sắp xếp thứ tự dựa trên thứ tự của các giá trị chỉ số được khuyến cáo cho đích - trong
quá trình truyền tải các đối tượng đến URC - và cho URC - trong việc đưa ra các đối tượng cho người
sử dụng (xem TCVN 11523-1 (ISO/IEC 24752-1)).
CHÚ THÍCH 2 Phần phụ thuộc quy định liệu URC có thể thay đổi tập các chỉ số ở thời gian
chạy hay không (xem điều 7.4.4).
Nếu các tập thứ nguyên được xếp lồng với nhau thì các giá trị cho các thẻ socket dựa trên mỗi kết hợp
hiện có của tập các giá trị chỉ số của tất cả các tập thứ nguyên liên quan, cộng với các giá trị chỉ số của
chính thẻ socket nếu nó là thứ nguyên.
CHÚ THÍCH 3 Nói cách khác, tập tối đa các giá trị cho thẻ socket riêng do sản phẩm của tất cả các
kiểu chỉ số mà xuất hiện khi đi trên đường truyền từ thẻ xuống thẻ socket riêng (xem định
nghĩa đường truyền trong điều 5.2.5.2). Tuy nhiên, không phải mỗi kết hợp có thể xảy xa tại thời gian
chạy.
CHÚ THÍCH 4 Tập thứ nguyên cũng được gọi là “tập lặp lại”.
Thuộc tính ‘dim’ có thể hiện diện cho các thẻ . Nếu hiện diện, nó phải chứa danh mục không
trống, có thứ tự, phân cách bằng khoảng trống của các tham chiếu kiểu mà là các kiểu chỉ số của tập.
Tham chiếu đầu tiên quy định kiểu chỉ số cho thứ nguyên đầu tiên, kiểu thứ hai cho thứ nguyên thứ hai,
v.v...Các tham chiếu kiểu chỉ số hợp lệ là (a) tên của kiểu mà được xác định trong phần
của mô tả socket, hoặc (b) tên định tính (QName) của kiểu bên ngoài.
CHÚ THÍCH 5 Một tập có thể có một chỉ số của kiểu với tập không giới, hạn các giá trị chỉ số. Tuy
nhiên, tại thời gian chạy tập con vô hạn các giá trị kiểu chỉ số sẽ được sử dụng như các chỉ số thực
của tập thứ nguyên.
VÍ DỤ Ứng dụng chương trình trộn âm kết hợp hai dòng đầu vào thành một dòng đầu ra. Mỗi dòng có
hai cài đặt âm thanh (âm lượng và độ to) và lệnh “break” là lệnh chặn kênh trong 5 giây.
- CHÚ THÍCH 6 Các tham chiếu (ví dụ: từ các tài nguyên nguyên tử) đến các tập thứ nguyên tham chiếu
đến các thành phần đơn lẻ của tập . Trong ví dụ trên, URI “http://example.com/mixer/socket#stream”
tham chiếu đến mọi thành phần tập đơn lẻ bao gồm biến ‘volume’, biến ‘loudness’ và lệnh ‘break’. Tuy
nhiên, URI “http://example.com/mixer/socket#dims(stream)” tham chiếu đến toàn bộ tập với tất cả các
thành phần, tức là đến tất cả các kênh như một thực thể phức hợp. Xem TCVN 11523-5(ISO/IEC
24752-5) để biết thêm chi tiết.
CHÚ THÍCH 7 Thứ tự mà các thành phần của tập thứ nguyên được đưa ra cho người sử dụng, dựa
trên việc sắp xếp thứ tự các kiểu chỉ số thích hợp. Xem TCVN 11523-1 (ISO/IEC 24752-1) để biết thêm
chi tiết.
7.4 Các phần phụ thuộc của tập
7.4.1 Khái quát
Thẻ có thể hiện diện trong thẻ . Nếu hiện diện thì sẽ xuất hiện một lần.
7.4.2 Phần phụ thuộc
Phần phụ thuộc có thể hiện diện như thẻ con của thẻ trên các tập. Nếu hiện
diện thì nó sẽ xuất hiện một lần.
Nội dung của thẻ phải được quy định cho phần phụ thuộc của các biến (xem
điều 8.9.2).
Một tập phải kế thừa phần phụ thuộc của nó cho các đối tượng của nó (gắn với các tập, các
biến, các lệnh và các thông báo), trừ khi đối tượng tự quy định phần phụ thuộc .
CHÚ THÍCH Sự kế thừa các phần phụ thuộc tạo thuận lợi cho người thực thi quy định phần phụ thuộc
một lần (trên mức tập) mà chung cho tất cả các đối tượng của nó.
7.4.3 Phần phụ thuộc
Phần phụ thuộc có thể hiện diện như thẻ con của thẻ trên các tập. Nếu hiện
diện thì nó sẽ xuất hiện một lần.
Nội dung của thẻ phải được quy định cho phần phụ thuộc của các biến (xem
điều 8.9.2).
Một tập phải kế thừa phần phụ thuộc của nó cho các đối tượng của nó (gắn với các tập, các
biến, các lệnh và các thông báo), trừ khi đối tượng tự quy định phần phụ thuộc .
7.4.4 Phần phụ thuộc
Phần phụ thuộc quy định liệu người sử dụng có thể sửa đổi tập các liên kết chỉ số hợp lệ tại
thời gian chạy hay không (với tập đang nói đến là các chỉ số quy định bởi thuộc tính ‘dim’ trên thẻ
tương ứng).
Nội dung của phần phụ thuộc phải là một biểu thức Xpath đánh giá giá trị Boolean mà có thể
thay đổi trong suốt một phiên. Nếu nó đánh giá là false thì sẽ không thích hợp để thêm vào hoặc xóa
- một liên kết chỉ số; mặt khác biểu thức Xpath cố gắng thêm vào hoặc xóa một liên kết chỉ số mặc dù
không có sự đảm bảo rằng nó sẽ thành công.
CHÚ THÍCH 1 “Thêm vào một liên kết chỉ số” có nghĩa là thêm vào thành phần của mỗi thẻ socket
chứa trong thẻ tương ứng, đối với một liên kết chỉ số mới trong khoảng trống chỉ số xác định bởi
thuộc tính ‘dim’ tương ứng. Chú ý rằng các giá trị ban đầu của các thành phần mới được định rõ bởi
đích. “Bỏ đi một liên kết chỉ số” có nghĩa là xóa một thành phần của mỗi thẻ socket chứa trong thẻ
tương ứng, đối với một liên kết chỉ số riêng hiện đang diễn ra.
Phần phụ thuộc có thể hiện diện như thẻ con của thẻ trên các tập thứ nguyên
(tức là các tập với thuộc tính ‘dim’, xem điều 7.3). Nếu hiện diện thì nó sẽ xảy ra một lần.
Giá trị mặc định của nó phải là “false()”.
CHÚ THÍCH 2 Phần phụ thuộc trên một tập quy định nếu chỉ số có thể được chèn vào (hoặc
bỏ đi) chỉ dành cho các thứ nguyên mà gắn liền với tập. Nếu thẻ socket bên dưới tập này có các thứ
nguyên khác (từ các tập mà là hình thức sơ khai của thẻ đó hoặc bởi vì nó là phân tử thứ nguyên), các
thứ nguyên này có thể có các phần phụ thuộc xung đột. Trong trường hợp này, liệu việc thêm
vào hoặc bỏ đi liên kết chỉ số cho thẻ đó là thích hợp hay không và tùy thuộc vào đích để quyết định
dựa trên cơ sở riêng lẻ.
7.5 Thông tin ánh xạ về nền tảng cho các tập
Thẻ có thể được sử dụng số lần như thẻ con của bao gồm thông tin ánh xạ về nền
tảng cho tập.
Thẻ phải có thuộc tính ‘platform’ mà giá trị của nó không được giới hạn bởi bộ tiêu chuẩn
này.
Thẻ có thể có nội dung thẻ và các thẻ con bất kỳ. Tuy nhiên, các thẻ con từ các vùng tên
trừ vùng tên uis.
CHÚ THÍCH 1 Các mô tả socket mà chứa thông tin ánh xạ về nền tảng sẽ mất tính trung lập của
chúng. Mặc dù nhiều ánh xạ có thể được quy định trong mô tả socket (một ánh xạ cho mỗi nền tảng)
nhưng nó được khuyến cáo xem xét các cơ chế khác về việc quy định sự liên kết với các công nghệ
đặc trưng cho nền tảng. Ví dụ, thông tin ánh xạ có thể được cung cấp trong tệp bên ngoài với các tham
chiếu tới các thẻ của mô tả socket.
CHÚ THÍCH 2 Nhà cung cấp và nhà vận tải nền tảng bị ngăn sử dụng thẻ để gắn nội dung
có thể thực hiện được trong mô tả socket. Điều này đưa ra một rủi ro an toàn cho các thành phần phân
tích mô tả socket và thực thi nội dung.
7.6 Các đặc tính của tập từ DCMI
Mọi thẻ hoặc bộ lọc phần tử từ TCVN 7980 (ISO 15836), Bộ phần tử siêu dữ liệu Dublin Core, hoặc
Thuật ngữ siêu dữ liệu của sáng kiến siêu dữ liệu Dublin Core (DCMI) có thể được sử dụng để mô tả
thẻ , nếu thích hợp. Mỗi thuật ngữ có thể xuất hiện nhiều lần như thẻ con của thẻ .
7.7 Thành phần của tập
Thẻ phải chứa tập các thẻ không rỗng , (xem điều 8.1), hoặc như là các
đối tượng.
8 Biến
8.1 Khái quát
Các biến được sử dụng để trình bày trạng thái của đích cho URC. Giá trị của biến có thể được biểu
diễn cho người sử dụng URC và người sử dụng có thể thay đổi trạng thái của đích bằng cách thay đổi
giá trị của biến.
Thẻ có thể xuất hiện như thẻ con của (xem Điều 7), hoặc nhưng thẻ con của
(xem điều 6.1),
VÍ DỤ Các ví dụ về các biến bao gồm kênh hiện tại chiếu trên tivi và giá trị (không được chỉ cho người
sử dụng) cho biết liệu người sử dụng hiện tại có chấp nhận các điều khoản về bản quyền hay không.
8.2 Thuộc tính ‘id’
Thẻ (xem điều 8.1) phải có thuộc tính ‘id’.
- Thuộc tính ‘id’ phải là kiểu ID như đã xác định bởi Lược đồ XML Phần 2 : Các kiểu dữ liệu. Thuộc tính
id cung cấp định danh mà được sử dụng để tham chiếu đến thẻ trong mô tả socket và là phương tiện
liên kết bên ngoài các tài nguyên xác định như là các nhãn. Giá trị ‘id’ phải là duy nhất trong số tất cả
các thuộc tính ‘id’ và ‘name’ trong mô tả socket.
CHÚ THÍCH Các giá trị thuộc tính ‘id’ không được đưa ra cho người sử dụng và con người cũng không
cần hiểu nó.
VÍ DỤ
8.3 Thuộc tính ‘type’
8.3.1 Khái quát
Thẻ (xem điều .1) phải có thuộc tính ‘type’.
Nếu biến có thuộc tính ‘dim’ (xem điều 8.8) thì thuộc tính ‘type’ sẽ quy định kiểu của một trong các giá
trị của biến (“mảng đồng nhất”).
8.3.2 Các kiểu đơn giản
Mọi kiểu đơn giản xác định trong Lược đồ XML phần 2 đều có thể được sử dụng như kiểu biến hoặc
mọi kiểu đơn giản khác dẫn xuất từ một trong các kiểu này (bao gồm việc dẫn xuất bằng danh mục
hoặc phép hợp).
CHÚ THÍCH Việc sử dụng các khai báo tập dữ liệu từ Lược đồ XML Phần 2 không hàm ý rằng các giá
trị được mã hóa như đã xác định bởi Lược đồ XML. Đây là sự cài đặt phụ thuộc và không được xác
định bởi bộ tiêu chuẩn này. Ví dụ, biến của kiểu xsd:integer có thể được biểu diễn trong socket như giá
trị nhị phân và không phải là chuỗi.
8.3.3 Các danh mục giá trị phân cách bằng khoảng trống
Mọi kiểu mà được dẫn xuất bằng danh mục theo Lược đồ XML phần 2 có thể được sử dụng như kiểu
biến. Nếu sử dụng cho biến thì kiểu danh mục phải được xác định trong phần xác định kiểu của mô tả
socket (xem Điều 11). Mặt khác, kiểu xác định trước uis:stringList có thể được sử dụng nếu tập các
mục chuỗi không bị giới hạn (xem điều 11.3).
Nhằm mục đích biểu diễn các phần phụ thuộc trong cú pháp Xpath 2.0 (xem điều 5.2), giá trị của biến
danh mục phải được coi là chuỗi kiểu nguyên tử mà nó được dẫn xuất.
8.3.4 Các danh mục giá trị phân cách bằng dấu phẩy
Kiểu xác định trước uis:csvlist có thể được sử dụng như kiểu biến tham chiếu tới danh mục các giá trị
chuỗi, biểu diễn móc nối các chuỗi riêng lẻ với nhau và phân cách bằng dấu phẩy đơn (‘,’).
Các quy ước thoát sử dụng ký tự gạch chéo ‘\’ (mã ký tự UTF-8 0x5C) như sau: ký tự gạch chéo (‘\’)
được biểu diễn là ‘\\’ và dấu phẩy (‘,’) là ‘\’ trong các mục nhập chuỗi riêng lẻ trong các danh mục CSV.
Mọi ký tự khoảng trống trắng xuất hiện được giải thích là một phần của các mục nhập chuỗi.
Nhằm mục đích trình bày các phần phụ thuộc trong cú pháp Xpath 2.0 (xem điều 5.2), giá trị của biến
uis:csvlist phải được coi như kiểu xsd:string (xem điều 5.2.2).
CHÚ THÍCH 1 Xpath 2.0 cung cấp các chức năng cho các thủ thuật chuỗi có thể được sử dụng để xem
xét các giá trị của các biến danh mục phân cách bằng dấu phẩy, khi sử dụng trong các biểu thức phụ
thuộc. Các cài đặt URC có thể tạo các giá trị riêng lẻ của danh mục phân cách bằng dấu phẩy sẵn có
cho UIIDs thông qua API của nó nhưng đây là cài đặt cụ thể.
CHÚ THÍCH 2 Kiểu uis:csvlist là một thay thế cho uis:stringList (xem điều 11.3).
CHÚ THÍCH 3 uis:csvlist đặc biệt có ích cho một trường UPnP AV ở đó một số giá trị được truyền tải là
các danh mục giá trị phân cách bằng dấu phẩy. Chú ý rằng uis:csvlist chỉ tính đến các mục nhập của
kiểu string.
CHÚ THÍCH 4 Trái với bộ tiêu chuẩn TCVN 11523 (ISO/IEC 24752), Các đặc tả UPnP AV chỉ ra liệu
chuỗi trống có được giải thích là danh mục trống hoặc danh mục với một mục nhập chuỗi trống hay
không.
VÍ DỤ 1 “1, 2, 3” biểu diễn danh sách với ba mục nhập chuỗi: “1”, “2” và “3”.
VÍ DỤ 2 “Smith\, Fred, Jones\, Davey” biểu diễn danh mục hai chuỗi: “Smith, Fred” and “Jones, Davey”.
- VÍ DỤ 3 “alpha, beta” biểu diễn danh mục hai chuỗi, mỗi chuỗi với hai khoảng trống ở đầu: “alpha” và
“beta”.
VÍ DỤ 4 “,,” biểu diễn danh mục ba mục nhập chuỗi trống (mỗi chuỗi là “”)
VÍ DỤ 5 “ ” biểu diễn một danh mục trống (không có mục nhập).
8.3.5 Các kiểu dòng
Đối với các biến socket mà truyền tải các dòng văn bản, audio hoặc video, các kiểu xác định trước sau
đây có thể được sử dụng như cá giá trị cho thuộc tính ‘type’:
-“uis:textStreamOut”: Dòng văn bản chảy từ đích đến URC (khách).
-“uis:textStreamIn”: Dòng văn bản chảy từ URC đến đích.
-“uis:audioStreamOut”: Dòng audio chảy từ đích đến URC.
-“uis:audioStreamln”: Dòng audio chảy từ URC đến đích.
-“uis:videoStreamOut”: Dòng video chảy từ đích đến URC
-“uis:videoStreamln”: . Dòng video chảy từ URC đến đích
-“uis:multiMediaStreamOut”: Dòng giữ một liên kết đồng bộ hóa của video, audio và văn bản chảy từ
đích đến URC.
- “uis:multiMediaStreamln”: Dòng giữ một liên kết đồng bộ hóa của video, audio và văn bản chảy từ
URC đến đích.
Định dạng và giao thức truyền của mọi kiểu dòng này là cài đặt cụ thể và không được biết đến trước
thời gian chạy. Tuy nhiên, nếu tập các định dạng hỗ trợ đích được biết đến trước thời gian chạy thì thẻ
từ DCMI (xem điều 8.12) nên được sử dụng (bất kỳ số lần thích hợp nào) như thẻ con của
(xem điều 8.1) để quy định các định dạng sẵn có, mỗi định dạng mã hóa như kiểu MIME
(xem IETF RFC 2046).
Cũng như vậy, nếu dòng được biết đến là đặc trưng cho ngôn ngữ tự nhiên trước thời gian chạy, thẻ
từ DCMI (xem điều 8.12) nên được sử dụng như thẻ con của (xem điều 8.1)
để quy định ngôn ngữ.
CHÚ THÍCH 1 Khuyến cáo rằng các cài đặt socket và TUNs đề cập đến thỏa thuận định dạng tạo dòng
giữa URC và đích tại thời gian chạy.
CHÚ THÍCH 2 Sự hiện diện của biến kiểu dòng trong mô tả socket cho các mục đích mô tả và không
hàm ý rằng dòng được nói đến “chạy qua” cài đặt socket tại thời gian chạy. Các cài đặt tự do vận dụng
các dòng theo cách phù hợp với các yêu cầu cụ thể. Ví dụ, cài đặt socket có thể giúp thiết lập kết nối
để tạo dòng, với dòng thực tế bỏ qua cài đặt socket vì các lý do hiệu suất.
8.3.6 Các kiểu bên trong socket
Các kiểu cung cấp XSD (xem điều 8.3.2) không đủ để trình bày khoảng trống giá trị của biến dưới dạng
các giá trị cho phép và không cho phép. Trong các trường hợp này, thuộc tính ‘type’ của biến có thể
tham chiếu các kiểu bên trong socket, tức là các kiểu mà được xác định trong các phần riêng biệt của
mô tả socket, như đã quy định trong điều 10.12. Tham chiếu đến kiểu bên trong socket phải bao gồm
tên của kiểu mà không có bất kỳ tiền tố vùng tên nào.
8.3.7 Các kiểu nhập
Các kiểu xác định trong các vùng tên khác có thể được tên định tính đầy đủ của chúng (QName).
Trong trường hợp này, vùng tên URI phải được quy định đầy đủ và vị trí của tệp xác định lược đồ XML
thích hợp (XSD) nên được đưa ra qua thuộc tính ‘xsi:schemaLocation’.
CHÚ THÍCH Socket có thể coi các giá trị của kiểu nhập bên trong là kiểu string, cụ thể khi sử dụng bên
trong các biểu thức Xpath (xem điều 5.2) cho các phần phụ thuộc. Giả thiết việc không kiểm tra dựa
vào sự định hình hoặc tính chất hợp lệ. Tuy nhiên, có thể tạo các giá trị của kiểu nhập sẵn có trong
định dạng đặc biệt thông qua API. Ví dụ, nó có thể đưa ra API dựa trên DOM cho các biến của các kiểu
nhập nhưng đây là cài đặt cụ thể.
VÍ DỤ Biến này chưa mô tả nội dung của dịch vụ thư mục nội dung. Mô tả là kiểu DIDLType, như đã
xác định bởi DIDL (“Ngôn ngữ khai báo mục số”) vùng tên urn:mpeg:mpeg21:2002:02-DIDL-NS. Tệp
XSD thích hợp sẵn có tại http://standards.iso.org/ittf/PubliclyAvailableStandards/MPEG-21 schema
- files/did/didl.xsd.
8.4 Thuộc tính ‘secret’
Các thẻ (xem điều 8.1) có thể có thuộc tính ‘secret’. Đó là kiểu dữ liệu Boolean cho biết liệu
giá trị của biến là nhạy cảm liên quan đến an toàn và quyền riêng tư hay không và yêu cầu việc bảo vệ
để hỗ trợ quyền riêng tư của người sử dụng.
Giá trị mặc định phải là “false”
VÍ DỤ Mật khẩu có thể được khai báo là:
Nếu biến có thuộc tính ‘dim’ (xem điều 8.8) thì thuộc tính ‘secret’ gắn với một trong các giá trị của biến.
8.5 Thuộc tính ‘sensitive’
Thẻ (xem điều 8.1) có thể có thuộc tính ‘sensitive’. Đó là kiểu dữ liệu Boolean cho biết liệu
biến có được đưa ra cho người sử dụng với tất cả các trường hợp hay không.
Giá trị mặc định là “false”.
VÍ DỤ Biến đánh dấu với sensitive = “true” có thể biểu diễn thông tin an toàn và đảm bảo được đưa ra
cho người sử dụng:
Nếu biến có thuộc tính ‘dim’ (xem điều 8.8) thì thuộc tính ‘sensitive’ sẽ gắn với một trong các giá trị của
biến.
8.6 Thuộc tính ‘optional’
Biến có thể có một thuộc tính ‘optional’ của kiểu Boolean. Giá trị mặc định của nó phải là “false”.
Nếu optional = “true” thì biến không sẵn có tại thời gian chạy do các ràng buộc khác nhau. Nếu biến
không sẵn có tại thời gian chạy thì giá trị của nó phải là không xác định và tính không sẵn có phải được
chỉ ra cho URC tại thời gian chạy.
VÍ DỤ Nếu sử dụng trong các biểu thức phụ thuộc thì biến tùy chọn có thể được kiểm tra nếu nó có giá
trị xác định trước khi tự truy cập giá trị:
uis:hasDefinedValue(‘myvar’) and uis:value(‘myvar’) eq 4
CHÚ THÍCH 1 Các ví dụ về các ràng buộc tác động đến tính sẵn có của thẻ socket là: điều khiển truy
- cập, các sản phẩm khác nhau sử dụng mô tả socket chung với một số biến đổi về cài đặt (như là trong
UPnP DCPs).
CHÚ THÍCH 2 Tính sẵn có của thẻ socket phải được chỉ ra cho URC tại thời gian chạy thông qua
phương tiện đặc trưng cho TUN (xem TCVN 11523-1 (ISO/IEC 24752-1)).
Nếu biến có thuộc tính ‘dim’ (xem điều 8.8) thì thuộc tính ‘optional’ sẽ gắn với biến toàn bộ, tức là nó
tồn tại như biến thứ nguyên hoặc không tồn tại chút nào.
8.7 Thuộc tính ‘final’
Một số biến được cung cấp ban đầu bởi đích tại phiên mở và không bao giờ thay đổi trong suốt phiên.
Các biến này được đánh dấu với final = “true”.
Thẻ (xem điều 8.1) có thể có thuộc tính ‘final’ kiểu Boolean. Giá trị mặc định phải là “false”.
VÍ DỤ
CHÚ THÍCH Biến cuối cùng không thể được ghi bởi người sử dụng và do đó không có phần phụ thuộc
(xem điều 8.9.3).
Nếu biếu có thuộc tính ‘dim’ (xem điều 8.8) thì thuộc tính ‘final’ sẽ gắn với biến toàn bộ, tức là tất cả
các giá trị của nó được khởi tạo bởi đích tại phiên mở và sẽ không bao giờ thay đổi trong suốt phiên.
8.8 Thuộc tính ‘dim’
Thuộc tính ‘dim’ quy định các biến như thứ nguyên (với một hoặc nhiều thứ nguyên). Tại thời gian
chạy, biến thứ nguyên có nhiều giá trị, mỗi giá trị dành cho một liên kết các chỉ số riêng.
CHÚ THÍCH 1 Biến 1-dimensional là một mảng với 1 chỉ số, biến 2-dimensional là một bảng (mặc dù
bảng có thể được gắn vào thưa thớt).
CHÚ THÍCH 2 Không có việc sắp xếp thứ tự rõ ràng xác định cho các giá trị do biến thứ nguyên. Tuy
nhiên, việc sắp xếp thứ tự các giá trị dựa trên thứ tự của các giá trị chỉ số được khuyến cáo cho đích -
trong việc truyền tải các giá trị cho URC - và cho URC - trong việc đưa ra các giá trị cho người sử dụng
(xem TCVN 11523-1 (ISO/IEC 24752-1)).
CHÚ THÍCH 3 Tập lớn nhất của các giá trị cho biến socket riêng do sản phẩm của tất cả các kiểu chỉ
số mà xuất hiện khi đi trên đường truyền từ thẻ xuống biến socket riêng (xem định nghĩa
đường truyền trong điều 5.2.5.2). Tuy nhiên, không phải mọi liên kết có thể xuất hiện tại thời gian chạy.
Thuộc tính ‘dim’ có thể hiện diện cho các biến. Nếu hiện diện thì nó phải chứa danh sách không trống,
có thứ tự, phân cách bằng khoảng trống của các tham chiếu kiểu mà là các kiểu chỉ số của biến. Tham
chiếu đầu tiên quy định kiểu chỉ số cho thứ nguyên đầu tiên, kiểu thứ hai cho thứ nguyên thứ hai,
v.v...Các tham chiếu kiểu chỉ số hợp lệ là (a) tên của kiểu mà được xác định trong phần
của mô tả socket, hoặc (b) tên định tính (QName) của kiểu bên ngoài.
CHÚ THÍCH 4 Kiểu chỉ số có thể quy định số giá trị chỉ số không giới hạn (ví dụ: xsd:integer có các giá
trị không giới hạn). Tuy nhiên, các giá trị chỉ số thực tế tại thời gian chạy là tập con không giới hạn của
các giá trị được cho phép bởi kiểu chỉ số.
CHÚ THÍCH 5 Biến thứ nguyên là tương tự với “các mảng kết hợp” trong một số ngôn ngữ lập trình, ví
dụ: JavaSript.
CHÚ THÍCH 6 Thuộc tính ‘type’ của biến thứ nguyên quy định kiểu của mỗi giá trị chứa trong biến đó,
và không phải toàn bộ các kiểu của biến (là một mảng).
VÍ DỤ 1 Âm lượng của hệ thống âm thanh 5.1 có thể được xác định như một vector của các giá trị
nguyên 6, mỗi giá trị giữa 0 và 100. Mỗi giá trị biểu diễn âm lượng cho kênh riêng.
- CHÚ THÍCH 7 Các tham chiếu (ví dụ: từ các tài nguyên nguyên tử) đến các biến thứ nguyên tham
chiếu đến các thành phần đơn lẻ của biến. Trong ví dụ trên, URI
“http://example.com/sound/socket#volume” tham chiếu đến mọi thành phần tập đơn lẻ bao gồm biến
‘volume’, biến ‘loudness’ và lệnh ‘break’. Tuy nhiên, URI
“http://example.com/sound/socket#dims(volume)” tham chiếu đến toàn bộ tập với tất cả các thành
phần, tức là đến tất cả các kênh như một thực thể phức hợp. Xem TCVN 11523-5 (ISO/IEC 24752-5)
để biết thêm chi tiết.
CHÚ THÍCH 8 Thứ tự mà các thành phần của tập thứ nguyên được đưa ra cho người sử dụng, dựa
trên việc sắp xếp thứ tự các kiểu chỉ số thích hợp. Xem TCVN 11523-1 (ISO/IEC 24752-1) để biết thêm
chi tiết.
8.9 Các phần phụ thuộc của biến
nguon tai.lieu . vn
