TIÊU CHUẨN QUỐC GIA TCVN 11523-2:2016 (ISO/IEC 24752-2:2014) VỀ 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

Hiệu lực: Còn hiệu lực Ngày có hiệu lực: 30/12/2016

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ẻ <uis:uiSocket> (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 20103)

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 <xsd:schema> 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 <uiSocket> (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 <set> 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 <set> 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ẻ <set> (là một hình thức sơ khai của thẻ socket yêu cầu). Đối với các thẻ <set> thứ nguyên (tức là các thẻ <set> 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ẻ <set> 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 <set> 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 <variable> (xem điều 8.1), thẻ <command> (xem điều 9.1), hoặc phần tử <notify>. Đố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ẻ <conmmand> 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ẻ <notify> 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 <relevant> 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ẻ <notify> trong socket hoạt động, và “false” nếu không có thẻ <notify> 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ẻ <uiSocket> 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ẻ <uiSocket>.

VÍ DỤ Xem đoạn sau đây:

6.2 Thuộc tính ‘about’

Thẻ <uiSocket> 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ẻ <uiSocket>) và tên của socket trong mô tả socket (thuộc tính ‘name’ của thẻ <socket> 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ẻ <uiSocket> 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ẻ <uiSocket> 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 <uiSocket> đượ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ẻ <command> đơn lẻ (xem điều 9.1).

6.5 Thuộc tính ‘complete’

Thẻ <uiSocket> 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 <uiSocket> đượ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ẻ <command> đơ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 <xsd:schema>)

CHÚ THÍCH 1 Bộ chứa socket (thẻ <uiSocket>) 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ẻ <uiSocket> 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ã.

<uiSocket

about=“http://example.com/thermometerplus/socket” extends=“http://example.com/thermometer/socket”

id=“socket”

xmlns=“http://openurc.org/ns/uisocketdesc-2”>

…

</uiSocket>

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ẻ <dcterms:conformsTo>

Thẻ <uiSocket> phải có thẻ con <dcterms:conformsTo> 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ẻ <dcterms:conformsTo> có thể được sử dụng khi kiểm tra sự phù hợp của mô tả socket.

CHÚ THÍCH 2 <dcterms:conformsTo> 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Ụ <dcterms:conformsTo>http://openurc.org/ns/ uisocketdesc-2/isoiec24752-2-2013/dcterms:conformsTo

6.8 Thẻ <dcterms:modified>

Thẻ <uiSocket> có thể bao gồm thẻ <dcterms:modified>. Đ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 <dcterms:modified> 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Ụ <dcterms:modified> 2004-01-30 </dcterms:modified>

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ẻ <dcterms:modified>.

6.9 Các đặc tính mô tả socket từ DCMI

Mọi thẻ và việc lọc thẻ (ngoại trừ <dcterms:conformsTo> và <dcterms:modified>) 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ẻ <uiSocket>.

Cụ thể, các thẻ siêu dữ liệu Dublin Core sau đây có thể được áp dụng:

– <dc:creator> – quy định người thực thi mô tả socket

– <dc:publisher> – quy định người cung cấp mô tả socket

– <dc:contributor>- quy định người cùng thực thi mô tả socket

-<dcterms:hasVersion>- 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ự

– <dcterms:isVersionOf> – 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ẻ <variable>, <command>, <notify> và <set>

Thẻ <uiSocket> phải chứa tập hoàn thiện các thẻ <variable> (xem Điều 8), <command> (xem Điều 9) và <notify> (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ẻ <set> (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ẻ <mapping> có thể được sử dụng số lần như thẻ con của <uiSocket> để bao gồm thông tin ánh xạ về nền tảng liên quan đến socket.

Thẻ <mapping> 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ẻ <mapping> 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ẻ <mapping> để 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ẻ <set> có thể xuất hiện trong thẻ <set> khác).

CHÚ THÍCH Thẻ <set> 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ẻ <set> 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Ụ <set id=“mainSet”>

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 <insert> 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ẻ <uiSocket> 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ẻ <set>. 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 <xsd:schema> 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ẻ <dependency> có thể hiện diện trong thẻ <set>. Nếu hiện diện thì sẽ xuất hiện một lần.

7.4.2 Phần phụ thuộc <relevant>

Phần phụ thuộc <relevant> có thể hiện diện như thẻ con của thẻ <dependency> 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ẻ <relevant> phải được quy định cho phần phụ thuộc <relevant> 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 <relevant> 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 <relevant>.

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 <write>

Phần phụ thuộc <write> có thể hiện diện như thẻ con của thẻ <dependency> 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ẻ <relevant> phải được quy định cho phần phụ thuộc <relevant> 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 <write> 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 <write>.

7.4.4 Phần phụ thuộc <insert>

Phần phụ thuộc <insert> 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ẻ <set> tương ứng).

Nội dung của phần phụ thuộc <insert> 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ẻ <set> 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ẻ <set> 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 <insert> có thể hiện diện như thẻ con của thẻ <dependency> 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 <insert> 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 <lnsert> 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ẻ <mapping> có thể được sử dụng số lần như thẻ con của <set> bao gồm thông tin ánh xạ về nền tảng cho tập.

Thẻ <mapping> 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ẻ <mapping> 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.

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ẻ <set>, 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ẻ <set>.

7.7 Thành phần của tập

Thẻ <set> phải chứa tập các thẻ không rỗng <set>, <variable> (xem điều 8.1), hoặc <notify> 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ẻ <variable> có thể xuất hiện như thẻ con của <set> (xem Điều 7), hoặc nhưng thẻ con của <uiSocket> (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ẻ <variable> (xem điều 8.1) phải có thuộc tính ‘id’.

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Ụ <variablc id=“tvVolume” type=“xsd:decimal”/>

8.3 Thuộc tính ‘type’

8.3.1 Khái quát

Thẻ <variable> (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ẻ <dc:format> 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 <variable> (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ẻ <dc:language> từ DCMI (xem điều 8.12) nên được sử dụng như thẻ con của <variable> (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ẻ <variable>(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ẻ <variable> (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ị:

<write> uis:hasDefinedValue(‘myvar’) and uis:value(‘myvar’) eq 4 </write>

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ẻ <variable> (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Ụ <variable id=“serialNumber” type=“xsd:integer’’ final=“true” />

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 <write> (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ẻ <uiSocket> 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 <xsd:schema> 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

8.9.1 Khái quát

Các phần phụ thuộc của biến diễn tả khi biến là thích hợp và người sử dụng có thể ghi lại được và các phần phụ thuộc giữa các giá trị của biến đang tồn tại.

Tất cả các phần phụ thuộc phải được mã hóa như các biểu thức Xpath và được đánh giá tại thời gian chạy. Một số kiểu phụ thuộc có thể thay đổi trong suốt phiên.

Các phần phụ thuộc của biến phải được quy định bằng cách gắn chúng trong thẻ biến sử dụng ký tự đánh dấu:

<relevant>exprl</relevant>

</dependency>

Thẻ <dependency> có thể hiện diện như thẻ con của <variable> (xem điều 8.1). Nếu hiện diện nó sẽ xuất hiện một lần.

8.9.2 Phần phụ thuộc <relevant>

Phần phụ thuộc <relevant> quy định khi biến có thể được đưa ra cho người sử dụng, tức là nó được dựa trên trạng thái riêng của đích như thế nào. Nếu phần phụ thuộc <relevant> là true thì biến phải được đưa ra cho người sử dụng. Điều này không nhất thiết mang ý nghĩa là nó có thể truy cập trực tiếp trong giao diện người sử dụng dẫn xuất từ socket nhưng có một số đường truyền điều hứng mà người sử dụng có thể tìm thấy nó.

Thẻ <relevant> có thể hiện diện như thẻ con của <dependency> (xem điều 8.9.1). Nếu hiện diện nó sẽ xuất hiện một lần. Nếu không hiện diện thì biến sẽ kế thừa phần phụ thuộc <relevant> từ thẻ <set> sơ khai gần nhất mà có phần phụ thuộc <relevant> đã quy định (xem điều 7.4.2).

VÍ DỤ Biến biểu diễn số người trong danh sách chỉ có thể sẵn có nếu biến ‘userType’ có giá trị “student”:

<relevant> uis:value(‘userType’) eq ‘student’ </relevant

</dependency>

Nội dung của thẻ <relevant> phải là biểu thức Xpath hợp lệ (với các phần mở rộng cho phép như đã quy định trong điều 5.2) mà đánh giá giá trị của Number hoặc Boolean. Các số phải nằm trong dải [0.0, 1.0] (cả 0.0 và 1.0 được bao gồm). Điều này đề cập đến các mức độ thích đáng có thứ tự với ý nghĩa các số cao hơn “thích đáng” hơn các số thấp hơn. 0.0 là “không thích đáng” và 1.0 là “liên quan”. Nếu biểu thức Xpath đánh giá trị Boolean, “true” phải được giải thích là 1.0, và “false” là 0.0.

CHÚ THÍCH Kết quả của biểu thích Xpath có thể thay đổi trong suốt phiên.

Nếu không có phần phụ thuộc <relevant> được quy định (cả trên biến và trên mọi tập sơ khai) hoặc nếu nó là trống thì phần phụ thuộc (relevant) của biến phải luôn là true, thậm chí khi thẻ <notify> hoạt động.

8.9.3 Phần phụ thuộc <write>

Phần phụ thuộc <write> quy định liệu người sử dụng có thể thay đổi giá trị của biến hay không. Nếu phần phụ thuộc <write> là false thì nó không thích hợp để sửa đổi giá trị của biến, nếu không thì nó sẽ thích hợp để thiết lập một giá trị mới mặc dù không đảm bảo rằng sẽ thành công.

Thẻ <write> có thể hiện diện như thẻ con của <dependency> (xem điều 8.9.1) nếu thuộc tính ‘final’ (xem điều 8.7) là ‘false’ hoặc không hiện diện trên biến được nói đến. Nếu hiện diện nó sẽ xuất hiện một lần. Nếu không hiện diện thì biến sẽ kế thừa phần phụ thuộc <write> từ thẻ <set> sơ khai gần nhất mà có phần phụ thuộc <relevant> đã quy định (xem điều 8.9.3).

VÍ DỤ 1 Hệ thống đặt chỗ khách sạn có thể có biến đối với kiểu thanh toán tín dụng mà chỉ có thể được ghi lại nếu người sử dụng lựa chọn trả bằng thẻ tín dụng. Phần phụ thuộc này có thẻ được thể hiện như sau:

<write> uis:value(‘creditPayment’) </write>

</variable>

VÍ DỤ Các phần phụ thuộc có thể được sử dụng để biểu diễn việc sắp xếp thứ tự các ràng buộc. Ví dụ, các biến của dịch vụ chỉ có thể ghi lại được sau khi người sử dụng chấp nhận các điều khoản đăng ký. Sự chấp nhận của người sử dụng có thể được biểu diễn như biến có kiểu dữ liệu Boolean với id = “warrantySigned” và các biến khác có các thuộc tính write của dạng:

<write> uis:value(‘warrantySigned’) </write>

</variable>

Nội dung của thẻ <write> phải là trống hoặc biểu thức XPath hợp lệ (với các phần mở rộng cho phép như đã quy định trong điều 5.2) đánh giá giá trị Boolean.

CHÚ THÍCH 1 Kết quả của biểu thức XPath có thể thay đổi trong suốt phiên.

Nếu thẻ <write> của biến là trống hoặc nếu nó kế thừa phần phụ thuộc <write> trống từ một tập sơ khai thì phần phụ thuộc <write> của biến phải là ẩn số.

CHÚ THÍCH 2 Việc giới thiệu một giá trị ẩn là tương tự với kiểu logic Boolean có giá trị 3 mà chú ý đến tính bất định. Nếu phần phụ thuộc <write> là ẩn thì URC không có sự lựa chọn nào khác là tìm hiểu xem liệu nó có thể thay đổi biến hay không.

Nếu không có phần phụ thuộc <write> được quy định (trên biến hoặc trên mọi tập sơ khai) thì phần phụ thuộc <write> của biến phải luôn là true thậm chí khi thẻ <notify> hoạt động.

8.9.4 Phần phụ thuộc <insert>

Phần phụ thuộc <insert> 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 là các chỉ số được quy định bởi thuộc tính ‘dim’ trên thẻ <variable> tương ứng, xem điều 8.8).

Nội dung của phần phụ thuộc <insert> phải là biểu thức XPath mà đánh giá giá trị Boolean có thể thay đổi trong suố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 đi một liên kết chỉ số nếu không thì sẽ thích hợp để thêm vào hoặc xóa đi một liên kết chỉ số mặc dù không có sự đảm bảo rằng điều đó 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 một thành phần biến cho 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 giá trị ban đầu của thành phần biến mới được định rõ bởi đích. “Xóa đi một liên kết chỉ số” có nghĩa là xóa đi thành phần biến đối với liên kết chỉ số riêng mà đang xảy ra.

Thẻ <insert> có thể hiện diện như thẻ con của <dependency> (xem điều 8.9.1) nếu biến tương ứng có thuộc tính ‘dim’ (xem điều 8.8) và không phải thuộc tính cuối cùng (xem điều 8.7). Nếu hiện diện thì sẽ xuất hiện một lần.

Giá trị mặc định của nó phải là “false()”.

CHÚ THÍCH 2 Không có sự kế thừa từ phần phụ thuộc <insert> của thẻ <set> tới phần phụ thuộc của thẻ <variable> chứa đựng (xem điều 8.1). Mỗi phần phụ thuộc <insert> chỉ gắn liền với tập các chỉ số được quy định bởi thuộc tính ‘dim’ của mức tương ứng.

VÍ DỤ Với mô tả socket sau đây, việc minh họa một bảng với các hang và các cột, URC có thể yêu cầu thêm vào hoặc xóa đi một hàng (index), nhưng không phải cột (index).

<insert> false () </insert>

</dependency>

</variable>

</set>

8.9.5 Phần phụ thuộc <length>

Thẻ <length> quy định biểu thức XPath (với cú pháp xác định trong điều 5.2) đánh giá một số. Số này quy định độ dài cho phép của biến tại thời gian chạy. Nó sẽ không thay đổi trong suốt thời gian chạy.

CHÚ THÍCH Cách xử lý trong trường hợp phần phụ thuộc <length> thay đổi là không xác định. Ví dụ, URC có thể bỏ qua mọi thay đổi. Công cụ kiểm tra sự phù hợp có thể từ chối các phần phụ thuộc <length> mà tham chiếu các thẻ socket trừ các biến cuối cùng.

Thẻ <length> có thể xuất hiện như thẻ con của <dependency>(xem điều 8.9.1), chỉ khi kiểu của biến đang nói tới là xsd:string hoặc dẫn xuất từ xsd:string. Nếu hiện diện thì sẽ xuất hiện một lần.

VÍ DỤ 1 Biểu thức sau đây quy định ràng buộc độ dài của 5:

VÍ DỤ 2 Biểu thức sau đây quy định rằng giá trị của biến (cuối cùng) với id ‘lengthVar’ được sử dụng như ràng buộc về độ dài:

<length> uis:value(“lengthVar”) </length>

Thẻ <length> chỉ nên được sử dụng nếu độ dài cho phép phải được đĩnh rõ tại lúc khởi tạo phiên, liên quan đến các phần tư socket. Nếu biến có ràng buộc về độ dài mà có thể được định rõ trước thời gian chạy thì nó sẽ diễn tả ràng buộc này thông qua kiểu được xác định trong phần <xsd:schema> (xem Điều 11) của mô tả socket. Nếu biến có ràng buộc về độ dài trên kiểu của nó và thông qua thẻ <length> thì chúng phải dẫn đến cùng một số.

8.9.6 Phần phụ thuộc <minLength>

Thẻ <minlength> quy định biểu thức XPath (với cú pháp xác định trong điều 5.2) đánh giá một số. Số này quy định độ dài tối thiểu của biến tại thời gian chạy. Nó sẽ không thay đổi trong suốt phiên.

CHÚ THÍCHn Cách xử lý trong trường hợp phần phụ thuộc <minLength> thay đổi là không xác định.

Thẻ <minLength> có thể xuất hiện như thẻ con của <dependency>(xem điều 8.9.1), chỉ khi kiểu của biến đang nói tới là xsd:string hoặc dẫn xuất từ xsd:string. Nếu hiện diện thì sẽ xuất hiện một lần.

Thẻ <minlength> chỉ nên được sử dụng nếu độ dài tối thiểu cho phép phải được đĩnh rõ tại lúc khởi tạo phiên, liên quan đến các phần tư socket. Nếu biến có ràng buộc về độ dài tối thiểu mà có thể được định rõ trước thời gian chạy thì nó sẽ diễn tả ràng buộc này thông qua kiểu được xác định trong phần <xsd:schema> (xem Điều 11) của mô tả socket. Nếu biến có ràng buộc về độ dài tối thiểu trên kiểu của nó và thông qua thẻ <length> thì biến phải phù hợp với cả hai (tức là số cao hơn được dùng như độ dài tối thiểu)

8.9.7 Phần phụ thuộc <maxLength>

Thẻ <maxlength> quy định biểu thức XPath (với cú pháp xác định trong điều 5.2) đánh giá một số. Số này quy định độ dài tối đa của biến tại thời gian chạy. Nó sẽ không thay đổi trong suốt phiên.

CHÚ THÍCH Cách xử lý trong trường hợp phần phụ thuộc <maxLength> thay đổi là không xác định.

Thẻ <maxLength> có thể xuất hiện như thẻ con của <dependency>(xem điều 8.9.1), chỉ khi kiểu của biến đang nói tới là xsd:string hoặc dẫn xuất từ xsd:string. Nếu hiện diện thì sẽ xuất hiện một lần.

Thẻ <maxlength> chỉ nên được sử dụng nếu độ dài tối đa cho phép phải được đĩnh rõ tại lúc khởi tạo phiên, liên quan đến các phần tư socket. Nếu biến có ràng buộc về độ dài tối thiểu mà có thể được định rõ trước thời gian chạy thì nó sẽ diễn tả ràng buộc này thông qua kiểu được xác định trong phần <xsd:schema> (xem Điều 11) của mô tả socket. Nếu biến có ràng buộc về độ dài tối đa trên kiểu của nó và thông qua thẻ <length> thì biến phải phù hợp với cả hai (tức là số thấp hơn được dùng như độ dài tối đa)

8.9.8 Phần phụ thuộc <pattern>

Thẻ <pattern> quy định biểu thức XPath (với cú pháp xác định trong điều 5.2) đánh giá một chuỗi. Chuỗi này quy định biểu thức thường xác định một mẫu cho các giá trị cho phép của biến tại thời gian chạy. Cú pháp của mẫu được quy định cho diện ràng buộc ‘pattern’ trong Lược đồ XML Phần 2. Mẫu sẽ không thay đổi trong suốt phiên.

CHÚ THÍCH 1 Cách xử lý trong trường hợp phần phụ thuộc <pattern> là không xác định.

Thẻ <pattern> có thể xuất hiện một lần như thẻ con của <dependency> (xem điều 8.9.1) chỉ khi kiểu biến đang nói đến là xsd:string, hoặc dẫn xuất từ xsd:string.

CHÚ THÍCH 2 Nếu khoảng trống giá trị của biến cần được mô tả bởi một liên kết các mẫu thì các mẫu này có thể được ORed cùng nhau bởi toán tử “I” bên trong biểu thức thường.

VÍ DỤ 1 Biểu thức sau đây quy định mẫu cho việc biển diễn dựa trên chuỗi của mọi số nguyên dương:

VÍ DỤ 2 Biểu thức sau đây quy định rằng giá trị của biến (cuối cùng) ‘patternVar’ được sử dụng như mẫu:

<pattern> uis:value(“patternVar”)</pattern>

CHÚ THÍCH 3 Nếu mọi ký tự ‘&’, ‘<or>‘ xuất hiện bên trong <pattern> thì chúng cần được thoát ra khỏi XML

VÍ DỤ 3 Biểu thức sau đây quy định một mẫu cho các chuỗi như “A&A”, “A&B”, v.v…

Thẻ <pattern> chỉ được sử dụng nếu mẫu đã quy định được xác định lúc khởi tạo phiên, liên quan đến các thẻ socket khác. Nếu biến có ràng buộc về mẫu mà có thể được xác định trước thời gian chạy thì nó nên diễn tả ràng buộc này thông qua kiểu được xác định trong phần <xsd:schema> (xem Điều 11) của mô tả socket. Nếu biến là các ràng buộc về kiểu mẫu trên cả kiểu của nó và thông qua các thẻ <pattern> thì biến phải phù hợp với tất cả (chúng được ANDed với nhau).

8.9.9 Phần phụ thuộc <minlnclusive>

Thẻ <minlnclusive> quy định biểu thức XPath (với cú pháp xác định trong điều 5.2) đánh giá một giá trị của cùng một kiểu với biến mà nó thuộc về. Giá trị này quy định giá trị tối thiểu (bao gồm tất cả) của biến tại thời gian chạy. Nó sẽ không thay đổi trong suốt phiên.

CHÚ THÍCH 1 Cách xử lý trong trường hợp phần phụ thuộc <minlnclusive> thay đổi là không xác định.

Thẻ <minlnclusive> có thể xuất hiện như thẻ con của <dependency> (xem điều 8.9.1) nhưng chỉ khi biến đang nói đến có kiểu mà khoảng trống giá trị của nó được sắp xếp thứ tự toàn bộ. Nếu hiện diện thì nó sẽ xuất hiện một lần.

CHÚ THÍCH 2 Trong XML các kiểu dữ liệu dựng sẵn được sắp xếp thứ tự (ví dụ: xsd:string) hoặc chỉ được sắp xếp thứ tự một phần (ví dụ: xsd:time). Đối với các kiểu dữ liệu này, <minlnclusive> và các ràng buộc thời gian chạy khác yêu cầu quan hệ thứ tự toàn bộ không được sử dụng

VÍ DỤ 1 Biểu thức sau đây quy định 10 là giới hạn thấp hơn bao hàm cho biến của kiểu xsd:integer”

VÍ DỤ 2 Biểu thức sau đây quy định hai giá trị của biến cuối cùng với đi ‘lowerBound’ là giới hạn thấp hơn bao hàm cho biến của kiểu xsd:integer:

<minlnclusive> 2 * uis:value(“lowerBound”) </minInclusive>

Thẻ <minlnclusive> chỉ được sử dụng nếu giá trị tối thiểu cho phép phải được định rõ tại lúc khởi tạo phiên, liên quan đến các phần tư socket. Nếu biến có ràng buộc về giá trị tối thiểu mà có thể được định rõ trước thời gian chạy thì nó sẽ diễn tả ràng buộc này thông qua kiểu được xác định trong phần <xsd:schema> (xem Điều 11) của mô tả socket. Nếu biến có ràng buộc về giá trị tối thiểu trên kiểu của nó và thông qua thẻ <length> thì biến phải phù hợp với cả hai (tức là giá trị cao hơn được dùng như giá trị tối thiểu)

8.9.10 Phần phụ thuộc <maxlnclusive>

Thẻ <maxlnclusive> quy định biểu thức Xpath (với cú pháp xác định trong điều 5.2) đánh giá giá trị của cùng một kiểu với biến mà nó thuộc về. Số này quy định giá trị tối đa (bao hàm) của biến tại thời gian chạy. Nó sẽ không thay đổi trong suốt phiên.

CHÚ THÍCH Cách xử lý trong trường hợp phần phụ thuộc <maxlncIusive> thay đổi là không xác định.

Thẻ <maxInclusive> có thể xuất hiện như thẻ con của <dependency> (xem điều 8.9.1), nhưng chỉ khi biến đang nói đến có kiểu mà khoảng trống giá trị của nó được sắp xếp thứ tự toàn bộ. Nếu hiện diện thì nó sẽ xuất hiện một lần.

Thẻ <maxInclusive> chỉ được sử dụng nếu giá trị tối đa cho phép được định rõ tại lúc khởi tạo phiên, liên quan đến các thẻ socket khác. Nếu biến có ràng buộc về giá trị tối đa mà có thể được định rõ trước thời gian chạy thì nó nên diễn tả ràng buộc này thông qua kiểu được xác định trong phần <xsd:schema>(xem Điều 11) của mô tả socket. Nếu biến có ràng buộc về giá trị tối đa trên kiểu của nó và thông qua thẻ <maxInclusive> thì biến phải phù hợp với cả hai (tức là giá trị thấp hơn được dùng như giá trị tối đa)

8.9.11 Phần phụ thuộc <minExclusive>

Thẻ <minExclusive> quy định biểu thức Xpath (với cú pháp xác định trong điều 5.2) đánh giá giá trị của cùng một kiểu với biến mà nó thuộc về. Số này quy định giá trị tối thiểu (không bao hàm) của biến tại thời gian chạy. Nó sẽ không thay đổi trong suốt phiên.

CHÚ THÍCH Cách xử lý trong trường hợp phần phụ thuộc <minExclusive> thay đổi là không xác định.

Thẻ <minExclusive> có thể xuất hiện như thẻ con của <dependency> (xem điều 8.9.1), nhưng chỉ khi biến đang nói đến có kiểu mà khoảng trống giá trị của nó được sắp xếp thứ tự toàn bộ. Nếu hiện diện thì nó sẽ xuất hiện một lần.

Thẻ <minExclusive> chỉ được sử dụng nếu giá trị tối thiểu cho phép được định rõ tại lúc khởi tạo phiên, liên quan đến các thẻ socket khác. Nếu biến có ràng buộc về giá trị tối thiểu mà có thể được định rõ trước thời gian chạy thì nó nên diễn tả ràng buộc này thông qua kiểu được xác định trong phần <xsd:schema>(xem Điều 11) của mô tả socket. Nếu biến có ràng buộc về giá trị tối thiểu trên kiểu của nó và thông qua thẻ <minExclusive> thì biến phải phù hợp với cả hai (tức là giá trị cao hơn được dùng như giá trị tối thiểu)

8.9.12 Phần phụ thuộc <maxExclusive>

Thẻ <maxExclusive> quy định biểu thức Xpath (với cú pháp xác định trong điều 5.2) đánh giá giá trị của cùng một kiểu với biến mà nó thuộc về. Số này quy định giá trị tối đa (không bao hàm) của biến tại thời gian chạy. Nó sẽ không thay đổi trong suốt phiên.

CHÚ THÍCH Cách xử lý trong trường hợp phần phụ thuộc <maxExclusive> thay đổi là không xác định.

Thẻ <maxExclusive> có thể xuất hiện như thẻ con của <dependency> (xem điều 8.9.1), nhưng chỉ khi biến đang nói đến có kiểu mà khoảng trống giá trị của nó được sắp xếp thứ tự toàn bộ. Nếu hiện diện thì nó sẽ xuất hiện một lần.

Thẻ <maxExclusive> chỉ được sử dụng nếu giá trị tối đa cho phép được định rõ tại lúc khởi tạo phiên, liên quan đến các thẻ socket khác. Nếu biến có ràng buộc về giá trị tối đa mà có thể được định rõ trước thời gian chạy thì biến đó nên diễn tả ràng buộc này thông qua kiểu được xác định trong phần <xsd:schema>(xem Điều 11) của mô tả socket. Nếu biến có ràng buộc về giá trị tối đa trên kiểu của nó và thông qua thẻ <maxExclusive> thì biến phải phù hợp với cả hai (tức là giá trị thấp hơn được dùng như giá trị tối đa)

8.10 Lựa chọn

8.10.1 Khái quát

Biến danh mục (tức là một biến mà kiểu của nó được dẫn xuất bởi danh mục) có thể cung cấp tập các giá trị giới hạn khoảng trống giá trị của biến (lựa chọn đóng) hoặc cung cấp các giá trị gợi ý cho đầu vào người sử dụng (lựa chọn mở). Các danh mục phải cùng một kiểu với biến có giới hạn hoặc một kiểu con. Tập các giá trị được mô tả vời thẻ <selection> cho biến có giới hạn. Cả tập giá trị tĩnh và động đều có thể được xác định và chúng được kết hợp trong thẻ <selection> đơn.

Thẻ <selection> có thể hiện diện trong thẻ <variable> (xem điều 8.1). Nếu hiện diện thì nó sẽ xuất hiện một lần.

VÍ DỤ <selection> … </selection>

8.10.2 Thuộc tính ‘closed’

Thuộc tính ‘closed’ của kiểu dữ liệu Boolean có thể đi kèm thẻ <selection> để cho biết liệu tập các giá trị là đóng hay mở. Giá trị mặc định là “true”, tức là lựa chọn đóng.

VÍ DỤ <selection closed=“false”> … </selection>

Giá trị “false”, tức là lựa chọn mở, cho biết lựa chọn chứa các giá trị người sử dụng được gợi ý là tùy chọn, tức là người sử dụng có thể nhập một giá trị không được đưa ra trong tập các giá trị.

8.10.3 Các tập lựa chọn tĩnh và động

8.10.3.1 Khái quát

Một lựa chọn bao gồm một hoặc nhiều tập lựa chọn có thể là tĩnh hoặc động. Mỗi tập lựa chọn phải được mô tả với thẻ <selectionSetStatic> riêng biệt hoặc <selectionSetStatic> riêng biệt và phải có thuộc tính ‘id’ của kiểu xsd:ID mà có thể được sử dụng để tham chiếu đến tập.

VÍ DỤ Lựa chọn đóng bao gồm hai tập lựa chọn: một với tập tĩnh các đô thị (myStaticCites) được dựa trên xác định kiểu staticCityType, và một lựa chọn với tập động các đô thị (myDynamicCities) được quy định tại thời gian chạy bởi nội dung của biến dynCitiesVariable. Chú ý rằng staticCityType được dẫn xuất từ uis:stringLisItem (xem ví dụ trong điều 11.3) mà được dẫn xuất từ xsd:string (xem điều 11.3) và dynCitiesVariable là kiểu uis:stringList.

</selection>

8.10.3.2 Thẻ <selectionSetStatic>

Tập lựa chọn tĩnh (tức là không thay đổi tại thời gian chạy) được biểu thị bởi thẻ <selectionSetStatic>. Nó phải có thuộc tính ‘typeRef’ chứa tên của kiểu.

Kiểu tham chiếu phải được dẫn xuất bởi giới hạn từ kiểu đơn giản. Sự hợp nhất của các bảng liệt kê cũng là hợp lệ và cung cấp cơ chế mà cấu trúc trong tập lựa chọn có thể được thu nạp. Ví dụ về kiểu này có trong điều 11.4.

Các lựa chọn hợp lệ là tất cả các thẻ tuân theo kiểu cho trước.

CHÚ THÍCH Các tác nhân người sử dụng có thể trả lại tập các giá trị theo cách phản ánh cấu trúc của các kiểu tham chiếu và các thẻ tập lựa chọn nơi mà hiện diện cấu trúc. Ví dụ, các nhà phân phối có thể phân chia nhóm các lựa chọn khác nhau của hộp kết hợp hình ảnh trong môi trường GUI.

8.10.3.3 Thẻ <selectionSetDynamic>

Tập lựa chọn động phải được biểu thị bởi <selectionSetDynamic> với thuộc tính ‘varRef’ chứa id của biến kiểu uis:csvlist hoặc id của biến danh mục giá trị phân cách bằng khoảng trống (xem điều 8.3.3) mà kiểu bộ phận tương thích với kiểu của biến chủ. Biến danh mục tham chiếu không phải là thứ nguyên.

Các lựa chọn hợp lệ là tất cả các thẻ mà được tổ chức bởi biến danh mục.

Nếu biến chủ không phải là thứ nguyên và không được chứa trong một hoặc nhiều tập thứ nguyên thì biến danh mục tham chiếu không được chứa trong một hoặc nhiều tập thứ nguyên. Nếu biến chủ là thứ nguyên hoặc được chứa trong một hoặc nhiều tập thứ nguyên và nếu biến danh mục tham chiếu được chứa trong một hoặc nhiều tập thứ nguyên thì đường truyền thích đáng cho biến danh mục phải được định rõ bằng cách chia sẻ các chỉ số của các tập chung với đường truyền cho biến với thuộc tính ‘varRef’.

VÍ DỤ Trong máy thu hình, biến “channel’ chỉ cho phép các giá trị được chứa trong danh mục phân cách bằng khoảng trống trắng do giá trị của biến “channelList” đưa ra. Trong suốt thời gian chạy, giá trị của biến “channelList” có thể thay đổi mọi lúc do đó thay đổi tập các giá trị biến của biến “channel”.

<selection, closed=“true”>

</selection>

</variable>

8.11 Thông tin ánh xạ về nền tảng cho các biến

Thẻ <mapping> có thẻ được sử dụng số lần như thẻ con của <variable> (xem điều 8.1) để bao gồm thông tin ánh xạ về nền tảng cho biến.

Thẻ <mapping> phải có thuộc tính ‘platform’ mà bộ tiêu chuẩn này không giới hạn giá trị của nó.

Thẻ <mapping> có thể có nội dung thẻ và các thẻ con bất kỳ. Tuy nhiên, các thẻ con phải từ các vùng tên trừ vùng tên uis.

VÍ DỤ Thông tin ánh xạ về UpnP cho biến có thể bao gồm như sau:

…

</mapping>

8.12 Các đặc tính của biến từ DCMI

Mọi thẻ và bộ lọc thẻ từ TCVN 7980 (ISO 15836), Bộ phần tử siêu dữ liệu 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ả biến socket khi 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 <variable>(xem điều 8.1)

9 Lệnh

9.1 Khái quát

Các thẻ lệnh được sử dụng để thu nạp các lệnh mà người sử dụng có thể đưa ra cho đích. Lệnh là chức năng cốt lõi mà người sử dụng có thể yêu cầu đích thực hiện và điều đó không thể được biểu diễn bởi một biến. Lệnh nên biểu diễn một số chức năng ngoại trừ việc thao tác giá trị của biến đơn.

VÍ DỤ Nút tìm kiếm trên máy phát CD và nút đệ trình trên mẫu trực tuyến.

Thẻ <command> có thể xuất hiện như thẻ con của <set> (xem điều 7.1) hoặc như thẻ con của <uiSocket> (xem điều 6.1)

9.2 Thuộc tính ‘id’

Thẻ <command> (xem điều 9.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. Nó cung cấp định danh được sử dụng để tham chiếu 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’ là duy nhất trong số tất cả các thuộc tính ‘id’ và ‘name’ trong mô tả socket.

VÍ DỤ <command id=“seek”>

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 không cần phải hiểu nó.

9.3 Thuộc tính ‘type’

9.3.1 Khái quát

Các thẻ <command> (xem điều 9.1) có thể có thuộc tính ‘type’. Kiểu của một lệnh mô tả các trạng thái mà lệnh có. Trạng thái cung cấp thông tin về thực thi cuối cùng (yêu cầu) của lệnh.

Thuộc tính ‘type’ dùng QName như giá trị (xem Lược đồ XML Phần 2: Các kiểu dữ liệu ). Nếu tiền tố vùng tên được quy định thì sẽ giả thiết vùng tên http://openurc.org/ns/uisocketdesc-2.

VÍ DỤ 1 Các giá trị kiểu sau đây là cùng type=“uis:voidCommand” và type=“voidCommand” về ngữ nghĩa, giả thiết rằng định danh vùng tên uiSocket được liên kết với http://openurc.org/ns/uisocketdesc-2.

Các điều sau đây xác định kiểu lệnh. Kiểu lệnh mặc định phải là uis:voidCommand.

9.3.2 uis:voidCommand

Kiểu=“uis:voidCommand”: lệnh không trạng thái.

Lệnh của kiểu uisivoidCommand không có các thông số đầu vào – đầu ra.

CHÚ THÍCH Giới hạn này là cần thiết bởi vì lệnh với các thông số đầu vào – đầu ra không thể thực thi nhiều đối tượng của cùng một lệnh cùng một lúc, bởi chỉ có một tập các thông số đầu ra mà có thể nhận các kết quả.

9.3.3 uis:basicCommand

Kiểu=“uis:basicCommand”: lệnh phải có tập biến trạng thái sau đây: “initial”, “rejected”, “inProgress”, “done”, “succeeded”, “failed”.

Ý nghĩa ủa các trạng thái như sau:

– “initial”: lệnh không được yêu cầu thực thi

– “rejected”: Việc thực thi lệnh không được yêu cầu, đích từ chối yêu cầu

– “inProgress”: Lệnh hiện đang được thực thi theo yêu cầu

– “done”: Lệnh đã được thực thi

– “succeeded”: Lệnh được thực thi thành công (biến trạng thái này cụ thể hơn “done” và được ưu tiên hơn nếu được biết đến bởi đích)

– “failed”: Lệnh đã được thực thi nhưng thất bại (biến trạng thái này cụ thể hơn “done” và được ưu tiên hơn nếu được biết đến bởi đích)

CHÚ THÍCH 1 Với sự thất bại của việc thực thi lệnh, đích sẽ truyền tải một thông điệp về lỗi cho người sử dụng theo một cách riêng biệt, ví dụ: bằng cách tăng thông báo.

CHÚ THÍCH 2 Trạng thái của lệnh không cho biết gì về liệu lệnh này có thể được thực thi hay không. Điều này được quy định bởi phần phụ thuộc <write> (xem điều 9.9.3).

CHÚ THÍCH 3 Lệnh của kiểu “uis:basicCommand” không thể được gọi ra nhiều lần trên đích trừ khi việc gọi ra trước đó được hoàn thành (TCVN 11523-1 (ISO/IEC 24752-1)).

VÍ DỤ Nút bấm trong thang máy là lệnh với trạng thái “inProgress”.

9.3.4 uis:timedCommand

Kiểu=“uis:timedCommand”: giống với uis:basicCommand ngoài trừ trạng thái “inProgress” phải tạo sẵn trường “ttc” thêm vào.

Trường ‘ttc’ phải là kiểu xsd:duration.

Giá trị của trường ‘ttc’ có thể là không xác định tại mọi thời điểm.

Nếu lệnh trong trạng thái “inProgress” thì đích có thể “đếm ngược” một cách định kỳ giá trị của trường ‘ttc’ cho đến khi lệnh chuyển sang trạng thái khác. Giá trị của trường ‘ttc’ (nếu không phải chuỗi trống) là một gợi ý từ đích đến URC để biết được thời gian ước tính hoàn thành là bao lâu – đích không có bất cứ sự đảm bảo nào về điều này. Trường ‘ttc’ là trường chỉ đọc đối với URC. Giá trị của trường ‘ttc’ là không hợp lệ trong mọi trạng thái trừ ‘inProgress’

CHÚ THÍCH 1 Lệnh của kiểu uis:timedCommand không thể được gọi ra nhiều lần trên đích trừ khi việc gọi ra trước đó được hoàn thành (xem TCVN 11523-1 (ISO/lEC 24752-1)).

CHÚ THÍCH 2 Giá trị của trường ‘ttc’ có thể được truy cập trong các biểu thực phụ thuộc bằng cách gán “[ttc]” cho đường truyền trong chức năng Xpath uis:value(path), xem điều 5.2.5.2.

VÍ DỤ Lệnh “book” trong hệ thống đặt vé trực tuyến của kiểu uis:timedCommand và truyền tải thời gian ước tính cho quá trình đặt vé tại thời gian thực.

9.4 Thuộc tính ‘sensitive’

Thẻ <command> (xem điều 9.1) có thể có thuộc tính ‘sensitive’. Nó là kiểu dữ liệu Boolean cho biết liệu lệnh biểu diễn hoạt động nhạy cảm hợp pháp hay không.

Giá trị mặc định phải là “false”.

VÍ DỤ Lệnh gọi khẩn cấp mà dạng thể hiện của nó có phép tất suy hợp pháp sẽ được mô tả với phép đánh dấu:

9.5 Thuộc tính ‘sufficient’

Thẻ <command> (xem điều 9.1) có thể có thuộc tính ‘sufficient’ của kiểu Boolean.

Giá trị “true” cho biết rằng lệnh được quy định đầy đủ. Lệnh được quy định đầy đủ khi và chỉ khi tập các phần phụ thuộc assert là đầy đủ (nếu có). Tập các phần phụ thuộc assert là đầy đủ khi và chỉ khi bất cứ lúc nào tất cả các biểu thức của chúng là true, lệnh được thực thi thành công trên đích. Phần phụ thuộc assert được quy định trong điều 9.9.5.

CHÚ THÍCH 1 Từ “iff” là viết tắt của “if and only if” và có nghĩa là các câu lệnh trước và sau “iff” là tương đương. Vì vậy nếu một trong các câu lệnh là true thì các câu lệnh khác cũng là true, (cũng như vậy, nếu một trong các câu lệnh là false thì các câu lệnh khác cũng là false).

VÍ DỤ Đối với nút lệnh “tầng 4” của thang máy, điều kiện sau đây là không đầy đủ, bởi vì lệnh có thể thất bại và giá trị của biểu thức vẫn có thể là true:

<assert> uis:value(‘currentFloor’) > 0</assert>

</dependency>

Tuy nhiên, các điều kiện sau đây là đầy đủ:

<assert> uis:value (‘currentFloor’) eq 4 </assert>

</dependency>

CHÚ THÍCH 2 Trong trường hợp các mô tả đầy đủ của các lệnh, một URC thông minh có thể áp dụng các kỹ thuật suy luận tiên tiến và do đó, cung cấp nhiều giao diện người sử dụng hơn. Ví dụ, nó có thể kết luận rằng một lệnh không cần được gọi ra nếu các phần phụ thuộc assert của nó là true.

Nếu hiện diện thì thuộc tính ‘sufficient’ của <command> (xem điều 9.1) sẽ ghi đè lên thuộc tính ‘sufficient’ của <uiSocket> (xem điều 6.4) nhưng chỉ cho lệnh riêng. Nếu không hiện diện thì giá trị của thuộc tính ‘sufficient’ của <uiSocket> sẽ gắn với lệnh.

9.6 Thuộc tính ‘complete’

Thẻ <command> (xem điều 9.1) có thể có thuộc tính ‘complete’ của kiểu Boolean.

Giá trị “true” cho biết rằng tất cả các lệnh trong mô tả socket được quy định hoàn toàn liên quan đến các thông số của chúng. Một lệnh được quy định hoàn toàn khi và chỉ khi tập các thông số đầu vào và đầu ra của nó là hoàn thiện. Các thông số của lệnh được quy định trong điều 9.12.

Tập các thông số đầu vào của lệnh là hoàn thiện khi và chỉ khi kết quả của thực thi lệnh thành công được bảo đảm là giống nhau bất cứ khi nào lệnh được thực thi với cùng tập các giá trị thông số đầu vào.

Tập các thông số đầu ra của lệnh là hoàn thiện khi và chỉ khi không có các biến socket trừ các biến quy định như các thông số đầu ra được sửa đổi do việc thực thi lệnh cho tất cả các tập thông số đầu vào.

CHÚ THÍCH 1 Từ “iff- là viết tắt của “if and only if và có nghĩa là các câu lệnh trước và sau “iff” là tương đương. Vì vậy nếu một trong các câu lệnh là true thì các câu lệnh khác cũng là true, (cũng như vậy, nếu một trong các câu lệnh là false thì các câu lệnh khác cũng là false).

CHÚ THÍCH 2 Trong trường hợp các mô tả hoàn thiện của các lệnh, URC thông minh có thể áp dụng các kỹ thuật suy luận tiên tiến và do đó cung cấp nhiều giao diện người sử dụng hơn.

Nếu hiện diện thì thuộc tính ‘complete’ của <command> (xem điều 9.1) sẽ ghi đè lên thuộc tính ‘complete’ của <uiSocket>> (xem điều 6.5) nhưng chỉ cho lệnh riêng. Nếu không hiện diện thì giá trị của thuộc tính ‘complete’ của <uiSocket> sẽ gắn với lệnh.

9.7 Thuộc tính ‘optional’

Thẻ <command> (xem điều 9.7) có thể có thuộc tính ‘optional’ của kiểu Boolean. Giá trị mặc định của nó là ‘false’.

Giá trị “true” cho biết rằng lệnh có thể không sẵn có tại thời gian chạy do các ràng buộc khác nhau.

CHÚ THÍCH 1 Các ví dụ về sự ràng buộc mà 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 trong cài đặt (như là trong UpnP DCPs)

CHÚ THÍCH 2 Tính sẵn có của thẻ socket sẽ được chỉ ra tại thời gian chạy cho URC thông qua phương tiện về TUN. (TCVN 11523-1 (ISO/IEC 24752-1)).

9.8 Thuộc tính ‘dim’

Thẻ <command> (xem điều 9.1) có thể có thuộc tính ‘dim’ quy định lệnh là thứ nguyên (với một hoặc nhiều thứ nguyên), tại thời gian chạy, lệnh thứ nguyên phải có nhiều trạng thái, mỗi trạng thái cho một liên kết các chỉ số riêng.

Thuộc tính ‘dim’ có thể hiện diện cho các thẻ <set>. 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 được xác định (xem điều 11.5) hoặc được nhập (xem điều 11.6) trong phần <xsd:schema>của mô tả socket, và (b) tên định tính đầy đủ (QName) của kiểu bên ngoài (xem điều 11.7).

Chỉ số của lệnh không có giá trị ‘ttc’ dược dự trữ để biểu thị trường ‘ttc’ của nó (xem điều 5.2.5.2).

CHÚ THÍCH 1 Thuộc tính ‘type’ của lệnh thứ nguyên quy định kiểu của mỗi giá trị đơn chứa trong lệnh đó và không phải toàn bộ kiểu lệnh.

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 lệnh 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 trạng thái 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 lệnh 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ẻ <uiSocket> xuống lệnh 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.

CHÚ THÍCH 4 Kiểu chỉ số có thể quy định một số không giới hạn của các giá trị chỉ số (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ị cho phép bởi kiểu chỉ số.

CHÚ THÍCH 5 Việc sử dụng lệnh thứ nguyên chỉ hợp lý nếu tập các lệnh là đồng nhất, tức là mỗi lệnh có các đặc tính giống hệt nhau bao gồm nhãn (thông điệp) và văn bản trợ giúp.

CHÚ THÍCH 7 Các tham chiếu (ví dụ: từ các tài nguyên nguyên tử) đến các lệnh thứ nguyên tham chiếu đến các thành phần đơn lẻ của lệnh. Trong ví dụ trên, URI “http://example.com/thermometer/socket#reset” tham chiếu đến mọi thành phần lệnh đơn trong lệnh thứ nguyên với id=‘reset’. Tuy nhiên, URI “http://example.com/thermometer/socket#dims(reset)” tham chiếu đến toàn bộ lệnh 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-1 (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 lệnh 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.

9.9 Các phần phụ thuộc của lệnh

9.9.1 Khái quát

Các phần phụ thuộc của lệnh diễn tả khi một lệnh là thích hợp và có thể thực thi được bởi người sử dụng và hiệu quả của lệnh là gì (“điều kiện sau”).

Các phần phụ thuộc của lệnh phải được quy định bằng cách gán chúng trong thẻ lệnh sử dụng phép đánh dấu:

</dependency>

Thẻ <dependency> có thể xuất hiện một lần như thẻ con của <command> (xem điều 9.1).

9.9.2 Phần phụ thuộc <relevant>

Phần phụ thuộc <relevant> quy định khi lệnh được đưa ra cho người sử dụng, tức là phần phụ thuộc dựa trên trạng thái riêng của đích thích hợp như thế nào. Nếu phần phụ thuộc <relevant> là true thì lệnh phải được đưa ra cho người sử dụng. Điều này không nhất thiết rằng nó có thể truy cập trực tiếp trong giao diện người sử dụng được dẫn xuất từ socket nhưng có một số đường truyền điều hướng mà người sử dụng có thể tìm thấy nó.

Thẻ <relevant> có thể hiện diện như thẻ con của <depedency> (xem điều 9.9.1). Nếu hiện diện, nó sẽ xuất hiện một lần. Nếu không hiện diện thì lệnh sẽ kế thừa phần phụ thuộc <relevant> từ thẻ <set> sơ khai gần nhất mà có phần phụ thuộc <relevant> đã quy định (xem 7.4.2).

VÍ DỤ Lệnh đặt chỗ chỉ có thể thích hợp khi người sử dụng đang xác định việc đặt chỗ. Phần phụ thuộc này có thể được diễn tả sử dụng phần phụ thuộc <relevant> như sau:

<relevant> uis:value(‘activity’ ) eq ‘makingReservation’ </relevant>

</dependency>

</command>

Nội dung của thẻ <relevant> phải được quy định cho phần phụ thuộc <relevant> của các biến (xem điều 8.9.2).

Nếu không có phần phụ thuộc <relevant> được quy định (không nằm trên lệnh hoặc trên mọi tập sơ khai của nó) hoặc nếu nó là trống thì phần phụ thuộc <relevant> của lệnh phải luôn là true, thậm chí khi thẻ <notify> hoạt động.

9.9.3 Phần phụ thuộc <write>

Phần phụ thuộc <write> quy định liệu người sử dụng có thể kích hoạt lệnh hay không. Điều này được gọi là “phần phụ thuộc <write> hoặc “điều kiện trước”. Nếu điều kiện trước là false thì nó không thích hợp để thực hiện hoạt động, nếu không thì nó sẽ thích hợp để thực hiện một hoạt động mặc dù không đảm bảo rằng sẽ thành công.

Thẻ <write> có thể hiện diện như thẻ con của <dependency> (xem điều 8.9.1). Nếu hiện diện nó sẽ xuất hiện một lần. Nếu không hiện diện thì lệnh sẽ kế thừa phần phụ thuộc <write> từ thẻ <set> sơ khai gần nhất mà có phần phụ thuộc <relevant> đã quy định (xem điều 8.9.3).

VÍ DỤ Nút bấm ở thang máy lệnh cho thang máy đi đến tầng 4 chỉ được kích khởi nếu thang máy không ở tầng 4. Phần phụ thuộc này có thể được diễn tả như sau:

<write> uis:value(‘currentrioor’) ne 4 </write>

</dependency>

Nội dung của thẻ <write> phải được quy định cho phần phụ thuộc <write> của các biến (xem điều 8.9.3).

Nếu phần phụ thuộc <write> của lệnh là trống hoặc nếu nó kế thừa phần phụ thuộc <write> trống từ tập sơ khai thì phần phụ thuộc <write> của lệnh là phải là ẩn số.

CHÚ THÍCH Việc giới thiệu một giá trị ẩn là tương tự với kiểu logic Boolean có giá trị 3 mà chú ý đến tính bất định. Nếu phần phụ thuộc <write> là ẩn thì URC không có sự lựa chọn nào khác là tìm hiểu xem liệu nó có thể thực thi lệnh hay không.

Nếu không có phần phụ thuộc <write> được quy định (không nằm trên lệnh hoặc trên mọi tập sơ khai của nó), phần phụ thuộc <write> của lệnh phải luôn là true, thậm chí khi thẻ <notify> hoạt động.

9.9.4 Phần phụ thuộc <insert>

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 lệnh cho liên kết chỉ số mới trong khoảng trống chỉ số được xác định bởi thuộc tính ‘dim’ tương ứng. Chú ý rằng tình trạng của thành phần lệnh đã thêm vào đượ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 lệnh cho liên kết chỉ số riêng mà hiện đang diễn ra.

Phần phụ thuộc <insert> có thể hiện diện như thẻ con của thẻ <dependency> (xem điều 9.9.1) chỉ khi lệnh tương ứng có thuộc tính ‘dim’ (xem điều 9.8). Nếu hiện diện thì nó sẽ xuất hiện một lần.

Giá trị mặc định của nó phải là “false ()”.

CHÚ THÍCH 2 Không có sự kế thừa nào từ phần phụ thuộc <insert> của thẻ <set> (xem điều 7.4.4) đến phần phụ thuộc của thẻ <command>. Phần phụ thuộc <insert> chỉ liên quan đến tập các chỉ số được quy định bởi thuộc tính ‘dim’ của mức tương ứng.

9.9.5 Phần phụ thuộc <assert>

Phần phụ thuộc <assert> quy định biểu thức Boolean được đảm bảo là true sau khi lệnh được thực thi thành công. Điều này được gọi là ‘sự xác nhận’ hay “điều kiện sau”.

CHÚ THÍCH 1 Nếu phần phụ thuộc <assert> được đảm bảo là đầy đủ thì nó có thể suy luận từ một điều kiện sau đúng đắn mà lệnh thực thi thành công. Xem điều 9.5 để biết chi tiết về thuộc tính ‘sufficient’

Đối với các lệnh của kiểu uis:voidCommand (xem điều 9.3.2) điều kiện sau được đảm bảo là true đối với mọi lần gọi ra lệnh đã yêu cầu. Đối với lệnh của kiểu uis:basicCommand (xem điều 9.3.3) hoặc uis:timedCommand (xem điều 9.3.4), điều kiện sau được đảm bảo là true cho tất cả các lần gọi ra lệnh mà dẫn đến trạng thái “succeeded”.

Thẻ <assert> có thể hiện diện như thẻ con của <dependency> (xem điều 9.9.1). Nếu hiện diện thì nó sẽ xuất hiện một lần.

VÍ DỤ 1 Sau khi thực thi thành công nút “tầng 4” của thang máy, giá trị của biến ‘currentFloor’ sẽ là 4. Sự xác nhận này có thể được diễn tả như sau:

dependency>

<assert> uis:value(‘currentFloor’) eq 4 </assert>

</dependency>

VÍ DỤ 2 Lệnh “startPlay” sẽ kích khởi đích yêu cầu URC mở một phiên con (“yêu cầu chuyển tiếp”, xem TCVN (ISO/IEC 24752-1)) trên socket “play”.

<assert> uis:sessionForward(“spawn”, “http://example.com/target/play”)

</assert>

</dependency>

</command>

CHÚ THÍCH Các URC tiên tiến có thể khai thác tin tức trên các điều kiện sau để tạo nhiều giao diện người sử dụng dễ dùng hơn. Các điều kiện sau đặc biệt hữu dụng nếu chúng được quy định đầy đủ (xem điều 9.5).

Nội dung của thẻ <assert> phải là trống hoặc biểu thức Xpath hợp lệ đánh giá giá trị Boolean.

Nếu phần phụ thuộc <assert> của lệnh là trống thì phần phụ thuộc <assert> của lệnh phải là ẩn số.

9.10 Thông tin ánh xạ về nền tảng cho các lệnh

Thẻ <mapping> có thể được sử dụng số lần như thẻ con của <command> (xem điều 9.1) bao gồm thông tin ánh xạ về nền tảng cho lệnh.

Thẻ <mapping> 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ẻ <mapping> 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.

9.11 Các đặc tính lệnh 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ả lệnh socket, 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ẻ <command>(xem điều 9.1).

9.12 Các thông số lệnh

9.12.1 Khái quát

Thẻ <command> (xem điều 9.1) có thể có mọi số thẻ con <param>, mỗi thẻ con xác định một thông số từ xa liên quan đến lệnh.

CHÚ THÍCH 1 Phạm vi của thông số lệnh là cục bộ hoặc toàn cục (trong socket). Xem điều 9.12.2 và 9.12.3 dưới đây.

VÍ DỤ Lệnh gọi thang máy có ba thông số đầu vào: tầng gốc, tầng đến và thời gian đợi cửa thang máy mở khi không có ai đi qua cửa. Các thông số “tầng gốc” và “tầng đến” là cục bộ, tức là chúng phải được cung cấp cho mọi lần gọi. Thời gian đợi là thông số toàn cục, tức là nó có thể được thiết lập là cài đặt toàn cục cho tất cả lần gọi sau.

</command>

CHÚ THÍCH 2 Các URC tiên tiến có thể khai thác tin tức trên các điều kiện sau để tạo nhiều giao diện người sử dụng dễ dùng hơn. Các điều kiện sau đặc biệt hữu dụng nếu chúng được quy định đầy đủ. Xem điều 9.6 để biết thêm chi tiết về thuộc tính ‘complete’.

9.12.2 Thuộc tính ‘id’ (thông số cục bộ)

Thẻ <param> (xem điều 9.12.1) phải có một thuộc tính ‘id’ hoặc một thuộc tính ‘idref’ (xem điều 9.12.3). Thẻ <param> với thuộc tính ‘id’ được gọi là “thông số cục bộ”.

Giá trị của thông số cục bộ phải sẵn có cho người sử dụng (tức là có trạng thái xác định) chỉ khi phần phụ thuộc <relevant> của lệnh là true.

Giá trị của thuộc tính ‘id’ phải là duy nhất trong số tất cả các thuộc tính ‘id’ trong mô tả socket.

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. Nó cung cấp định danh đượ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. Thuộc tính ‘id’ không được đưa ra cho người sử dụng và con người không cần hiểu nó.

CHÚ THÍCH Căn cứ vào việc gọi ra lệnh, URC sẽ gửi các giá trị của tất cả các thông số đầu vào cục bộ (tức là các thông cục bộ với giá trị dir của “in” hoặc “inout”) đến đích. Sau khi thực thi, đích sẽ trả về giá trị của tất cả các thông số đầu ra cục bộ (tức là các thông số cục bộ với giá trị dir “out” hoặc “inout”) cho URC.

9.12.3 Thuộc tính ‘idref’(thông số toàn cục)

Thẻ <param> (xem điều 9.12.1) phải có một thuộc tính ‘idref’ hoặc một thuộc tính ‘id’ (xem điều 9.12.2). Thẻ <param> với thuộc tính ‘idref’ được gọi là “thông số toàn cục”.

Thuộc tính ‘idref’ phải tham chiếu biến hoặc thông báo của cùng một socket, tức là giá trị của thuộc tính ‘idref’ phải là giá trị của thuộc tính ‘id’ của thẻ <variale> hoặc <notify> (xem điều 8.1) trong mô tả socket có liên quan. Vì là một ngoại lệ, thuộc tính ‘idref’ cũng có thể tham chiếu một tập socket giống nhau bởi ‘id’ của nó, có nghĩa là tất cả các biến chứa trong tập được sử dụng như các thông số toàn cục cho lệnh.

CHÚ THÍCH 1 Tham chiếu một biến là thông số “out” toàn cục có nghĩa là việc thực thi lệnh sẽ tác động đến giá trị của biến. Tham chiếu một thông báo là thông số “out” toàn cục có nghĩa là việc thực thi lệnh sẽ tác động lên tính trạng của thông báo.

Các thông số cục bộ của các lệnh khác không được tham chiếu bởi thuộc tính ‘idref.

Thuộc tính ‘idref của kiểu IDREF như được xác định bởi Lược đồ XML Phần 2: Các kiểu dữ liệu. Nó quy định ràng buộc giữa lệnh được chứa trong và một biến: Nếu giá trị của thuộc tính ‘dir’ (xem điều 9.12.4) là “in” thì đích sẽ sử dụng giá trị hiện thời của biến tham chiếu như giá trị đầu vào cho việc thực thi lệnh. Nếu giá trị của thuộc tính ‘dir’ là “out” thì đích sẽ cập nhật giá trị tham chiếu để phản ánh kết quả sau khi thực thi lệnh. Nếu giá trị của thuộc tính ‘dir’ là “inout” thì đích sẽ đọc từ biến tham chiếu trước khi thực hiện và ghi lại nó sau khi thực hiện lệnh.

Thuộc tính ‘idref’ không được đưa ra cho người sử dụng và con người cũng không cần hiểu nó.

Thông số toàn cục không có thuộc tính ‘type’ (xem điều 9.12.4.4). Thay vào đó, kiểu của nó được quy định bởi khai báo biến socket tham chiếu (xem điều 8.3).

CHÚ THÍCH 2 Căn cứ vào việc gọi ra lệnh, URC sẽ không gửi hoặc nhận các giá trị của các thông số toàn cục của lệnh. Thay vào đó, các giá trị của chúng sẽ được đồng bộ hóa giữ URC và đích như đã yêu cầu cho các biến socket (đã mô tả trong TCVN (ISO/IEC 24752-1)), độc lập từ việc gọi ra lệnh.

CHÚ THÍCH 3 Các URC tiên tiến có thể khai thác tin tức trên các thông số toàn cục để suy luận các phần phụ thuộc giữa các thẻ socket và do đó tạo nhiều giao diện người sử dụng dễ dùng hơn

9.12.4 Thuộc tính ‘dir’

9.12.4.1 Khái quát

Thẻ <param> (xem điều 9.12.1) phải có thuộc tính ‘id’.

Giá trị của nó phải là “in”, “out”, hoặc “inout”. Giá trị “in” đánh dấu thông số là thông số đầu vào. Giá trị “out” đánh dấu thông số là thông số đầu ra. Giá trị “inout” quy định rằng thông số là cả thông số đầu vào và thông số đầu ra, tức là thông số sẽ được đọc trước khi thực thi và cập nhật sau khi thực thi lệnh.

CHÚ THÍCH Các lệnh của kiểu uis:voidCommand không thể có các thông số đầu ra hoặc các thông số đầu vào-đầu ra (xem điều 9.3.2).

9.12.4.2 Các thông số đầu vào

Thuộc tính ‘dir’ (xem điều 9.12.4.1 giá trị ‘in’ biểu thị các thông số đầu vào, tức là các thông số mà giá trị của chúng sẽ được đọc bởi đích trước khi thực thi lệnh, để ảnh hưởng đến việc thực thi và (các) kết quả của nó).

Lệnh có thể có mọi thông số đầu vào (cục bộ và toàn cục).

Giá trị của thông số đầu vào cục bộ có thể được thay đổi bởi URC hoặc người sử dụng khi phần phụ thuộc <write> của lệnh đánh giá là “true” hoặc không được biết đến.

Đối với các thông số đầu vào toàn cục, các phần phụ thuộc <relevant> và <write> của chúng (xem điều 8.9.2 và 8.9.3) quy định liệu chúng có thể truy cập hoặc thay đổi bởi URC hoặc người sử dụng hay không.

CHÚ THÍCH Các thông số đầu vào cục bộ tương tự với các thẻ socket, nhưng các giá trị của chúng được đồng bộ hóa với đích chỉ khi lệnh được gọi ra và chỉ từ URC đến đích.

9.12.4.3 Các thông số đầu ra

Thuộc tính ‘dir’ (xem điều 9.12.4.1 giá trị ‘out’ biểu thị các thông số đầu ra, tức là các thông số mà giá trị của chúng sẽ được cập nhật bởi đích trước khi thực thi lệnh, để phản ánh kết quả của việc thực thi).

Lệnh có thể có mọi thông số đầu ra (cục bộ và toàn cục).

Giá trị của thông số đầu ra cục bộ không được thay đổi bởi URC hoặc người sử dụng.

Đối với các thông số đầu ra toàn cục, các phần phụ thuộc <relevant> và <write> của chúng (xem điều 8.9.2 và 8.9.3) quy định liệu chúng có thể truy cập hoặc thay đổi bởi URC hoặc người sử dụng hay không.

CHÚ THÍCH Các thông số đầu ra cục bộ tương tự với các thẻ socket, nhưng các giá trị của chúng được đồng bộ hóa với đích chỉ khi lệnh được gọi ra và chỉ từ URC đến đích.

9.12.4.4 Các thông số đầu vào – đầu ra

Thuộc tính ‘dir’ (xem điều 9.12.4.1 giá trị ‘inout’ biểu thị các thông số đầu vào-đầu ra, tức là các biến mà được sử dụng như các thông số đầu vào-đầu ra cho cùng một lệnh).

Lệnh có thể có mọi thông số đầu ra (cục bộ và toàn cục).

Đối với các thông số đầu vào-đầu ra toàn cục, các phần phụ thuộc <relevant> và <write> của chúng (xem điều 8.9.2 và 8.9.3) quy định liệu chúng có thể truy cập hoặc thay đổi bởi URC hoặc người sử dụng hay không.

CHÚ THÍCH Các thông số đầu vào – đầu ra cục bộ tương tự với các thẻ socket, nhưng các giá trị của chúng được đồng bộ hóa với đích trong hai trường hợp sau đây: (1) khi lệnh được gọi ra, từ URC đến đích; và (2) sau khi việc thực thi của lệnh hoàn thành, từ đích đến URC.

9.12.5 Thuộc tính ‘type’

Thông số cục bộ (9.12.2) phải có thuộc tính ‘type’. Thông số toàn cục (xem điều 9.12.3) không có thuộc tính ‘type’.

Giá trị thuộc tính ‘type’ biểu thị kiểu thông số. Các kiểu hợp lệ giống với thẻ <variable> (xem điều 8.3).

9.12.6 Thuộc tính ‘secret’

Thông số cục bộ (xem điều 9.12.2) có thể có thuộc tính ‘secret’. Giá trị mặc định của nó phải là ‘false’.

Thông số toàn cục (xem điều 9.12.3) không có thuộc tính ‘secret’.

Thuộc tính ‘secret’ phải có cùng ý nghĩa với thẻ <variable> (xem điều 8.4).

9.12.7 Thuộc tính ‘sensitive’

Thông số cục bộ (xem điều 9.12.2) có thể có thuộc tính ‘sensitive’. Giá trị mặc định của nó phải là “false”.

Thông số toàn cục (xem điều 9.12.2) không có thuộc tính “sensitive”.

Thuộc tính ‘sensitive’ phải có cùng ý nghĩa với thẻ <variable> (xem điều 8.5).

9.12.8 Thẻ con <selection>

Thẻ <selection> có thể xuất hiện như thẻ con của <param> (xem điều 9.12.1) nhưng chỉ cho các thông số đầu vào cục bộ (xem điều 9.12.4.2) và các thông số đầu vào-đầu ra cục bộ (xem điều 9.12.4.4). Nếu hiện diện thì nó sẽ xuất hiện một lần.

Thẻ <selection> cung cấp tập các giá trị mà giới hạn khoảng trong giá trị của thông số (lựa chọn đóng) hoặc cung cấp các giá trị gợi ý cho đầu vào người sử dụng (lựa chọn mở). Nó phải theo cùng một cú pháp như đã xác định cho các biến (xem điều 8.10).

VÍ DỤ Thiết bị kết xuất đồ họa giúp người sử dụng lựa chọn kỹ từ các cấu hình thiết lập trước. Khi gọi ra lệnh “selectPreset”, người sử dụng có thể lựa chọn kỹ một trong các cấu hình thiết lập trước trong biến danh mục “presetNameList”.

<dc:description> Biến này chứa danh mục phân cách bằng dấu phẩy của các tên thiết lập trước hợp lệ được hỗ trợ bởi thiết bị này. Giá trị của nó thay đổi nếu/khi thiết bị thay đổi tập các cấu hình thiết lập trước mà nó hỗ trợ. Điều này có thể xảy ra cùng với hoạt động xác định nhà cung cấp hoặc một số sự kiện phi UPnP khác. Biến trạng thái này bao gồm mọi cấu hình thiết lập trước mà được hỗ trợ bởi thiết bị..</dc:description>

</variable>

<dc:deseription>Set a preset configuration.</dc:description

</selection>

</param>

</command>

9.12.9 Thông tin ánh xạ về nền tảng cho các thông số lệnh

Thẻ <mapping> có thể được sử dụng số lần như thẻ con của <param> (xem điều 9.12.1) cho các thông số cục bộ (xem điều 9.12.2) bao gồm thông tin ánh xạ về nền tảng. Nó không xuất hiện với các thông số toàn cục (xem điều 9.12.2).

Thẻ <mapping> phải có thuộc tính ‘platform’ mà giá trị của nó không được giới hạn bởi tiêu chuẩn này.

Thẻ <mapping> 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.

9.11 Các đặc tính thông số lệnh 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ông số lệnh, 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ẻ <param>(xem điều 9.12.1).

10 Thông báo

10.1 Khái quát

Thông báo là các trạng thái đặc biệt mà thao tác thông thường bị treo, như là các trạng thái loại bỏ. Đích có thể gọi ra (kích hoạt) hoặc xóa bỏ (bỏ kích hoạt) một thông báo tại mọi thời điểm.

VÍ DỤ Các ví dụ về thông báo bao gồm cáo thị được tạo bởi hệ thống địa chỉ công cộng trong sân bay, đồng hồ báo thức hoặc trả lời đầu vào không hợp lệ cho một trường hoặc một dạng.

Thẻ <notify> có thể xuất hiện một hoặc nhiều lần như thẻ con của <set> (xem điều 7.1) hoặc như thẻ con của <uiSocket> (xem điều 6.1).

Thẻ <notify> phải có một trong ba trạng thái: “active”, “inactive” hoặc “stacked”. Trạng thái mặc định là “inactive”. Đích có thể kích hoạt hoặc bỏ kích hoạt thẻ <notify> tại mọi thời điểm. Một số biến và lệnh chỉ có thể đọc được hoặc ghi lại khi thông báo hoạt động, như đã diễn tả trong các phần phụ thuộc <relevant> và <write> của chúng (xem điều 8.9.2, 8.9.3, 9.9.2 và 9.9.3).

Đích có thể kích hoạt thông báo trong khi thông báo khác đang hoạt động. Trong trường hợp này, thông báo thứ hai chiếm ưu thế hơn thông báo thứ nhất. Tác nhân người sử dụng phải giữ một số lượng lớn các thông báo trong tầm điều khiển. Tất cả các thông báo hoạt động mà không nằm trong tầm kiểm soát thì được xem là trong trạng thái bị xếp chồng (điều này nằm bên trong tác nhân người sử dụng và không được chia sẻ với đích).

Các giao diện người sử dụng dựa trên socket giao diện người sử dụng phải đề cao thứ tự mà thông báo hoạt động, sao cho thông báo kích hoạt mới nhất luôn được đưa ra cho người sử dụng. Khi thông báo phía trên hoạt động thì thông báo tiếp theo trên ngăn xếp hoạt động một lần nữa và được đưa ra cho người sử dụng.

Hầu hết các thông báo yêu cầu việc thừa nhận của người sử dụng (phụ thuộc vào thuộc tính ‘type’, xem điều 10.3).

CHÚ THÍCH Thẻ <notify> không đi cùng thông điệp văn bản để biểu diễn cho người sử dụng. Hơn nữa, thông điệp được biểu diễn được đưa ra bởi các tài nguyên nguyên tử (ở dạng văn bản, hình ảnh hoặc video), như đã xác định trong các tệp tài nguyên (xem TCVN 11523-5 (ISO/IEC 24752-5)),

10.2 Thuộc tính ‘id’

Thẻ <notify> (xem điều 10.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: Kiểu dữ liệu. Thuộc tính ‘id’ cung cấp định danh đượ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 ví dụ như 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’ thường không được đưa ra cho người sử dụng và con người cũng không cần hiểu chúng.

VÍ DỤ <notify id=‘‘fireAlarmWarning”>

10.3 Thuộc tính ‘type’

Thẻ <notify> (xem điều 10.1) có thể có thuộc tính ‘type’, quy định kiểu hội thoại xác định trước.

CHÚ THÍCH 1 Thuộc tính ‘type’ là cơ chế thuận tiện cho nhà phát triển socket sử dụng các dạng hội thoại chuẩn dựng sẵn khi thích hợp. Các kiểu xác định trước nên đầy đủ cho nhiều trường hợp sử dụng.

CHÚ THÍCH 2 Đối với tất cả các thông báo, các nhãn và các thành phần giao diện người sử dụng phụ thuộc ngôn ngữ khác cho các thông báo sử dụng kiểu hội thoại chuẩn bị trước có thể được quy định như các tài nguyên nguyên tử trong các tệp tài nguyên (xem TCVN 1 1523-5 (ISO/IEC 24752-5)).

Nếu hiện diện thì thuộc tính ‘type’ phải có một trong các giá trị sau đây:

– “show”: Thông báo phải được đưa ra cho người sử dụng. Người sử dụng không được yêu cầu thừa nhận việc chấp nhận thông báo (tức là không yêu cầu hội thoại theo chế độ);

CHÚ THÍCH Thông báo “show” có thể được đưa ra nhưng mục tin trên dòng trạng thái hoặc cửa sổ của bộ điều khiển hay một số vị trí cụ thể khác trên màn hình. Có thể có một nút cho người sử dụng để xóa thông điệp.

– “confirm” Thông báo phải được đưa ra cho người sử dụng và người sử dụng được yêu cầu thừa nhận (xác nhận) việc nhận thông báo;

CHÚ THÍCH Trong giao diện người sử dụng trực quan, thông báo này có thể được biểu diễn như một hội thoại theo chế độ, chỉ ra một thông điệp và nút “OK”.

– “confirmCancel”: Giống với “confirm” nhưng khác chỗ người sử dụng có thể chọn giữa việc xác nhận và việc xóa;

CHÚ THÍCH Trong giao diện người sử dụng trực quan, thông báo này có thể được biểu diễn như một hội thoại theo chế độ, chỉ ra một thông điệp và hai nút “OK” và “Cancel”.

– “yesNo”: Thông báo phải được đưa ra cho người sử dụng và người sử dụng được yêu cầu trả lời “yes” hoặc “no” cho thông báo

CHÚ THÍCH Trong giao diện người sử dụng trực quan, thông báo này có thể được biểu diễn như một hội thoại theo chế độ, chỉ ra một thông điệp và hai nút “yes” và “no”.

VÍ DỤ Mã sau đây biểu diễn thông báo mà người sử dụng cần trả lời với “yes” hoặc “no”.

– “yesNoCancel”: Giống với “yesNo” nhưng khác chỗ người sử dụng cũng có thể chọn cancel;

– “option”: Thông báo phải được đưa ra cho người sử dụng và người sử dụng được yêu cầu lựa chọn một trong nhiều lựa chọn. Tập các lựa chọn được quy định trong thẻ <selection> xếp lồng (xem điều 8.10). <selection> có thể chứa một hoặc nhiều tập lựa chọn mở và đóng (xem điều 8.10.3);

CHÚ THÍCH 1 Trong giao diện người sử dụng trực quan, thông báo này có thể được biểu diễn như một hội thoại theo chế độ, chỉ ra một thông điệp và nhiều nút, mỗi chút cho một lựa chọn sẵn có.

CHÚ THÍCH 2 Các nhãn cho các lựa chọn có thể được quy định bằng cách gán các tài nguyên nguyên tử cho các giá trị cụ thể của các kiểu socket và/hoặc các biến socket, như đã tham chiếu trong thẻ <selection> xếp lồng.

VÍ DỤ Mã sau đây biểu diễn thông báo mã giúp người sử dụng lựa chọn giữa các giá trị liệt kê của kiểu bên trong Socket ‘problemType’ (ví dụ: có thể có các giá trị liệt kê sau đây: “proceed”, “cancel”, “callhelp”)

</selection>

</notify>

– “optionCancel”: Giống với “option” nhưng khác chỗ người sử dụng cũng có thể chọn cancel;

– “custom” (giá trị mặc định): kiểu Custom. Trong trường hợp này, thẻ <notify> (xem điều 10.1) phải có các thẻ con quy định cái mà đầu vào từ người sử dụng được yêu cầu (xem điều 10.10). Sau khi người sử dụng cung cấp đầu vào thì họ phải xác nhận thông báo;

– “customCancel”: Giống với “custom” nhưng khác chỗ người sử dụng có thể chọn cancel.

CHÚ THÍCH Trong giao diện người sử dụng bằng đồ họa, người sử dụng nhìn thấy một hoặc nhiều thành phần đầu vào (ví dụ: các nút ở radio, các hộp đánh dấu, các trường đầu vào) và nút “OK”. Người sử dụng ấn nút “OK” khi mà họ xác minh rằng tất cả các giá trị được thiết lập theo mong muốn.

10.4 Thuộc tính ‘category’

Thẻ <notify> (xem điều 10.1) có thể có thuộc tính ‘category’. Hạng mục của thẻ <notify> mô tả bản chất của thông báo.

CHÚ THÍCH 1 URC có thể sử dụng thông tin hạng mục để đáp lại thông báo theo nhiều cách khác nhau. Ví dụ, các hình tượng khác nhau có thể được sử dụng để cho biết mức độ khẩn cấp của cho người sử dụng.

CHÚ THÍCH 2 Hạng mục khác với kiểu thông báo. Về cơ bản, mọi liên kết của các kiểu và hạng mục có thể xảy ra.

Thuộc tính ‘category’ phải có một trong các giá trị sau đây:

– “info”: đích đang cung cấp thông tin cho người sử dụng;

– “alert”: đích đang báo động cho người sử dụng về một tình huống

– “error”: đích phát hiện ra lỗi.

VÍ DỤ 1 Để thông báo cho người sử dụng sự trễ chuyến bay, hạng mục info là thích hợp.

VÍ DỤ 2 Để thông báo cho người sử dụng rằng thang máy đang đến tầng yêu cầu, hạng mục alert là thích hợp.

VÍ DỤ 3 Để thông báo cho người sử dụng rằng chỉ 2 trong số 10 mục yêu cầu là sẵn có, hạng mục error là thích hợp.

Giá trị mặc định phải là “info”.

10.5 Thuộc tính ‘sensitive’

Thẻ <notify> (xem điều 10.1) có thể có thuộc tính ‘sensitive’. Nó là kiểu dữ liệu Boolean cho biết liệu thông báo biểu diễn hoạt động nhạy cảm hợp pháp hay không.

VÍ DỤ Thông báo có thể cung cấp một cảnh báo về an toàn mà dạng trình diễn của nó có các phép tất duy hợp pháp. Ví dụ này được mô tả với phép đánh dấu:

Giá trị mặc định phải là “false”.

10.6 Thuộc tính ‘optional’

Thẻ <notify> (xem điều 10.1) có thể có 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ì thông báo không sẵn có tại thời gian chạy do các ràng buộc khác nhau.

CHÚ THÍCH 1 Các ví dụ về các ràng buộc tác động lê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)).

10.7 Thuộc tính ‘dim’

Thuộc tính ‘dim’ quy định thông báo là thứ nguyên (với một hoặc nhiều thứ nguyên). Tại thời gian chạy, thông báo thứ nguyên có nhiều trạng thái, mỗi trạng thái cho một liên kết các chỉ mục riêng.

Thẻ <notify> (xem điều 10.1) có thể có thuộc tính ‘dim’. 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 thông báo. 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 hoặc nhập trong phần <xsd:schema> của mô tả socket, hoặc (b) tên định tính (QName) của kiểu bên ngoài.

Chỉ số của thông báo không có giá trị ‘ttc’ mà được dành riêng để biểu thị trường ‘ttc’ của nó (xem điều 5.2.5.2).

CHÚ THÍCH 1 Tập lớn nhất của các giá trị cho thông báo 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ẻ <uiSocket> xuống thông báo 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.

CHÚ THÍCH 2 Không có việc sắp xếp thứ tự rõ ràng xác định cho các thực thể do thông báo 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 trạng thái đến URC – và cho URC – trong việc đưa ra các trạng thái cho người sử dụng (xem TCVN 11523-1 (ISO/IEC 24752-1)).

CHÚ THÍCH 3 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 4 Việc sử dụng lệnh thứ nguyên chỉ hợp lý nếu tập các thông báo là đồng nhất, tức là mỗi lệnh có các đặc tính giống hệt nhau bao gồm nhãn (thông điệp) và văn bản trợ giúp.

CHÚ THÍCH 5 Các tham chiếu (ví dụ: từ các tài nguyên nguyên tử) đến các thông báo thứ nguyên tham chiếu các thành phần riêng lẻ của thông báo. Ví dụ, URI http://example.com/thermometer/socket#alert tham chiếu đến mọi thành phần thông báo đơn trong thông báo thứ nguyên với id=’alert’. Tuy nhiên, URI http:// example.com/thermometer/socket#dims(alert) tham chiếu đến toàn bộ thông báo với tất cả các thành phần. Xem TCVN 11523-1 (ISO/IEC 24752-1) để biết thêm chi tiết.

CHÚ THÍCH 6 Thứ tự mà các thành phần của thông báo thứ nguyên đưa ra cho người sử dụng được dựa trên việc sắp xếp thứ tự đã xác định của 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.

10.8 Thuộc tính ‘timeout’

Thẻ <notify> (xem điều 10.1) có thể có thuộc tính ‘timeout’ nhằm cho biết rằng thông báo sẽ không tính thời gian khi hoạt động. Nếu hiện diện thì thuộc tính ‘timeout’ phải có giá trị kiểu xsd:duration, quy định thời gian chờ mặc định cho thông báo.

VÍ DỤ Mã sau đây biểu diễn thông báo với thời gian chờ mặc định 1 phút hoặc 15 giây.

Tất cả các thẻ <notify> (xem điều 10.1) mà có thời gian chờ phản hồi người của sử dụng phải biểu diễn thời gian chờ mặc định với một thuộc tính như vậy. Thuộc tính này cho biết thời gian để người sử dụng phản hồi thông báo trước khi đích xóa nó. Giá trị thuộc tính phải ít nhất 10 giây và nên dài hơn đối với các hội thoại thông báo phức tạp.

CHÚ THÍCH 1 Khuyến cáo rằng các đích đưa ra một lựa chọn cho người sử dụng để kéo dài thời gian chờ của thông báo (xem TCVN 11523-1 (ISO/IEC 24752-1)). Điều này có thể đạt được bằng cách thông báo với người sử dụng trước khi xuất hiện thời gian chờ và giúp người sử dụng kéo dài thời gian chờ qua một hội thoại. Đích có thể tự động điều chỉnh thời gian chờ dựa trên các quyền ưu tiên của người sử dụng (điều này không thuộc phạm vi của bộ tiêu chuẩn này)

CHÚ THÍCH 2 Đối với các thông báo với thuộc tính ‘timeout’, đích có thể gửi liên tục các giá trị đếm ngược cập nhật cho thời gian còn lại trong khi nó hoạt động (trường “ttc”). Cũng như vậy, thời gian còn lại có thể được sử dụng như một phần của phần phụ thuộc (xem điều 5.2.5.2).

10.9 Các phần phụ thuộc của thông báo

10.9.1 Khái quát

Thẻ <dependency> có thể hiện diện như thẻ con của <notify> (xem điều 10.1). Nếu hiện diện nó sẽ xuất hiện một lần.

10.9.2 Phần phụ thuộc <insert>

Phần phụ thuộc <insert> 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ệ có liên quan ở thời gian chạy hay không (với tập có liên quan là các chỉ số quy định bởi thuộc tính ‘dim’ trên thẻ <notify> tương ứng, xem điều 10.1).

Nội dung của phần phụ thuộc <insert> phải là biểu thức Xpath đánh giá giá trị Boolean mà có thể thay đổi trong suố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 thông báo cho 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 tình trạng của thành phần thông báo thêm vào đượ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 thông báo cho liên kết chỉ số riêng hiện đang diễn ra.

Thẻ <insert> có thể hiện diện như thẻ con của thẻ <dependency> (xem điều 10.9.1) chỉ khi thẻ <notify> có thuộc tính ‘dim’ (xem điều 10.7). 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 Không có sự kế thừa từ phần phụ thuộc <insert> của thẻ <set> (xem điều 7.4.4) tới phần phụ thuộc của thẻ <notify> chứa đựng (xem điều 8.1). Mỗi phần phụ thuộc <insert> chỉ gắn liền với tập các chỉ số được quy định bởi thuộc tính ‘dim’ của mức tương ứng.

10.10 Các biến và các lệnh thông báo

Các thông báo custom, tức là không hiện diện thuộc tính ‘type’ hoặc type =“custom” (xem điều 10.3), thẻ <notify> (xem điều 10.1) phải chứa một hoặc nhiều thẻ <variable> hoặc<command>, với tất cả các thuộc tính và các thẻ con thích hợp quy định trong Điều 8 và Điều 9. Đối với các kiểu thông báo trừ “custom”, thẻ <notify> không được chứa bất kỳ thẻ <variable> hoặc <command> nào.

Các biến hoặc các lệnh thông báo phải có giá trị không xác định và không được đưa ra cho người sử dụng trừ khi thông báo hoạt động.

Khi thông báo hoạt động thì hội thoại theo chế độ phải được đưa ra cho người sử dụng, bao gồm tất cả các biến và các lệnh chứa trong có liên quan được quy định bởi các phần phụ thuộc riêng lẻ. Sau đó người sử dụng có thể tương tác với các thẻ chứa trong nó, tức là thay đổi giá trị của biến và/hoặc kích khởi việc thực thi các lệnh.

Cuối cùng, người sử dụng được yêu cầu xác nhận hoặc hủy bỏ (đối với kiểu thông báo nếu thích hợp) hội thoại theo chế độ.

VÍ DỤ Mã sau đây quy định một thông báo yêu cầu dữ liệu xác nhận từ người sử dụng (tên, mật khẩu). Thông báo này sẽ nêu ra nếu người sử dụng yêu cầu thực thi thao tác đặc quyền.

<notify id=“authorizationRequired”

category=“alert”

type=“customCancel”>

<dc:description xml:lang=‘‘en”> Cho người sử dụng biết việc xác nhận được yêu cầu, và cung cấp tên và mật khẩu. Nếu người sử dụng hủy thì thao tác đã yêu cầu sẽ không được thực thi. Cũng có một lệnh mà người sử dụng có thể kích hoạt trong trường hợp họ quên mật khẩu .</dc:descriptions>

</notify>

CHÚ THÍCH Trong giao diện người sử dụng đồ họa, người sử dụng có thể ấn nút “OK” để xác nhận rằng họ kết thúc việc tương tác với hội thoại theo chế độ và các thẻ của nó. Cũng như vậy, nút “Cancel” có thể được cung cấp cho các kiểu thông báo “yesNoCancel”, “optionCancel” và “customCancel”.

Trong khi người sử dụng tương tác với hội thoại theo chế độ, đích thiết lập trạng thái thông báo ngược trở lại “inactive”, người sử dụng phải được thông báo về điều này và hội thoại theo chế độ phải bị đóng.

10.11 Thông tin ánh xạ về nền tảng cho các thông báo

Thẻ <mapping> có thể được sử dụng số lần như thẻ con của <notify> (xem điều 10.1) bao gồm thông tin ánh xạ về nền tảng cho thông báo.

Thẻ <mapping> phải có thuộc tính ‘platform’ mà giá trị của nó không được giới hạn bởi tiêu chuẩn này.

Thẻ <mapping> 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.

10.12 Các đặc tính của thông báo từ DCMI

11 Các xác định kiểu

11.1 Khái quát

Mô tả socket có thể chứa các xác định kiểu cho các biến chứa trong cùng một tài liệu. Các kiểu này phải được dẫn xuất bởi giới hạn hoặc danh mục từ các kiểu dựng sẵn hoặc các kiểu dẫn xuất khác. Ngoài ra, dẫn xuất bằng việc hợp nhất được cho phép nếu các kiểu được thống nhất và dẫn xuất từ cùng một kiểu dữ liệu dựng sẵn.

VÍ DỤ Kiểu dẫn xuất bao gồm sự hợp nhất hai kiểu dẫn xuất từ xsd:string có thể được sử dụng trong mô tả socket.

Xem ‘Lược đồ XML Phần 2: Các kiểu dữ liệu’ để biết thêm chi tiết về cách dẫn xuất các kiểu trong XSD.

Thẻ gốc <uiSocket> (xem điều 6.1) có thể có một thẻ <xsd:schema> chúng xác định các kiểu.

Thẻ <xsd:schema> không chứa thuộc tính ‘targetNamespace’. Các kiểu xác định bên trong mô tả socket chỉ là các kiểu cục bộ (không có định danh vùng tên), và không thể được tham chiếu bên ngoài mô tả socket.

Giá trị thuộc tính ‘name’ trên <xsd:simpleType> hoặc <xsd:complexType> phải là duy nhất trong số tất cả số lần xuất hiện của các thuộc tính ‘name’ và ‘id’ trên mọi thẻ XML trong tài liệu mô tả socket.

CHÚ THÍCH Giá trị ‘name’ được sử dụng để quy định các nhãn và các tài nguyên nguyên tử khác cho các kiểu bên trong socket trong các tệp tài nguyên. Vì các tài nguyên nguyên tử cho các thẻ socket được quy định qua các thuộc tính ‘id’ của chúng cho nên các giá trị của tất cả các thuộc tính ‘name’ và ‘id’ là duy nhất.

11.2 Các facet

Kiểu biến phải được mô tả càng chính xác càng tốt trong định nghĩa socket. Các facet mô tả các khía cạnh của khoảng trống giá trị của kiểu phải được sử dụng. Có các facet cơ sở và facet ràng buộc. Xem Định nghĩa Lược đồ XML Phần 2 để biết thêm chi tiết.

VÍ DỤ Facet cơ sở “có thứ tự” có thể có các giá trị “false”, “partial” hoặc “total”. Giá trị của facet này có các phép tất duy về cách giá trị của biến có thể được sửa đổi bởi người sử dụng trong tầng trình diễn. Đối với biến mà có kiểu được sắp xếp thứ tự toàn bộ thì cơ chế đầu vào liên quan như là một con trượt hoặc lệnh “up” và “down” có thể được sử dụng.

Nếu có các giới hạn trên tập các giá trị hợp pháp cho biến, các giới hạn này phải được diễn tả bằng cách dẫn xuất một kiểu đơn giản mới từ kiểu Lược đồ XML cơ sở sử dụng các facet ràng buộc xác định trong Lược đồ XML Phần 2.

Các facet ràng buộc sẵn có như đã xác định trong Lược đồ XML Phần 2 là: length, minLength, maxLength, patter, enumeration, whiteSpace, maxlnclusive, maxExclusive, minlnclusive, minExclusive.

VÍ DỤ 2 Biến biểu diễn số seri của nhân viên có thể được khai báo là chuỗi có độ dài 9 ký tự với dẫn xuất từ kiểu dữ liệu string sau đây:

<xsd:simpleType name=“serialNumberType”>

<xsd:restriction base=“xsd:string”>

<xsd:length value=“9”/>

</xsd:restriction>

</xsd:simpleType>

Một kiểu giới hạn lựa chọn cho tập các giá trị cụ thể có thể được diễn tả sử dụng facet liệt kê.

VÍ DỤ 3 Lược đồ xác định các ngày nghỉ lễ được chỉ ra trong http://www.w3.org/TR/2001/REC-xmlschema-2- 20010502/#rf-fund-facets là một dẫn xuất của kiểu xsd:gMonthDay.

11.3 Danh mục các giá trị string

Kiểu uis:stringListItem được xác định trước như một khối hợp nhất cho đặc tả của kiểu cung cấp danh mục các giá trị string. uis:stringListltem được dẫn xuất từ chuỗi bởi sự giới hạn và không chứa bất cứ khoảng trắng nào. Tập tĩnh các giá trị string (tham khảo trong <selectionSetStatic>, xem điều 8.9.5) có thể được dẫn xuất từ uis:stringListltem bởi kết cấu liệt kê.

Kiểu uis:stringListltem phải được xác định trước là:

<xsd:simpleType name=“stringListItem”>

<xsd:restriction base=“xsd:string”>

<xsd:pattern value=“\S+” />

</xsd:restriction>

</xsd:simpleType>

VÍ DỤ Kiểu mới staticCityType được xác định rằng chứa một tập tĩnh các tên thành phố, như đã sử dụng trong ví dụ 3 của điều 8.9.5:

<xsd:simpleType name=“staticCityType”>

<xsd:restriction base=“uis:stringListItem”>

<xsd:enumeration value=“Washington, DC” />

<xsd:enumeration value=“Seattle, WA” />

<xsd:enumeration value=“Boston, MA” />

</xsd:restriction>

</xsd:simpleType>

Các facet: length, minLength, maxLength có thể được sử dụng để quy định các ràng buộc liên quan đến số thẻ mà biến danh mục có thể nắm giữ. Các facet khác có thể được sử dụng là enumeration và pattern.

Kiểu xác định trước uis:stringList có thể được sử dụng bởi người thực thi mô tả socket nhằm tham chiếu đến danh mục các chuỗi ở đó không có tập các giá trị mục nào được biết trước thời gian chạy:

<xsd: simpleType name=“stringList”>

<xsd:list itemType=“uis:stringListltem” />

</xsd:simpleType>

CHÚ THÍCH Các kiểu xác định trước uis:stringListltem và uis:stringList được cung cấp nhằm tạo thuận lợi cho người thực thi mô tả socket. Nếu người thực thi muốn sử dụng các danh mục của kiểu trừ string thì họ cần sử dụng cú pháp cung cấp XSD cho việc dẫn xuất bởi danh mục và đảm bảo rằng các giá trị mục không chứa các khoảng trống.

11.4 Cấu trúc diễn tả trong khoảng trống giá trị của kiểu

Khoảng trống giá trị của biến có thể có một số lớn các giá trị có thể xảy ra và khoảng trống giá trị này có thể có một số cấu trúc tự nhiên, cấu trúc này có thể được biểu diễn bằng cách xác định kiểu của biến như một sự hợp nhất các kiểu con.

VÍ DỤ Kiểu cho các tên thành phố có thể được cấu trúc theo quốc gia và trạng thái như sau:

<xsd:simpleType name=“worldCityListType”>

<xsd:union memberTypes=“unitedStatesCityType …” />

</xsd:simpleType>

<xsd:simpleType name=“unitedStatesCityType”>

<xsd:union memberTypes=“alaskaCityType …” />

</xsd:simpleType>

<xsd:simpleType name=“alaskaCityType”>

<xsd:restriction base=“xsd:string”>

<xsd:enumeration value=“anchorage”/>

<xsd:enumeration value=“city2”/>

</xsd:restrictions>

</xsd:simpleTypes>

CHÚ THÍCH Cấu trúc diễn tả ở đây chỉ nhằm mục đích giải thích cho máy và các tài nguyên yêu cầu giải thích cho người sử dụng cấu trúc, như là các nhãn cho các kiểu và các giá trị được cung cấp riêng biệt.

11.5 Các kiểu bên trong socket

Socket có thể xác định các kiểu đơn giản hoặc phức tạp cho các biến và các thứ nguyên. Nó có thể làm được như vậy bằng cách sử dụng các thẻ <xsd:simpleType> và <xsd:complexType> (và các thẻ con thích hợp) như đã xác định trong Lược đồ XML Phần 1. Chúng được gọi là “các kiểu bên trong socket”.

Giá trị thuộc tính ‘name’ của các kiểu bên trong socket này phải là duy nhất trong số tất cả các thuộc tính ‘id’ và ‘name’ trong mô tả socket.

11.6 Nhập lược đồ

Nó có thể làm như vậy bằng cách sử dụng thẻ <xsd:import> như đã xác định trong Lược đồ XML Phần 1. Thẻ <import> phải có một thuộc tính ‘namespace’ và thuộc tính ‘schemaLocation’ với ý nghĩa được xác định trong Lược đồ XML Phần 1. Giá trị của thuộc tính ‘namespace’ phải ngang bằng với vùng tên đích của lược đồ bên ngoài tham chiếu bởi giá trị của thuộc tính ‘schemaLocation’.

Các xác định kiểu và thẻ từ vùng tên bên ngoài được nhập, có thể tham chiếu bởi các thẻ socket và các thứ nguyên qua định danh vùng tên và các tên kiểu (giá trị ‘name’).

CHÚ THÍCH Khác với XML Phần 1, việc định danh lược đồ bên ngoài không được tạo điều kiện. Trong mô tả socket, Thuộc tính ‘schemaLocation’ quy định rõ ràng làm thế nào để tìm ra tập lược đồ bên ngoài được nhập.

11.7 Các tham chiếu đến các kiểu bên ngoài socket

Các kiểu xác định trong các vùng tên khác có thể được tham chiếu bởi 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 định nghĩa lược đồ XML thích hợp nên được đưa ra bằng cách sử dụng thuộc tính ‘xsi:schemaLocation’,

CHÚ THÍCH Socket coi các giá trị của các kiểu phức tạp như kiểu dữ liệu string, cụ thể, khi sử dụng bên trong biểu thức Xpath đối với các phần phụ thuộc. Giả thiết không có việc kiểm tra nào dựa trên tính chính xác và tính hợp lệ. Tuy nhiên, nó có thể tạo ra các giá trị của kiểu phức tạp sẵn có cho các UIID trong định dạng đặc biệt thông qua API. Ví dụ, nó có thể đề nghị API dựa trên DOM cho các biến của các kiểu phức tạp.

11.8 Xác định thẻ

Socket có thể xác định các thẻ sử dụng trong các xác định kiểu phức tạp. Nó có thể làm được như vậy bằng cách sử dụng thẻ <xsd:element> (và các thẻ con thích hợp) như đã định nghĩa trong Lược đồ XML Phần 1. Thẻ <xsd:element> có thể xuất hiện như thẻ con của <xsd:schema> (xem Điều 11) hoặc bên trong thẻ <xsd:complexType>.

VÍ DỤ Kiểu về tập hợp các nhan đề sách:

<xsd:complexType name=“booksType”>

<xsd:sequence>

<xsd:element minOccurs=“0” maxOccurs=“unbounded” name=“title”

type=/,xsd: string”/>

</xsd:sequence>

</xsd:complexType>

12 Các xem xét về an toàn

Đối với các ứng dụng và môi trường tác động mạnh đến quyền riêng tư và tính toàn vẹn, các mô tả socket nên được bảo vệ bởi một mức độ an toàn thích hợp. Nhà cung cấp và nhà vận tải nền tảng được khuyến khích xem xét việc sử dụng các dịch vụ về quyền riêng tư và tính toàn vẹn như là an toàn vận tải (ví dụ: HTTP qua TLS). Tuy nhiên, các biện pháp an toàn cụ thể không thuộc phạm vi của bộ tiêu chuẩn này.

Phụ lục A

(Tham khảo)

Các tài liệu cho các mô tả socket giao diện người sử dụng

Phụ lục này chứa các tham chiếu trực tuyến tới các tài liệu mà liên quan tiêu chuẩn này. Các tài liệu này được giao phó cho máy chủ web của liên kết URC mở đối với tính ngắn gọn của tiêu chuẩn này.

a) Mô tả socket cho bộ ổn nhiệt số, có trong các tài liệu WSDL ở trên http://openurc.org/TPL/basic-thermostat-1/basic-thermostat.uis

b) Định nghĩa Lược đồ XML cho các mô tả socket giao diện người sử dụng theo tiêu chuẩn này (với các quy tắc về lược đồ bao hàm): http://openurc.org/ns/uisocketdesc-2

THƯ MỤC TÀI LIỆU THAM KHẢO

[1] TCVN 11523-5 (ISO/IEC 24752-5), 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 5: Mô tả tài nguyên

[2] TCVN 11523-6 (ISO/IEC 24752-6), 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 6: Tích hợp dịch vụ web

[3] IETF RFC 2818. HTTP Over TLS. Internet Society, May 2000. http-//tools.ietf.org/html/rfc2818

[4] Metadata Terms D.C.M.I. http://dublincore.org/documents/dcmi-terms/

[5] IETF RFC 2046, Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types, November 1996, http://www.ietf.org/rfc/rfc2046.txt

[6] IETF RFC 3023, XML Media Types, January 2001, http://www.ietf.org/rfc/rfc3023.txt

[7] IETF RFC 3986, Uniform Resource Identifier (URI): Generic Syntax, January 2005, http://www.ietf.org/rfc/rfc3986. txt

[8] W3C Recommendation: Extensible Markup Language (XML) 1.0 (Fifth Edition), W3C Recommendation 26 November 2008, http://www.w3.org/TR/2008/REC-xm/-20081126/

[9] W3C Recommendation: Namespaces in XML 1.0 (Third Edition), W3C Recommendation 8 December 2009, http://www.w3.org/TR/2009/REC-xml-names-20091208/

MỤC LỤC

Lời nói đầu

1 Phạm vi áp dụng

2 Sự phù hợp

3 Tài liệu viện dẫn

4 Thuật ngữ và định nghĩa

5 Liên quan đến các tiêu chuẩn khác

5.1 Liên quan đến XML

5.2 Biểu thức XPath

6 Cấu trúc của mô tả socket

6.1 Khái quát

6.2 Thuộc tính ‘about’

6.3 Thuộc tính ‘id’

6.4 Thuộc tính ‘sufficient’

6.5 Thuộc tính ‘complete’

6.6 Thuộc tính’extends’

6.7 Thẻ <dcterms:conformsTo>

6.8 Thẻ <dcterms:modified>

6.9 Các đặc tính mô tả socket tử DCMI

6.10 Các thẻ <variable>, <command>, <notify>và <set>

6.11 Các thẻ lược đồ kiểu XSD

6.12 Thông tin ánh xạ về nền tảng cho các socket

7 Các tập

7.1 Khái quát

7.2 Thuộc tính ‘id’

7.3 Thuộc tính ‘dim’

7.4 Các phần phụ thuộc của tập

7.5 Thông tin ánh xạ về nền tảng cho các tập

7.6 Các đặc tính của tập từ DCMI

7.7 Thành phần của tập

8 Biến

8.3 Thuộc tính ‘type’

8.4 Thuộc tính ‘secret’

8.5 Thuộc tính ‘sensitive’

8.6 Thuộc tính ‘optional’

8.7 Thuộc tính ‘final’

8.8 Thuộc tính ‘dim’

8.9 Các phần phụ thuộc của biến

8.10 Lựa chọn

8.11 Thông tin ánh xạ về nền tảng cho các biến

8.12 Các đặc tính của biến từ DCMI

9 Lệnh

9.1 Khái quát

9.2 Thuộc tính ‘id’

9.3 Thuộc tính ‘type’

9.4 Thuộc tính ‘sensitive’

9.5 Thuộc tính ‘sufficient’

9.6 Thuộc tính ‘complete’

9.7 Thuộc tính ‘optional’

9.8 Thuộc tính ‘dim’

9.9 Các phần phụ thuộc của lệnh

9.10 Thông tin ánh xạ về nền tảng cho các lệnh

9.11 Các đặc tính Set từ DCMI

9.12 Các thông số lệnh

9.11 Các đặc tính thông số lệnh từ DCMI

10 Thông báo

10.1 Khái quát

10.2 Thuộc tính ‘id’

10.3 Thuộc tính ‘type’

10.4 Thuộc tính ‘category’

10.5 Thuộc tính ‘sensitive’

10.6 Thuộc tính’optional’

10.7 Thuộc tính’dim’

10.8 Thuộc tính ‘timeout’

10.9 Các phần phụ thuộc của thông báo

10.10 Các biến và các lệnh thông báo

10.11 Thông tin ánh xạ về nền tảng cho các thông báo

10.12 Các đặc tính của tập từ DCMI

11 Các xác định kiểu

11.1 Khái quát

11.2 Các facet

11.3 Danh mục các giá trị string

11.4 Cấu trúc diễn tả trong khoảng trống giá trị của kiểu

11.5 Các kiểu bên trong socket

11.6 Nhập lược đồ

11.7 Các tham chiếu đến các kiểu bên ngoài socket

11.8 Xác định thẻ

12 Các xem xét về an toàn

Phụ lục A (Tham khảo) Các tài liệu cho các mô tả socket giao diện người sử dụng

1 ISO/IEC 10646:2011 đã bị hủy và thay bằng ISO/IEC 10646:2014/Amd1:2015, Amd2:2016

2 Tệp có thể được truy cập tại http://www.w3.org/TR/2010/REC-Xpath20-20101214/

3 Tệp có thể được truy cập tại http://www.w3.org/TR/2010/REC-xpath-functions-20101214/

4 Tệp có thể được truy cập tại http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/

5 Tệp có thể được truy cập tại http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/

TIÊU CHUẨN QUỐC GIA TCVN 11523-2:2016 (ISO/IEC 24752-2:2014) VỀ 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
Số, ký hiệu văn bản	TCVN11523-2:2016	Ngày hiệu lực	30/12/2016
Loại văn bản	Tiêu chuẩn Việt Nam	Ngày đăng công báo
Lĩnh vực	Giao dịch điện tử	Ngày ban hành	30/12/2016
Cơ quan ban hành	Bộ khoa học và công nghê	Tình trạng	Còn hiệu lực

Các văn bản liên kết

Văn bản được hướng dẫn		Văn bản hướng dẫn
Văn bản được hợp nhất		Văn bản hợp nhất
Văn bản bị sửa đổi, bổ sung		Văn bản sửa đổi, bổ sung
Văn bản bị đính chính		Văn bản đính chính
Văn bản bị thay thế		Văn bản thay thế
Văn bản được dẫn chiếu		Văn bản căn cứ

Tải văn bản

Tải văn bản về Bản PDF/Bản gốc