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

Tải văn bản

Lưu trữ Góp ý

Thuộc tính
Nội dung
Tiếng anh
Lược đồ

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

...

Bạn phải đăng nhập hoặc đăng ký Thành Viên TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.

Mọi chi tiết xin liên hệ: ĐT: (028) 3930 3279 DĐ: 0906 22 99 66

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: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 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ó.

...

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.

...

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.

...

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.

...

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.

...

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’

...

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).

...

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 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: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.

...

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.

...

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.

...

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”.

...

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

...

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>

...

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>

...

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>

...

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.

...

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.

...

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.

...

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>

...

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>

...

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>

...

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’

...

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.

...

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’.

...

<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ó.

...

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

...

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’

...

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

...

Ý 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).

...

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.

...

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’

...

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

...

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>

...

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ế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 ()”.

...

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>

...

<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ố.

...

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

...

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ộ)

...

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’ 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).

...

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.

...

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’.

...

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

...

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.

...

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.

...

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”.

...

- “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”)

...

</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.

...

- “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.

...

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.

...

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.

...

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).

...

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ế độ.

...

<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”.

...

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

...

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.

...

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ê.

...

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

...

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ẻ

...

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

...

[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

...

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

...

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

...

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/

Nội dung văn bản đang được cập nhật

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ố hiệu:	TCVN11523-2:2016
Loại văn bản:	Tiêu chuẩn Việt Nam
Nơi ban hành:	***
Người ký:	***
Ngày ban hành:	01/01/2016
Ngày hiệu lực:	Đã biết
Tình trạng:	Đã biết

Văn bản được hướng dẫn - [0]

Văn bản được hợp nhất - [0]

Văn bản bị sửa đổi bổ sung - [0]

Văn bản bị đính chính - [0]

Văn bản bị thay thế - [0]

Văn bản được dẫn chiếu - [9]

Văn bản được căn cứ - [0]

Văn bản liên quan ngôn ngữ - [0]

Văn bản đang xem

Văn bản liên quan cùng nội dung - [4]

Văn bản hướng dẫn - [0]

Văn bản hợp nhất - [0]

Văn bản sửa đổi bổ sung - [0]

Văn bản đính chính - [0]

Văn bản thay thế - [0]

- 14 +

Tải Văn bản tiếng Việt
Tải Văn bản gốc

Chưa có Video

Hãy đăng nhập hoặc đăng ký Tài khoản để biết được tình trạng hiệu lực, tình trạng đã bị sửa đổi, bổ sung, thay thế, đính chính hay đã được hướng dẫn chưa của văn bản và thêm nhiều tiện ích khác