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.
đồng hồ báo thức hoặc trả lời đầu vào không hợp lệ cho một trường hoặc một dạng.
Thẻ <notify> có thể xuất hiện một hoặc nhiều lần như thẻ con của <set> (xem điều 7.1) hoặc như thẻ con của <uiSocket> (xem điều 6.1).
Thẻ <notify> phải có một trong ba trạng thái: “active”, “inactive” hoặc “stacked”. Trạng thái mặc định là “inactive”. Đích có thể kích hoạt hoặc bỏ kích hoạt thẻ <notify> tại mọi thời điểm. Một số biến và lệnh chỉ có thể đọc được hoặc ghi lại khi thông báo hoạt động, như đã diễn tả trong các phần phụ thuộc <relevant> và <write> của chúng (xem điều 8.9.2, 8.9.3, 9.9.2 và 9.9.3).
Đích có thể kích hoạt thông báo trong khi thông báo khác đang hoạt động. Trong trường hợp này, thông báo thứ hai chiếm ưu thế hơn thông báo thứ nhất. Tác nhân người sử dụng phải giữ một số lượng lớn các thông báo trong tầm điều khiển. Tất cả các thông báo hoạt động mà không nằm trong tầm kiểm soát thì được xem là trong trạng thái bị xếp chồng (điều này nằm bên trong tác nhân người sử dụng và không được chia sẻ với đích).
Các giao diện người sử dụng dựa trên socket giao diện người sử dụng phải đề cao thứ tự mà thông báo hoạt động, sao cho thông báo kích hoạt mới nhất luôn được đưa ra cho người sử dụng. Khi thông báo phía trên hoạt động thì thông báo tiếp theo trên ngăn xếp hoạt động một lần nữa và được đưa ra cho người sử dụng.
Hầu hết các thông báo yêu cầu việc thừa nhận của người sử dụng (phụ thuộc vào thuộc tính ‘type’, xem điều 10.3).
CHÚ THÍCH Thẻ <notify> không đi cùng thông điệp văn bản để biểu diễn cho người sử dụng. Hơn nữa, thông điệp được biểu diễn được đưa ra bởi các tài nguyên nguyên tử (ở dạng văn bản, hình ảnh hoặc video), như đã xác định trong các tệp tài nguyên (xem TCVN 11523-5 (ISO/IEC 24752-5)),
10.2 Thuộc tính ‘id’
Thẻ <notify> (xem điều 10.1) phải có thuộc tính ‘id’.
Thuộc tính ‘id’ phải là kiểu ID như đã xác định bởi Lược đồ XML Phần 2: Kiểu dữ liệu. Thuộc tính ‘id’ cung cấp định danh được sử dụng để tham chiếu đến thẻ trong mô tả socket và là phương tiện liên kết bên ngoài các tài nguyên ví dụ như các nhãn. Giá trị ‘id’ phải là duy nhất trong số tất cả các thuộc tính ‘id’ và ‘name’ trong mô tả socket.
CHÚ THÍCH Các giá trị thuộc tính ‘id’ thường không được đưa ra cho người sử dụng và con người cũng không cần hiểu chúng.
VÍ DỤ <notify id=‘‘fireAlarmWarning”>
10.3 Thuộc tính ‘type’
Thẻ <notify> (xem điều 10.1) có thể có thuộc tính ‘type’, quy định kiểu hội thoại xác định trước. CHÚ THÍCH 1 Thuộc tính ‘type’ là cơ chế thuận tiện cho nhà phát triển socket sử dụng các dạng hội thoại chuẩn dựng sẵn khi thích hợp. Các kiểu xác định trước nên đầy đủ cho nhiều trường hợp sử dụng.
CHÚ THÍCH 2 Đối với tất cả các thông báo, các nhãn và các thành phần giao diện người sử dụng phụ thuộc ngôn ngữ khác cho các thông báo sử dụng kiểu hội thoại chuẩn bị trước có thể được quy định như các tài nguyên nguyên tử trong các tệp tài nguyên (xem TCVN 1 1523-5 (ISO/IEC 24752-5)). Nếu hiện diện thì thuộc tính ‘type’ phải có một trong các giá trị sau đây:
- “show”: Thông báo phải được đưa ra cho người sử dụng. Người sử dụng không được yêu cầu thừa nhận việc chấp nhận thông báo (tức là không yêu cầu hội thoại theo chế độ);
CHÚ THÍCH Thông báo “show” có thể được đưa ra nhưng mục tin trên dòng trạng thái hoặc cửa sổ của bộ điều khiển hay một số vị trí cụ thể khác trên màn hình. Có thể có một nút cho người sử dụng để xóa thông điệp.
- “confirm” Thông báo phải được đưa ra cho người sử dụng và người sử dụng được yêu cầu thừa nhận (xác nhận) việc nhận thông báo;
CHÚ THÍCH Trong giao diện người sử dụng trực quan, thông báo này có thể được biểu diễn như một hội thoại theo chế độ, chỉ ra một thông điệp và nút “OK”.
và việc xóa;
CHÚ THÍCH Trong giao diện người sử dụng trực quan, thông báo này có thể được biểu diễn như một hội thoại theo chế độ, chỉ ra một thông điệp và hai nút “OK” và “Cancel”.
- “yesNo”: Thông báo phải được đưa ra cho người sử dụng và người sử dụng được yêu cầu trả lời “yes” hoặc “no” cho thông báo
CHÚ THÍCH Trong giao diện người sử dụng trực quan, thông báo này có thể được biểu diễn như một hội thoại theo chế độ, chỉ ra một thông điệp và hai nút “yes” và “no”.
VÍ DỤ Mã sau đây biểu diễn thông báo mà người sử dụng cần trả lời với “yes” hoặc “no”. <notify id=“giftwrap” type=“yesNo” />
- “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 id=“problem” type=“option”> <selection>
<selectionSetStatic id=“problemSelectionSet” typeRef=“problemType” /> </selection>
</notify>
- “optionCancel”: Giống với “option” nhưng khác chỗ người sử dụng cũng có thể chọn cancel;
- “custom” (giá trị mặc định): kiểu Custom. Trong trường hợp này, thẻ <notify> (xem điều 10.1) phải có các thẻ con quy định cái mà đầu vào từ người sử dụng được yêu cầu (xem điều 10.10). Sau khi người sử dụng cung cấp đầu vào thì họ phải xác nhận thông báo;
- “customCancel”: Giống với “custom” nhưng khác chỗ người sử dụng có thể chọn cancel.
CHÚ THÍCH Trong giao diện người sử dụng bằng đồ họa, người sử dụng nhìn thấy một hoặc nhiều thành phần đầu vào (ví dụ: các nút ở radio, các hộp đánh dấu, các trường đầu vào) và nút “OK”. Người sử dụng ấn nút “OK” khi mà họ xác minh rằng tất cả các giá trị được thiết lập theo mong muốn.
10.4 Thuộc tính ‘category’
Thẻ <notify> (xem điều 10.1) có thể có thuộc tính ‘category’. Hạng mục của thẻ <notify> mô tả bản chất của thông báo.
CHÚ THÍCH 1 URC có thể sử dụng thông tin hạng mục để đáp lại thông báo theo nhiều cách khác nhau. Ví dụ, các hình tượng khác nhau có thể được sử dụng để cho biết mức độ khẩn cấp của cho người sử dụng.
CHÚ THÍCH 2 Hạng mục khác với kiểu thông báo. Về cơ bản, mọi liên kết của các kiểu và hạng mục có thể xảy ra.
Thuộc tính ‘category’ phải có một trong các giá trị sau đây: - “info”: đích đang cung cấp thông tin cho người sử dụng;
- “alert”: đích đang báo động cho người sử dụng về một tình huống - “error”: đích phát hiện ra lỗi.
VÍ DỤ 1 Để thông báo cho người sử dụng sự trễ chuyến bay, hạng mục info là thích hợp.
VÍ DỤ 2 Để thông báo cho người sử dụng rằng thang máy đang đến tầng yêu cầu, hạng mục alert là thích hợp.
VÍ DỤ 3 Để thông báo cho người sử dụng rằng chỉ 2 trong số 10 mục yêu cầu là sẵn có, hạng mục error là thích hợp.
Giá trị mặc định phải là “info”.
10.5 Thuộc tính ‘sensitive’
Thẻ <notify> (xem điều 10.1) có thể có thuộc tính ‘sensitive’. Nó là kiểu dữ liệu Boolean cho biết liệu thông báo biểu diễn hoạt động nhạy cảm hợp pháp hay không.
VÍ DỤ Thông báo có thể cung cấp một cảnh báo về an toàn mà dạng trình diễn của nó có các phép tất duy hợp pháp. Ví dụ này được mô tả với phép đánh dấu:
<notify id=“fireAlarmWarning” sensitive=“true” /> Giá trị mặc định phải là “false”.
10.6 Thuộc tính ‘optional’
Thẻ <notify> (xem điều 10.1) có thể có thuộc tính ‘optional’ của kiểu Boolean. Giá trị mặc định của nó phải là “false”.
Nếu optional =“true” thì thông báo không sẵn có tại thời gian chạy do các ràng buộc khác nhau. CHÚ THÍCH 1 Các ví dụ về các ràng buộc tác động lên tính sẵn có của thẻ socket là: điều khiển truy cập, các sản phẩm khác nhau sử dụng mô tả socket chung với một số biến đổi về cài đặt (như là trong UPnP DCPs).
CHÚ THÍCH 2 Tính sẵn có của thẻ socket phải được chỉ ra cho URC tại thời gian chạy thông qua phương tiện đặc trưng cho TUN (xem TCVN 11523-1 (ISO/IEC 24752-1)).
10.7 Thuộc tính ‘dim’
Thuộc tính ‘dim’ quy định thông báo là thứ nguyên (với một hoặc nhiều thứ nguyên). Tại thời gian chạy, thông báo thứ nguyên có nhiều trạng thái, mỗi trạng thái cho một liên kết các chỉ mục riêng.
Thẻ <notify> (xem điều 10.1) có thể có thuộc tính ‘dim’. Nếu hiện diện thì nó phải chứa danh sách không trống, có thứ tự, phân cách bằng khoảng trống của các tham chiếu kiểu mà là các kiểu chỉ số của thông báo. Tham chiếu đầu tiên quy định kiểu chỉ số cho thứ nguyên đầu tiên, kiểu thứ hai cho thứ nguyên thứ hai, v.v...Các tham chiếu kiểu chỉ số hợp lệ là (a) tên của kiểu mà được xác định hoặc nhập trong phần <xsd:schema> của mô tả socket, hoặc (b) tên định tính (QName) của kiểu bên ngoài. Chỉ số của thông báo không có giá trị ‘ttc’ mà được dành riêng để biểu thị trường ‘ttc’ của nó (xem điều 5.2.5.2).
CHÚ THÍCH 1 Tập lớn nhất của các giá trị cho thông báo socket riêng do sản phẩm của tất cả các kiểu chỉ số mà xuất hiện khi đi trên đường truyền từ thẻ <uiSocket> xuống thông báo socket riêng (xem định nghĩa đường truyền trong điều 5.2.5.2). Tuy nhiên, không phải mọi liên kết có thể xuất hiện tại thời gian chạy.
CHÚ THÍCH 2 Không có việc sắp xếp thứ tự rõ ràng xác định cho các thực thể do thông báo thứ
nguyên. Tuy nhiên, việc sắp xếp thứ tự dựa trên thứ tự của các giá trị chỉ số được khuyến cáo cho đích - trong quá trình truyền tải các trạng thái đến URC - và cho URC - trong việc đưa ra các trạng thái cho người sử dụng (xem TCVN 11523-1 (ISO/IEC 24752-1)).
CHÚ THÍCH 3 Kiểu chỉ số có thể quy định số giá trị chỉ số không giới hạn (ví dụ: xsd:integer có các giá trị không giới hạn). Tuy nhiên, các giá trị chỉ số thực tế tại thời gian chạy là tập con không giới hạn của các giá trị được cho phép bởi kiểu chỉ số.
CHÚ THÍCH 4 Việc sử dụng lệnh thứ nguyên chỉ hợp lý nếu tập các thông báo là đồng nhất, tức là mỗi lệnh có các đặc tính giống hệt nhau bao gồm nhãn (thông điệp) và văn bản trợ giúp.
CHÚ THÍCH 5 Các tham chiếu (ví dụ: từ các tài nguyên nguyên tử) đến các thông báo thứ nguyên tham chiếu các thành phần riêng lẻ của thông báo. Ví dụ, URI
http://example.com/thermometer/socket#alert tham chiếu đến mọi thành phần thông báo đơn trong thông báo thứ nguyên với id=’alert’. Tuy nhiên, URI http://
example.com/thermometer/socket#dims(alert) tham chiếu đến toàn bộ thông báo với tất cả các thành phần. Xem TCVN 11523-1 (ISO/IEC 24752-1) để biết thêm chi tiết.
CHÚ THÍCH 6 Thứ tự mà các thành phần của thông báo thứ nguyên đưa ra cho người sử dụng được dựa trên việc sắp xếp thứ tự đã xác định của các kiểu chỉ số thích hợp. Xem TCVN 11523-1 (ISO/IEC 24752-1) để biết thêm chi tiết.
10.8 Thuộc tính ‘timeout’
Thẻ <notify> (xem điều 10.1) có thể có thuộc tính ‘timeout’ nhằm cho biết rằng thông báo sẽ không tính thời gian khi hoạt động. Nếu hiện diện thì thuộc tính ‘timeout’ phải có giá trị kiểu xsd:duration, quy định thời gian chờ mặc định cho thông báo.
VÍ DỤ Mã sau đây biểu diễn thông báo với thời gian chờ mặc định 1 phút hoặc 15 giây. <notify id=“timeoutNotification” type=“yesNo” timeout=“PT1M15S” />
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áo10.9.1 Khái quát 10.9.1 Khái quát
Thẻ <dependency> có thể hiện diện như thẻ con của <notify> (xem điều 10.1). Nếu hiện diện nó sẽ xuất hiện một lần.
10.9.2 Phần phụ thuộc <insert>
Phần phụ thuộc <insert> quy định liệu người sử dụng có thể sửa đổi tập các liên kết chỉ số hợp lệ có liên quan ở thời gian chạy hay không (với tập có liên quan là các chỉ số quy định bởi thuộc tính ‘dim’ trên thẻ <notify> tương ứng, xem điều 10.1).
Nội dung của phần phụ thuộc <insert> phải là biểu thức Xpath đánh giá giá trị Boolean mà có thể thay đổi trong suốt phiên. Nếu nó đánh giá là false thì sẽ không thích hợp để thêm vào hoặc xóa một liên kết chỉ số; mặt khác biểu thức Xpath cố gắng thêm vào hoặc xóa một liên kết chỉ số mặc dù không có sự đảm bảo rằng nó sẽ thành công.
CHÚ THÍCH 1 “Thêm vào một liên kết chỉ số” có nghĩa là thêm vào thành phần thông báo cho liên kết chỉ số mới trong khoảng trống chỉ số xác định bởi thuộc tính ‘dim’ tương ứng. Chú ý rằng tình trạng của thành phần thông báo thêm vào được định rõ bởi đích. “Bỏ đi một liên kết chỉ số” có nghĩa là xóa một thành phần thông báo cho liên kết chỉ số riêng hiện đang diễn ra.
Thẻ <insert> có thể hiện diện như thẻ con của thẻ <dependency> (xem điều 10.9.1) chỉ khi thẻ <notify> có thuộc tính ‘dim’ (xem điều 10.7). Nếu hiện diện thì nó sẽ xảy ra một lần.
Giá trị mặc định của nó phải là “false()”.
CHÚ THÍCH 2 Không có sự kế thừa từ phần phụ thuộc <insert> của thẻ <set> (xem điều 7.4.4) tới phần phụ thuộc của thẻ <notify> chứa đựng (xem điều 8.1). Mỗi phần phụ thuộc <insert> chỉ gắn liền với tập các chỉ số được quy định bởi thuộc tính ‘dim’ của mức tương ứng.
10.10 Các biến và các lệnh thông báo
Các thông báo custom, tức là không hiện diện thuộc tính ‘type’ hoặc type =“custom” (xem điều 10.3), thẻ <notify> (xem điều 10.1) phải chứa một hoặc nhiều thẻ <variable> hoặc<command>, với tất cả các thuộc tính và các thẻ con thích hợp quy định trong Điều 8 và Điều 9. Đối với các kiểu thông báo trừ “custom”, thẻ <notify> không được chứa bất kỳ thẻ <variable> hoặc <command> nào.
Các biến hoặc các lệnh thông báo phải có giá trị không xác định và không được đưa ra cho người sử dụng trừ khi thông báo hoạt động.
Khi thông báo hoạt động thì hội thoại theo chế độ phải được đưa ra cho người sử dụng, bao gồm tất cả các biến và các lệnh chứa trong có liên quan được quy định bởi các phần phụ thuộc riêng lẻ. Sau đó người sử dụng có thể tương tác với các thẻ chứa trong nó, tức là thay đổi giá trị của biến và/hoặc kích