Tiêu chuẩn Quốc gia TCVN 11523-6:2016 ISO/IEC 24752-6:2014 Công nghệ thông tin-Giao diện người sử dụng-Bộ điều khiển từ xa phổ dụng-Phần 6: Tích hợp dịch vụ web

TIÊU CHUẨN QUỐC GIA

TCVN 11523-6:2016

ISO/IEC 24752-6:2014

CÔNG NGHỆ THÔNG TIN - GIAO DIỆN NGƯỜI SỬ DỤNG - BỘ ĐIỀU KHIỂN TỪ XA PHỔ RỘNG - PHẦN 6: TÍCH HỢP DỊCH VỤ WEB

Information technology - User interfaces - Universal remote console - Part 6: Web service integration

Lời nói đầu

TCVN 11523-6:2016 hoàn toàn tương đương với ISO/IEC 24752-6:2014

TCVN 11523-6:2016 do Tiểu Ban kỹ thuật tiêu chuẩn quốc gia TCVN/JTC 1/SC 35 Giao diện người sử dụng biên soạn, Tổng cục Tiêu chuẩn Đo lường Chất lượng đề nghị, Bộ Khoa học và Công nghệ công bố.

Bộ tiêu chuẩn TCVN 11523 Công nghệ thông tin - Giao diện người sử dụng - Bộ điều khiển từ xa phổ dụng gồm sáu phần:

- TCVN 11523-1:2016 (ISO/IEC 24752-1:2014), Phần 1: Khung tổng quát chung

- TCVN 11523-2:2016 (ISO/IEC 24752-2:2014), Phần 2: Mô tả socket giao diện người sử dụng

- TCVN 11523-3:2016, Phần 3: Khuôn mẫu trình bày

- TCVN 11523-4:2016 (ISO/IEC 24752-4:2014), Phần 4: Mô tả đích

- TCVN 11523-5:2016 (ISO/IEC 24752-5:2014), Phần 5: Mô tả tài nguyên

- TCVN 11523-6:2016 (ISO/IEC 24752-6:2014), Phần 6: Tích hợp dịch vụ web

CÔNG NGHỆ THÔNG TIN - GIAO DIỆN NGƯỜI SỬ DỤNG - BỘ ĐIỀU KHIỂN TỪ XA PHỔ DỤNG - PHẦN 6: TÍCH HỢP DỊCH VỤ WEB

Information technology - User interfaces - Universal remote console - Part 6: Web service integration

1  Phạm vi áp dụng

Tiêu chuẩn này xác định cú pháp và ngữ nghĩa đối với việc mô tả đích được cài đặt và mô tả socket trong đặc tả giao diện của dịch vụ web sao cho có ánh xạ rõ ràng giữa các thẻ riêng biệt trong tài liệu WSDL và các thẻ mô tả đích (ngầm định) và mô tả socket (ngầm định).

2  Sự phù hợp

Tài liệu WSDL1 phù hợp với tiêu chuẩn này nếu tuân theo đặc tả ngôn ngữ mô tả dịch vụ web (WSDL) 1.1, các yêu cầu và khuyến cáo trong điều 6 và điều 7.

Tài liệu WSDL2 phù hợp với tiêu chuẩn này nếu tuân theo đặc tả ngôn ngữ mô tả dịch vụ web (WSDL) 2.0, các yêu cầu và khuyến cáo trong điều 6 và điều 7.

CHÚ THÍCH  Sự phù hợp chặt chẽ về ngôn ngữ (không có các thẻ hoặc thuộc tính bổ sung nào được phép) không được yêu cầu bởi vì các phiên bản tương lai của tiêu chuẩn này có thể thêm vào các thẻ, các thuộc tính hoặc các giá trị mới. Do đó, các nhà sản xuất URC được khuyến khích cài đặt các URC của họ sao cho việc đánh dấu sẽ được bỏ qua mà không gây ra lỗi.

Dịch vụ web phù hợp với tiêu chuẩn này nếu thực hiện các yêu cầu về đích trong TCVN 11523-1 (ISO/IEC 24752-1) theo tất cả các cách sau đây.

- Dịch vụ web phải cung cấp ít nhất một liên kết dịch vụ (như đã xác định trong tài liệu WSDL của dịch vụ web) là socket mạng URC đích

- Dịch vụ web phải có tên đích, được đưa ra là vùng tên đích của dịch vụ web, như đã xác định trong điều 7.5.2.

- Dịch vụ web phải có chính xác một mô tả đích được cài trong tài liệu WSDL và phải bao bồm các tham chiếu đối với các tệp bên ngoài có chứa tài nguyên đích (tệp tạo nhóm và tệp tài nguyên) phù hợp với ít nhất một ngôn ngữ tự nhiên, như đã xác định trong điều 7.5.

- Dịch vụ web phải bao gồm cơ chế tìm nạp đối với tài nguyên đích của nó (tệp tạo nhóm, tệp tài nguyên, UIID) do URI tìm kiếm, bao gồm hỗ trợ đối với các kiểu MIME.

- Dịch vụ web phải cung cấp định danh thực thể đích thông qua hoạt động ‘getTargetInstanceld’ trong phần “_target”, như đã xác định trong điều 7.5.11.2

- Dịch vụ web phải hỗ trợ các hàm định vị thông qua phần “_target”, như đã xác định trong điều 7.5.7.

- Dịch vụ web phải biểu lộ một hoặc nhiều socket, khi được xem xét cùng nhau, bao phủ toàn bộ chức năng của dịch vụ web là đích. Đối với mỗi kết nối, mô tả socket phải được cài vào trong tài liệu WSDL của dịch vụ web (như đã xác định trong điều 7.6).

- Đối với mỗi socket của dịch vụ web, socket phải có các biến bao gồm tất cả các dữ liệu động trên trạng thái socket người sử dụng có thể hiểu và/hoặc thao tác và ra lệnh rằng tất cả các hàm socket có thể được người sử dụng gọi rõ ràng hoặc ngầm định và các thông báo bao gồm tất cả các ngoại lệ mà dịch vụ web cần thông báo cho người sử dụng.

- Dịch vụ web phải cung cấp một tài nguyên tạo nhóm đối với mỗi socket thông qua tệp tạo nhóm ngoài.

- Dịch vụ web phải bao gồm tài nguyên ký hiệu nguyên bản thông qua tệp tài nguyên bên ngoài, trong ít nhất một ngôn ngữ tự nhiên.

- Dịch vụ web phải bao gồm tài nguyên nguyên tử động tại thời gian chạy thực đối với các thẻ socket đó mà không có sẵn tài nguyên nguyên tử (tĩnh) trong tài nguyên đích, như đã xác định trong các điều 7.6.21.5, 7.6.22.5 và 7.6.23.6.

- Dịch vụ web, nếu mô tả một yêu cầu phiên, phải hỗ trợ yêu cầu vùng mở từ URC, như được mô tả trong điều 7.6.15.

- Dịch vụ web, nếu mô tả một yêu cầu phiên, phải hỗ trợ sự kiện vùng đóng từ URC, như được mô tả trong điều 7.6.16.

- Dịch vụ web, nếu mô tả một yêu cầu phiên, phải hỗ trợ sự kiện vùng treo từ URC, như đã xác định trong điều 7.6.17.

- Dịch vụ web, nếu mô tả một yêu cầu phiên, phải hỗ trợ sự kiện vùng khôi phục từ URC, như đã xác định trong 7.6.18.

- Dịch vụ web, nếu mô tả một yêu cầu phiên, phải gửi sự kiện vùng hủy trong trường hợp hủy phần người sử dụng, như đã xác định trong điều 7.6.14.

- Dịch vụ web phải theo dõi thông tin trạng thái socket từ mạng dưới mà hoạt động của nó liên kết

- Dịch vụ web, nếu mô tả một yêu cầu phiên, phải gửi sự kiện chuyển tiếp vùng tới URC trong trường hợp chuyển tiếp vùng, như đã xác định trong điều 7.6.14.

- Dịch vụ web, nếu mô tả một yêu cầu phiên, phải tạo ra và duy trì một vùng giữa socket với URC sau khi yêu cầu vùng mở thành công.

- Dịch vụ web phải biểu thị với URC sự sẵn sàng của các thẻ socket tại thời gian thực (các thẻ socket không sẵn sàng có giá trị không xác định)

- Dịch vụ web phải đồng bộ hóa biến socket giữa socket và URC tham gia vào vùng liên kết với socket (bằng phương thức hoạt động cập nhật và hoạt động của các biến)

- Dịch vụ web phải hỗ trợ yêu cầu dẫn lệnh từ URC (bao gồm xử lý các thông số cục bộ) và đồng bộ hóa trạng thái lệnh (bằng phương thức hoạt động lệnh).

- Dịch vụ web phải hỗ trợ sự lan truyền của các trạng thái thông báo và, đối với thông báo dạng tùy chỉnh, các lệnh và biến được cài, với URC được socket, và chấp nhận sự thừa nhận thích đáng (bằng phương thức hoạt động cập nhận hoạt động kiểm tra).

- Dịch vụ web phải đồng bộ hóa các chỉ số thực của cặp socket và các thẻ (bằng phương thức hoạt động chỉ số).

- Dịch vụ web không phụ thuộc vào URC thực hiện diễn giải sự phụ thuộc thẻ socket.

- Cung cấp các cơ chế sau liên quan đến thời gian chờ hồi đáp người sử dụng:

a) sau khi gia hạn thời gian chờ, quay lại với trạng thái tác vụ người sử dụng đã đạt được trước thời gian chờ;

b) hỗ trợ hoạt động gia hạn thời gian chờ (xem điều 7.6.23.4) đối với các thông báo thời gian chờ và để cho khách hàng gia hạn thời gian chờ ít nhất năm lần thời gian chờ mặc định;

c) ghi nhận thông báo thời gian chờ ít hơn 10 giây.

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

Các tài liệu viện dẫn sau đây rất cần thiết cho áp dụng tiêu chuẩn này. Đối với các tài liệu viện dẫn ghi năm công bố thì áp dụng bản được nêu. Đối với các tài liệu viện dẫn không ghi năm công bố thì áp dụng phiên bản mới nhất (bao gồm cả các sửa đổi, bổ sung).

TCVN 11523-1 (ISO/IEC 24752-1), Công nghệ thông tin - Giao diện người sử dụng - Bộ điều khiển từ xa phổ dụng - Phần 1: Khung khái quát

ISO/IEC 24752-2:20131, Information technology - User interfaces - Universal remote console - Part 2: User interface socket description (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)

ISO/IEC 24752-4:20132, Information technology - User interfaces - Universal remote console - Part 4: Target description (Công nghệ thông tin - Giao diện người sử dụng - Bộ điều khiển từ xa phổ dụng - Phần 4: Mô tả đích

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

Tiêu chuẩn này áp dụng các thuật ngữ nêu trong TCVN 11523-1 (ISO/IEC 24752-1), TCVN 11523-2 (ISO/IEC 24752-2) và TCVN 11523-4 (ISO/IEC 24752-4) và các thuật ngữ sau đây:

4.1

Mục lỗi (fault item)

Thực thể lỗi có tên của hoạt động dịch vụ web, nghĩa là trong WSDL1 một <message> được tham chiếu từ thẻ <fault> của một <operation>, và trong WSDL2 một thẻ <outfault> của một <operation> tham chiếu lỗi giao diện.

4.2

Mục đầu vào (input item)

Thực thể đầu vào có tên là đối với hoạt động dịch vụ web, nghĩa là trong WSDL1 một <part> của một <message> được tham chiếu từ một thẻ <input> của một <operation>; và trong WSDL2 một thẻ <input> của một <operation>

4.3

Tên thẻ mẻ (item element name)

Tên thẻ XML đối với mục đầu vào hoặc đầu ra, nghĩa là trong WSDL1 giá trị của thuộc tính ‘element’ trên thông điệp gắn với <part>; và trong WSDL2 giá trị của thuộc tính ‘element’ trên thông điệp <input>

4.4

Phân khu (partition)

Phân khu dịch vụ web (Web service partition)

Tập các hoạt động dịch vụ web có tên là (“kiểu cổng” trong WSDL1, “giao diện” trong WSDL2)

4.5

Mục đầu ra (output item)

Thực thể đầu ra từ hoạt động dịch vụ web có tên là, nghĩa là trong WSDL1 thẻ <part> của <message> được tham chiếu từ một thẻ <output> của <operation>, và trong WSDL2 một thẻ <output> của <operation>

4.6

Socket yêu cầu phiên (session-full socket)

Socket của đích yêu cầu phiên

4.7

Socket không yêu cầu phiên (session-less socket)

Socket của đích không yêu cầu phiên

4.8

Tài liệu WSDL1 (WSDL1 document)

Tài liệu phù hợp với đặc tả ngôn ngữ mô tả dịch vụ web (WSDL) 1.1

4.9

Tài liệu WSDL2 (WSDL2 document)

Tài liệu phù hợp với đặc tả ngôn ngữ mô tả dịch vụ web (WSDL) 2.0

5  Mối quan hệ với các tiêu chuẩn khác

5.1  Mối quan hệ với XML

Đặc tả này xây dựng ngôn ngữ đánh dấu có thể mở rộng (XML). Đánh dấu trong XML có phân biệt chữ hoa, chữ thường.

Tên thẻ, tên thuộc tính và các giá trị không thể định vị được, tức là chúng đồng nhất với tất cả các ngôn ngữ quốc tế. Tuy nhiên, nội dung văn bản giữa các thẻ có thể là ngôn ngữ đặc trưng. Với tất cả các ngôn ngữ dựa trên XML, các ký tự khoảng trống trắng bao quanh thẻ là không có nghĩa.

Đặc tả này tận dụng khái niệm các vùng tên xác định để kích hoạt việc nhập các tên của thẻ và thuộc tính đã xác định ở một nơi khác.

Xuyên suốt tài liệu này, tiền tố vùng tên và định danh vùng tên tương ứng sau đây được sử dụng để tham chiếu vùng tên. Tác giả không ràng buộc với các tiếp đầu ngữ, mặc dù vậy được khuyến nghị sử dụng đối với tính dễ dàng đọc được của tài liệu được công bố công khai phù hợp với tiêu chuẩn này .

- dc: Vùng tên tập thẻ siêu dữ liệu Dublin core ("http://purl.org/dc/elements/1.1/") (tập thẻ được xác định theo TCVN 7980 (ISO 15836)):

- dcterms : Vùng tên của các thuật ngữ siêu dữ liệu DCMI (http://purl.org/dc/terms)

- td: vùng tên mô tả đích ("http://openurc.org/ns/targetdesc-2"):

- uis: vùng tên mô tả socket giao diện người sử dụng ("http://openurc.org/ns/uisocketdesc-2"):

- wsdl-urc: vùng tên mở rộng tài liệu WSDL1 hoặc WSDL2 bằng cách cài mô tả đích ngầm định và mô tả socket ngầm định ("http://openurc.org/ns/wsdl-urc"):

- xs: vùng tên lược đồ XML ("http://www.w3.org/2001/XMLSchema"):

- xsi: vùng tên đối tượng lược đồ ("http://www.w3.org/2001/XMLSchema-instance").

6  Mô tả ánh xạ

6.1  Khái quát

Socket giao diện người sử dụng (gọi tắt là “socket”) bao gồm các biến, lệnh, thông báo, tập và xác định kiểu. Giao diện dịch vụ web, như được mô tả theo WSDL1, bao gồm kiểu cổng, hoạt động, thông điệp, các phần thông điệp và xác định kiểu.

Mô tả ánh xạ bao gồm các phần sau: ánh xạ của đích và các đặc tả của nó đối với dịch vụ web và các đặc tả của nó, ánh xạ của từng socket đích, tập và thẻ của nó đối với một trong các phân khu của dịch vụ web và thẻ của nó.

CHÚ THÍCH 1  phân khu dịch vụ web là đơn vị chức năng của dịch vụ web. Trong WSDL1, nó có tên là kiểu cổng (thẻ <portType>), trong WSDL2 và giao diện (thẻ <interface>).

CHÚ THÍCH 2  phần này xác định các yêu cầu chung (ngữ nghĩa học) đối với mô tả ánh xạ. Phần sau đây xác định cú pháp cụ thể đối với mô tả ánh xạ.

Hình 1  Ánh xạ lược đồ biến socket, lệnh socket, và nhận thẻ thông báo socket, tập, nhận tài nguyên, lệnh, nhận trạng thái, kiểm tra, thời gian chờ gia hạn và hoạt động báo nhận do phân khu giao diện dịch vụ web cung cấp. Mũi tên chỉ dòng nội dung socket. Mũi tên đứt quãng biểu thị hoạt động tùy chọn. Lưu ý rằng bàn phím điều khiển từ xa đa năng (được mô tả bên phía trái bằng màu ghi) được bao gồm nhằm cung cấp thông tin ngữ cảnh cho socket, tuy nhiên không thuộc phạm vi của tiêu chuẩn này (xem TCVN 11523-1 (ISO/IEC 24752-1) để biết thêm thông tin về bàn phím điều khiển từ xa đa năng)

CHÚ THÍCH 3  Trong các điều sau, ánh xạ được đưa ra đối với các đích, socket, biến, lệnh, thông báo và xác định kiểu. Tuy nhiên, ánh xạ đối với các tập được chứa một cách ngầm định trong ánh xạ đối với các biến, lệnh và thông báo (phản ánh cấu trúc socket).

6.2  Ánh xạ một đích tới dịch vụ web

Mô tả ánh xạ phải ánh xạ chính xác một đích tới một dịch vụ web chính xác. Đích phải được xác định theo tên (URI) và dịch vụ web theo vùng tên đích của nó

6.3  Ánh xạ socket tới phân khu dịch vụ web

Mô tả ánh xạ sẽ ánh xạ socket của đích được ánh xạ tới các phân khu của dịch vụ web được ánh xạ tới đích (như đã xác định trong 6.2). Mỗi socket bao gồm trong ánh xạ phải được ánh xạ tới một phân khu đơn. Kết nối phải được xác định theo tên của chúng (URI), và phân khu dịch vụ web theo tên của chúng.

6.4  Ánh xạ biến socket

6.4.1  Khái quát

Biến socket được ánh xạ tới hoạt động dịch vụ web sau:

- Hoạt động get,

- Hoạt động set (chỉ đối với các biến có thể ghi được), và

- Hoạt động nhận tài nguyên (tùy chọn).

6.4.2  Hoạt động get (nhận)

Mô tả ánh xạ đối với biến socket phải xác định hoạt động get của dịch vụ web không có mục đầu vào và mục đầu ra đơn lẻ. Tại thời gian chờ, hoạt động get phải cung cấp giá trị hiện tại của biến socket thông qua mục đầu ra. Hoạt động get không được thay đổi trạng thái của dịch vụ web. Kiểu biến socket và mục đầu ra của hoạt động get phải tương thích. Khoảng thời gian và thời gian hết hiệu lực đối với kiểm soát vòng phải được xác định đối với mỗi cơ chế ánh xạ.

6.4.3  Hoạt động set (thiết lập)

Trừ khi phần phụ thuộc ghi của biến socket luôn false (nghĩa là biến chỉ ở dạng đọc), mô tả ánh xạ phải xác định hoạt động set của dịch vụ web với mục đầu vào đơn lẻ. Kiểu biến socket và mục đầu vào của hoạt động set phải tương thích. Tại thời gian chờ, hoạt động set cung cấp phương thức chỉnh sửa trạng thái dịch vụ web. Mục đầu vào phải phản ánh giá trị mới được yêu cầu đối với biến. Mục đầu ra phải mang sang giá trị thực của biến sau khi hoạt động kết thúc (nghĩa là giá trị được gán mới nếu hoạt động thành công, hoặc giá trị cũ nếu hoạt động thất bại).

6.4.4  Hoạt động nhận tài nguyên

Mô tả ánh xạ đối với biến socket có thể xác định hoạt động nhận tài nguyên, nếu dịch vụ web muốn cung cấp tài nguyên nguyên tử động đối với biến socket. Nếu hiện diện, hoạt động nhận tài nguyên phải không có mục đầu vào và một mục đầu ra có thẻ <wsdl-urc:resItems>, chuyển tập (có thể trống) mô tả tài nguyên nguyên tử động, mỗi tập được biểu diễn bằng một thẻ <wsdl- urc:aResDesc> có các thẻ con sau:

- <wsdl-urc:content> (of type xs:string) hoặc <wsdl-urc:contentAt> (của kiểu xs:anyURI)

- <dc:type> (tùy chọn) - với mọi giá trị chuỗi sau đây: “Collection”, “Dataset”, “Event”, “Image”, “Interactive Resource”, “Moving Image”, “Physical Object”, “Service”, “Software”, “Sound”, “Still Image”, “Text”

- <dc:format> (tùy chọn) - kiểu MIME hợp lệ

- <wsdl-urc:valRef> (tùy chọn) - of type xs:string

- <wsdl-urc:opRef> (optional) - với mọi URI sau đây: "http://openurc.org/ns/res#up". "http://openurc.org/ns/res#down"

- <wsdl-urc:role> - với mọi URI sau đây: "http://openurc.org/ns/res#label", "http://openurc.org/ns/res#help", "http://openurc.org/ns/res#accesskey", "http://openurc.org/ns/res#keyword", "http://openurc.org/ns/res#location"

- <wsdl-urc:forLang> (optional) - of type xs:language

Các thẻ con này tương ứng với các đặc tả có tên là của mô tả tài nguyên nguyên tử trong tệp tài nguyên (xem TCVN 11523-5 (ISO/IEC 24752-5)). Tuy nhiên, do sự giới hạn thẻ <wsdl-urc:content> chỉ bao gồm nội dung ngữ cảnh và không bao gồm bất kỳ thẻ con (như <title>, <span> hoặc <value>).

VÍ DỤ  biến socket “deviceStatus” được socket với các tài nguyên nguyên tử động sau: (1) nhãn ngữ cảnh đối với giá trị trạng thái hiện tại, và (2) biểu tượng đối với giá trị trạng thái hiện tại. Giá trị trong hiện tại của biến “status” là “2” (nghĩa là trạng thái chờ, tuy nhiên không biết được trước thời gian hoạt động). Mục đầu ra của hoạt động nhận tài nguyên khi đó sẽ giả định mảnh XML sau, miễn là vùng tên mặc định là WSDL-URC "http://openurc.org/ns/wsdl-urc") và tiếp đầu ngữ khoảng trống trên "dc" được ánh xạ tới "http://purl.org/dc/elements/1.1/":

CHÚ THÍCH  Bằng cách gọi hoạt động nhận tài nguyên, khách có thể tìm kiếm tài nguyên động mới (nhãn, ngữ cảnh trợ giúp, khóa tiếp cận, hoặc vị trí) đối với biến socket hoặc đối với bát kỳ giá trị nào của nó. Chú ý rằng cơ chế đơn giản này bị cấm khi nó không cho phép tìm kiếm tài nguyên động đối với các kiểu và giá trị kiểu khác với các phần tử socket và giá trị của chúng. Đồng thời, nó không cho phép xây dựng nhãn ngữ cảnh, hoặc giá trị i tích hợp của thẻ socket.

6.5  Ánh xạ lệnh socket

6.5.2  Khái quát

Lệnh socket phải được ánh xạ vào hoạt động dịch vụ web sau:

- Hoạt động lệnh,

- Hoạt động get trạng thái (chỉ đối với các lệnh có kiểu khác với ‘uis:voidCommand’), và

- Hoạt động nhận tài nguyên (tùy chọn).

6.5.3  Hoạt động lệnh

Mô tả ánh xạ đối với lệnh phải xác định hoạt động lệnh đơn lẻ của dịch vụ web. Tại thời gian chạy, hoạt động lệnh được thực hiện khi lệnh được kích hoạt.

6.5.4  Hoạt động nhận lệnh

Mô tả ánh xạ đối với lệnh có thể xác định hoạt động nhận lệnh đơn lẻ của dịch vụ web, nếu lệnh được thực hiện đồng bộ, nghĩa là nếu lệnh có kiểu khác với uis:voidCommand. Tại thời gian chạy, URC có thể gọi hoạt động nhận lệnh để nhận thông tin về trạng thái lệnh. Giá trị trạng thái có thể là “initial”, “rejected”, “inProgress”, “done”, “succeeded”, và “failed” (xem TCVN 11523-2 (ISO/IEC 24752-2)).

6.5.5  Hoạt động nhận tài nguyên

Mô tả ánh xạ đối với lệnh có thể xác định hoạt động nhận tài nguyên, nếu dịch vụ web muốn cung cấp tài nguyên nguyên tử động đối với lệnh socket. Nếu hiện diện, hoạt động nhận tài nguyên phải có cùng mục đầu vào và đầu ra như đối với hoạt động nhận tài nguyên đối với biến socket (xem 6.4.4).

6.6  Ánh xạ thông báo socket

6.6.2  Khái quát

Thông báo socket phải được ánh xạ tới hoạt động dịch vụ web sau:

- Hoạt động kiểm tra,

- Hoạt động gia hạn thời gian chờ (tùy chọn),

- Hoạt động ghi nhận (chỉ đối với các thông báo của kiểu khác với “show”), và

- Hoạt động nhận tài nguyên (tùy chọn).

6.6.3  Hoạt động kiểm tra

Mô tả ánh xạ đối với thông báo socket phải xác định hoạt động kiểm tra. Tại thời gian chạy, hoạt động kiểm tra thường xuyên được gọi (“polled”) để thu nạp trạng thái thông báo.

6.6.4  Hoạt động gia hạn thời gian chờ

Mô tả ánh xạ đối với thông báo socket phải xác định hoạt động gia hạn thời gian chờ nếu thông báo có thuộc tính ‘timeout’ (xem TCVN 11523-2 (ISO/IEC 24752-2)). Nếu không, nó có thể xác định hoạt động gia hạn thời gian. Tại thời gian chạy, hoạt động gia hạn thời gian chờ có thể được khách gọi yêu cầu gia hạn thời gian chờ thông báo.

6.6.5  Hoạt động ghi nhận

Mô tả ánh xạ đối với thông báo socket phải xác định hoạt động ghi nhận của dịch vụ web, nếu thông báo có kiểu khác với “show”. Dựa trên sự ghi nhận người sử dụng, hoạt động ghi nhận được gọi.

6.6.6  Hoạt động nhận tài nguyên

Mô tả ánh xạ đối với thông báo socket có thể xác định hoạt động nhận tài nguyên, nếu dịch vụ web muốn cung cấp tài nguyên nguyên tử động đối với thông báo socket. Nếu hiện diện, hoạt động nhận tài nguyên phải có cùng mục đầu vào và đầu ra như đối với hoạt động nhận tài nguyên dành cho biến socket (xem 6.4.4).

6.7  Ánh xạ xác định kiểu socket bên trong với xác định kiểu của dịch vụ web

Xác định kiểu socket trong phải được ánh xạ tới xác định kiểu trong mô tả giao diện của dịch vụ web.

CHÚ THÍCH 1  xác định kiểu socket trong được biểu thị bằng thẻ <simpleType> hoặc <complexType> trong phần <xs:schema> của mô tả socket (xem TCVN 11523 (ISO/IEC 24752-2)).

CHÚ THÍCH 2  trong tài liệu WSDL (cả WSDL1 và WSDL2), xác định kiểu được biểu thị bằng thẻ <simpleType> hoặc <complexType> được chứa trong thẻ <xs:schema> trong phần <types>.

7  Mô tả đích nhúng và mô tả socket trong tài liệu WSDL.

7.1  Khái quát

Phần này xác định cú pháp và quy ước đối với việc cung cấp mô tả ánh xạ (xem 6) trong tài liệu WSDL, cung cấp mô tả đích ngầm định và mô tả socket ngầm định. Phương pháp tiếp cận này có thể áp dụng đối với tài liệu WSDL1 và WSDL2, và được dựa trên quy tắc ánh xạ chung (như được tóm tắt trong 6), đặt tên các quy ước và đánh dấu bổ sung trong thẻ <documentation> trong tệp WSDL

CHÚ THÍCH 1  trong một số trường hợp, cú pháp khác giữa WSDL1 và WSDL2. Trong các trường hợp này, cả hai phiên bản được xác định.

CHÚ THÍCH 2  khi sử dụng phương pháp tiếp cận nhúng, cấu trúc của đích và socket của nó được công bố công khai với tài liệu WSDL. Điều này có nghĩa là không thể thực hiện được tính có sẵn của mô tả socket phụ thuộc vào việc mở một phần của người sử dụng (có nhãn quyển thích hợp)

7.2  Giới hạn về vùng tên đích của phần lược đồ bên trong

Tài liệu WSDL phải xác định kiểu trong vùng tên tương tự như vùng tên đích của tài liệu WSDL, trừ khi các kiểu được nhập từ vùng tên ngoài qua lệnh <xs:import>

VÍ DỤ  vùng tên đích của phần xác định kiểu giống như vùng tên đích của tài liệu tổng thể WSDL (WSDL1). Dạng mẫu WSDL2. Elip (“...”) biểu thị sự bỏ qua.

7.3  Giới hạn về định danh trong mô tả socket và đích

Giá trị của các thuộc tính ‘id’ trên thẻ XML trong mô tả đích hoặc mô tả socket mà được ánh xạ một cách ngầm định với tài liệu WSDL1 hoặc WSDL2 phải được giới hạn như sau:

- Không được bắt đầu với ký tự gạch dưới (‘_’).

- Không được chứa ký tự dấu chấm (‘.’).

- Không chứa ký tự gạch nối (‘-’)

CHÚ THÍCH  tên phần từ bắt đầu với gạch dưới được giữ để sử dụng nội bộ (ví dụ trường timeToComplete đối với lệnh về thời gian). Dấu chấm không được phép do chúng được sử dụng trong thuộc tính ‘name’ trong tài liệu WSDL làm dấu phân cách giữa thông báo và các lệnh và biến được chứa của chúng.

7.4  Giá trị thuộc tính ‘name’

Tài liệu WSDL chứa thuộc tính ‘name’ trên các thẻ khác nhau nhằm xác định mô tả đích ngầm định và mô tả socket giao diện người sử dụng ngầm định, và các thành phần của chúng (xem các phần tiếp theo)

Giá trị của các thuộc tính ‘name’ này phải là đơn nhất trong tài liệu WSDL, qua tất cả các kiểu thẻ.

CHÚ THÍCH  điều này chặt chẽ hơn so với WSDL yêu cầu tính đơn nhất của giá trị thuộc tính 'name’ trong cùng kiểu thẻ.

7.5  Mô tả đích ngầm định

7.5.1  Khái quát

Đích phải trình bày mô tả đích ngầm định, nhúng trong tài liệu WSDL của nó, như được mô tả trong các phần sau. Tham chiếu TCVN 11523-4 (ISO/IEC 24752-4) đối với ngữ nghĩa của các mục thông tin của mô tả đích.

7.5.2  Tên đích

Định danh thống nhất toàn cục của đích (thuộc tính ‘name’, xem TCVN 11523-4 (ISO/IEC 24752-4)), phải được xác định là giá trị của thuộc tính ‘targetNamespace’ của thẻ gốc WSDL (<definitions> trong WSDL1, <description> trong WSDL2). Giá trị của nó phải là URI.

VÍ DỤ 1  trong WSDL1, tên đích được xác định qua thuộc tính 'targetNamespace' của thẻ <definitions>. Elip (“...”) biểu thị sự bỏ qua trong mã.

VÍ DỤ 2  trong WSDL2, tên đích được xác định qua thuộc tính ‘targetNamespace’ của thẻ <description>. Elip (“...”) biểu thị sự bỏ qua trong mã.

7.5.3  Thẻ <wsdl-urc:hidden>

Thẻ <wsdl-urc:hidden> có thể xuất hiện như thẻ con của thẻ <documentation> bên dưới thẻ gốc (<definitions> trong WSDL1, <description> trong WSDL2). Nếu hiện diện, nó phải có giá trị Boolean (nghĩa là hoặc “true” hoặc “false”). Giá trị mặc định là “false”.

Điều này tương ứng với thuộc tính ‘ẩn’ trên thẻ <td:target> trong mô tả đích (xem TCVN 11523-4 (ISO/IEC 24752-4)).

VÍ DỤ  trong ví dụ này, đích được xác định là ẩn. Lưu ý rằng việc đánh dấu này là cho WSDL1 và WSDL2.

7.5.4  Thẻ <dcterms:conformsTo>

Một hoặc nhiều thẻ <dcterms:conformsTo> phải xuất hiện như thẻ con của thẻ <documentation> dưới thẻ gốc (<definitions> trong WSDL1, <description> trong WSDL2). Mỗi thẻ phải có URI là lượng thẻ, xác định tiêu chuẩn được thiết lập mà theo đó dịch vụ web tương ứng.

Giá trị “http://openurc.org/ns/wsdl-urc/isoiec24752-6-2013” biểu thị rằng dịch vụ web tuân theo tiêu chuẩn này.

VÍ DỤ  trong ví dụ này, mô tả dịch vụ web được xác định là phù hợp với tiêu chuẩn này. Lưu ý rằng việc đánh dấu này dành cho WSDL1 và WSDL2.

CHÚ THÍCH 1  khách của dịch vụ web có thể phân tích mô tả dịch vụ web và tìm kiếm sự xuất hiện của <dcterms:conformsTo> để tìm ra liệu dịch vụ web có mô tả đích một cách ngầm định hay không.

7.5.5  Thẻ <dcterms:modified>

Thẻ <dcterms:modifìed> có thể xuất hiện như thẻ con của thẻ <documentation> dưới thẻ gốc (<definitions> trong WSDL1, <description> trong WSDL2). Nếu xuất hiện, nội dung của nó phải là kiểu xs:date hoặc xs:dateTime. Thẻ <dcterms:modified> biểu thị rằng mô tả đích ngầm định đã được sửa đổi từ bản gốc trong khi vẫn tham chiếu cùng đích.

VÍ DỤ  Trong ví dụ này, mô tả đích ngầm định được đánh dấu là phiên bản từ ngày 21 tháng 10 năm 2010. Việc đánh dấu này được thực hiện cho WSDL1 và WSDL2.

CHÚ THÍCH  <dcterms:modified> phù hợp với điều khoản siêu dữ liệu Dublin Core Core đã được sửa đổi, http://purl.org/dc/terms/modified.

7.5.6  Các đặc tính của đích khác từ DCMI

Bất kỳ thẻ và bộ lọc thẻ nào từ tập các thuật ngữ siêu dữ liệu khởi đầu siêu dữ liệu Dublin Core (DCMI) có thể được sử dụng để mô tả đích, nếu phù hợp (như đã xác định trong ISO 15836). Mỗi thẻ có thể xuất hiện nhiều lần là thẻ con của thẻ <documentation> dưới thẻ gốc (<definitions> trong WSDL1, <description> trong WSDL2).

Cụ thể, các thuật ngữ DCMI sau có thể được áp dụng đối với đích (trình bày thông qua dịch vụ web)

- <dc:identifier> xác định mã sản phẩm (hoặc mã thực thể) của đích

- <dc:creator> xác định nhà sản xuất đích

- <dc:publisher> xác định nhà cung cấp đích

- <dc:contributor> xác định nhà đồng sản xuất đích

Thuộc tính ‘xsi:type’ được sử dụng để xác định lược đồ mã hóa, nếu phù hợp

VÍ DỤ  định danh cụ thể công ty được cung cấp cho đích, dựa trên lược đồ mã hóa 'myComp:companyCode’.

7.5.7  Thẻ <wsdl-urc:resSheet>

7.5.7.1  Khái quát

Bất kỳ thẻ <wsdl-urc:resSheet> nào có thể xuất hiện như thẻ con của thẻ <documentation> dưới thẻ gốc (<defInitions> trong WSDL1, <description> trong WSDL2), mỗi thẻ đưa ra tham chiếu đến tệp tài nguyên do nhà cung cấp đích cung cấp và có sẵn trong mạng cục bộ.

CHÚ THÍCH 1  tệp tài nguyên là tập các tài nguyên nguyên tử, như đã xác định trong TCVN 11523-5 (ISO/IEC 24752-5).

Tệp tài nguyên được tham chiếu theo phương thức này có thể bao gồm các tài nguyên nguyên tử đối với một hoặc nhiều socket đích, cũng như đối với chính đích (ví dụ nhãn đích).

VÍ DỤ  trong ví dụ này, tệp tài nguyên có câu lệnh và nhãn biểu tượng đối với ngữ cảnh tiếng Anh được tham chiếu. Tệp tài nguyên này chứa câu lệnh và nhãn biểu tượng đối với chính đích, bộ định vị, socket với name="socket", và đối với tệp tạo nhóm từ ví dụ 7.5.9.1. Chú ý rằng đánh dấu này dành cho WSDL1 và WSDL2.

CHÚ THÍCH 2  thẻ <wsdl-urc:resSheet> đưa ra khả năng nhà sản xuất đích cung cấp tệp tài nguyên “default” trong mạng cục bộ. Các tệp tài nguyên khác - có khả năng phù hợp với ngữ cảnh sử dụng riêng biệt - có thể được tìm kiếm từ máy chủ tài nguyên (xem 7.5.1.1) do nhà sản xuất đích hoặc bên thứ ba cung cấp.

7.5.7.2  Thuộc tính ‘about’

Thẻ <wsdl-urc:resSheet> (xem 7.5.8.1) có thể có thuộc tính 'about' của vùng tên ‘wsdl-urc’, xác định định danh rõ ràng của tệp tài nguyên. Đây phải là định danh thống nhất toàn cục dưới dạng định danh tài nguyên đồng nhất (URI, như đã xác định trong IETF RFC 3986) mà không có định danh đoạn nào được gắn vào. URI này có thể hoặc không thể giải quyết được.

CHÚ THÍCH 1  thuộc tính ‘about’ tương ứng với thuộc tính ‘rdf:about’ trên thẻ <resSheet> trong tệp tài nguyên (xem TCVN 11523-5 (ISO/IEC 24752-5)), mặc dù vùng tên khác nhau.

CHÚ THÍCH 2  URI do thuộc tính ‘about’ cung cấp có thể hoặc không thể giải quyết được. Trong bất kỳ trường hợp nào, sử dụng URI do <retrieveFrom> cung cấp (xem 7.5.8.6) để tìm kiếm tệp tài nguyên.

CHÚ THÍCH 3  định danh là giá trị của thuộc tính ‘about’ phù hợp với định danh siêu dữ liệu Dublin Core, http://purl.org/dc/elements/1.1/identifier.

7.5.7.3  Thẻ <dcterms:conformsTo>

Thẻ <wsdl-urc:resSheet> (xem 7.5.8.1) phải có một hoặc nhiều thẻ con <dcterms:conformsTo>, mỗi thẻ xác định tham chiếu đến tiêu chuẩn được thiết lập theo đó tệp tài nguyên và nội dung của nó (mô tả tài nguyên nguyên tử) phù hợp. Giá trị của mỗi thẻ <dcterms.conformsTo> phải là URI (như đã xác định trong IETF RFC 3986), và phải được cung cấp như nội dung thẻ.

VÍ DỤ  mã hóa sau xác định tệp tài nguyên phù hợp với TCVN 11523-5 (ISO/IEC 24752-5), năm 2013:

<dcterms: confomsTo>http: //openurc.org/ns/res/isoiec24752-5-2013<dcterms:conformsTo/>

CHÚ THÍCH 1  thẻ <dcterms.conformsTo> tương ứng với phần từ <dcterms:conformsTo> là thẻ con của <ResSheet> trong tệp tài nguyên (xem TCVN 11523-5 (ISO/IEC 24752-5)).

CHÚ THÍCH 2  giá trị của thẻ <dcterms:conformsTo> có thể được sử dụng khi thử sự phù hợp của tệp tài nguyên.

7.5.7.4  Các đặc tính tệp tài nguyên khác từ DCMI

Thẻ <wsdl-urc:resSheet> (xem 7.5.8.1) có thể có bất kỳ số thẻ và bộ bộ lọc thẻ từ thuật ngữ siêu dữ liệu Dublin Core (xem ISO 15836) như thẻ con, nếu phù hợp, để mô tả tệp tài nguyên. Mỗi một thẻ có thể xuất hiện nhiều lần.

Cụ thể, thuật ngữ siêu dữ liệu Dublin Core sau có thể xuất hiện:

- <dc:creator>

- <dc:publisher>

- <dc:contributor>

- <dc:rights>

- <dc:title> (with optional ‘xml:lang’ attribute)

7.5.7.5  Thẻ <wsdl-urc:scents>

Thẻ <wsdl-urc:resSheet> (xem 7.5.8.1) có thể có thẻ con <wsdl-urc:scents>.

Nếu hiện diện, thẻ <wsdl-urc:scents> có thể có bất kỳ số thẻ con nào, cung cấp các gợi ý đối với dữ liệu bao gồm trong tệp tài nguyên. Sự xuất hiện của mỗi thẻ scent này biểu thị rằng giá trị scent này áp dụng với ít nhất một tài nguyên nguyên tử trong tệp tài nguyên. Các thẻ scent tương tự có thể xuất hiện nhiều lần, nhưng có giá trị khác nhau.

Thẻ scent có thể áp dụng được là thẻ con của thẻ <wsdl-urc:scents> dưới <ResSheet> trong tệp tài nguyên, có giá trị thích hợp được đưa ra là nội dung thẻ (xem TCVN 11523-5 (ISO/IEC 24752-5)). Tuy nhiên, thẻ con của vùng tên “http://openurc.org/ns/res#” được nhập vào vùng tên “http://openurc.org/ns/wsdl-urc”. Thẻ con của vùng tên khác giữ vùng tên gốc của chúng.

CHÚ THÍCH  nhập trong vùng tên "http://openurc.org/ns/wsdl-urc" cần thiết đối với kiểm tra cú pháp tự động với xác định lược đồ XML. Vùng tên "http://openurc.org/ns/res#" được xác định trong thuật ngữ lược đồ RDF và không thích hợp đối với nhập trong tệp XSD thông thường.

Thẻ scent có thể áp dụng được bao gồm:

- <dc:type>

- <dc:format>

- <wsdl-urc:forDomain>

- <wsdl-urc:forLang>

- <dcterms:audience>

- <wsdl-urc:role>

Các thẻ scent của tệp tài nguyên khác từ DCMI

7.5.7.6  Thẻ <wsdl-urc:retrieveFrom>

Thẻ <wsdl-urc:resSheet> (xem 7.5.8.1) phải có thẻ con <wsdl-urc:retrieveFrom>.

Thẻ <wsdl-urc:retrieveFrom> xác định URI (như đã xác định trong IETF RFC 3986), được đưa ra là nội dung thẻ, có thể được sử dụng để tìm kiếm bản sao của tệp tài nguyên tham chiếu mà theo đó được thực hiện sẵn đối với một thực thể trong môi trường mạng cục bộ.

CHÚ THÍCH  tệp tài nguyên tham chiếu có thể được lưu giữ trong mạng cục bộ, hoặc trên internet. Tuy nhiên, nếu được lưu giữ trên internet, nó phải được công khai qua URI xác định URI có thể liên quan, trong trường hợp này nó được dựa trên URI của tài liệu WSDL bao hàm.

7.5.8  Thẻ <wsdl-urc:grpSheet>

7.5.8.1  Khái quát

Bất kỳ số thẻ <wsdl-urc:grpSheet> nào có thể xuất hiện như thẻ con của thẻ <documentation> dưới thẻ gốc (<definitions> trong WSDL1, <description> trong WSDL2), mỗi thẻ đưa ra một tham chiếu đến tệp tạo nhóm do nhà sản xuất đích cung cấp và có sẵn trong mạng cục bộ.

CHÚ THÍCH 1  tệp tạo nhóm là tập của các tài nguyên tạo nhóm, như đã xác định trong TCVN 11523-5 (ISO/IEC 24752-5).

Tệp tạo nhóm được tham chiếu theo phương thức này có thể bao gồm các nhóm đối với một hoặc nhiều socket đích.

VÍ DỤ  tham chiếu đến tệp tạo nhóm mà lớp này cung cấp tạo nhóm đối với socket đích name= “socket”. Tệp tạo nhóm này không có ngôn ngữ cụ thể. Elip (“...”) biểu thị sự bỏ qua.

CHÚ THÍCH  2 thẻ <wsdl-urc:grpSheet> đưa ra khả năng nhà sản xuất đích cung cấp tệp tạo nhóm "default" trong mạng cục bộ. Các tệp tạo nhóm khác mà có khả năng thích hợp hơn đối với ngữ cảnh sử dụng cụ thể, có thể được tìm kiếm từ máy tài nguyên chủ (xem 7.5.1.1) do nhà sản xuất mục hoặc bên thứ ba cung cấp.

7.5.8.2  Thuộc tính 'about'

Thẻ <wsdl-urc:grpSheet> (xem 7.5.9.1) phải có thuộc tính ‘about’ của vùng tên ‘wsdl-urc’, xác định định danh rõ ràng của tệp tạo nhóm. Phải là định danh thống nhất toàn cục dưới dạng định danh tài nguyên đồng nhất (URI), như đã xác định trong IETF RFC 3986, không có định danh mảnh gắn vào.

CHÚ THÍCH 1  thuộc tính ‘about’ tương ứng với thuộc tính 'rdf:about trên thẻ <GrpSheet> trong tệp tạo nhóm (xem TCVN (ISO/IEC 24752-5)), mặc dù vùng tên khác nhau.

CHÚ THÍCH 2  URI được cung cấp bởi thuộc tính ‘about’ có thể hoặc có thể không giải quyết được. Trong bất kỳ trường hợp nào, sử dụng URI được cung cấp bởi <wsdl-urc:retrieveFrom> (xem 7.5.9.6) để tìm kiếm tệp tạo nhóm.

CHÚ THÍCH 3  định danh là giá trị của thuộc tính ‘about’ phù hợp với định danh siêu dữ liệu Dublin Core, http://purl.org/dc/elements/1.l/identifier.

7.5.8.3  Thẻ <dcterms:conformsTo>

Thẻ <wsdl-urc:grpSheet> (xem 7.5.9.1) phải có một hoặc nhiều thẻ con <dcterms:conformsTo>, mỗi thẻ xác định một tham chiếu đến một tiêu chuẩn được thiết lập mà theo đó tệp tạo nhóm và nội dung của nó (tạo nhóm) phù hợp. Giá trị của mỗi thẻ <dcterms.conformsTo> phải là URI (như đã xác định trong IETF RFC 3986), và phải được cung cấp như nội dung thẻ.

VÍ DỤ  mã hóa sau xác định rằng tài nguyên tạo nhóm phù hợp với ISO/IEC 24752-5, năm 2013:

<dcterms:conformsTo>http://openurc.org/ns/res/isoiec24752-5-2013</dcterms:conformsTo>

CHÚ THÍCH 1  thẻ <dcterms.conformsTo> tương ứng với thẻ <dcterms:conformsTo> là thẻ con của <GrpSheet> trong tệp tạo nhóm (xem ISO/1EC 24752-5).

CHÚ THÍCH 2  giá trị của thẻ <dcterms:conformsTo> có thể được sử dụng khi thử tính phù hợp của tệp tạo nhóm

CHÚ THÍCH 3  <dcterms:conformsTo> phù hợp với bộ lọc thẻ siêu dữ liệu Dublin Core conformsTo, http://purl.org/dc/terms/conformsTo, là bộ lọc thẻ gốc Dublin http://purl.org/dc/elements/1.1/relation.

7.5.8.4  Các đặc tính tệp tạo nhóm khác từ DCMI

Thẻ <wsdl-urc:grpSheet> (xem 7.5.9.1) có thể có bất kỳ số thẻ và bộ lọc thẻ nào từ thuật ngữ siêu dữ liệu Dublin Core (xem ISO 15836) là thẻ con, nếu phù hợp, để mô tả tệp tài nguyên. Mỗi một thẻ có thể xuất hiện nhiều lần.

Cụ thể, thuật ngữ siêu dữ liệu Dublin Core sau có thể xuất hiện:

- <dc:creator>

- <dc:publisher>

- <dc:contributor>

- <dc:rights>

- <dc:title> (với thuộc tính tùy chọn ‘xml:lang’)

7.5.8.5  Thẻ <wsdl-urc:scents>

Thẻ <wsdl-urc:grpSheet> (xem 7.5.9.1) có thể có thẻ con <wsdl-urc:scents>.

Nếu hiện diện, thẻ <wsdl-urc:scents> có thể có bất kỳ số thẻ con nào, cung cấp các gợi ý đối với dữ liệu bao gồm trong tệp tài nguyên. Sự xuất hiện của mỗi thẻ scent này biểu thị rằng giá trị scent này áp dụng với ít nhất một tạo nhóm trong tệp tạo nhóm. Các thẻ scent tương tự có thể xuất hiện nhiều lần, nhưng có giá trị khác nhau.

Thẻ scent có thể áp dụng được là thẻ con của thẻ <wsdl-urc:scents> dưới <GrpSheet> trong tệp tạo nhóm, có giá trị thích hợp được đưa ra là nội dung thẻ (xem TCVN 11523 -5 (ISO/IEC 24752-5)). Tuy nhiên, thẻ con của vùng tên “http://openurc.org/ns/res#” được nhập vào vùng tên “http://openurc.org/ns/wsdl-urc”. Thẻ con của vùng tên khác giữ vùng tên gốc của chúng.

CHÚ THÍCH  nhập trong vùng tên "http://openurc.org/ns/wsdl-urc" cần thiết đối với kiểm tra cú pháp tự động với xác định lược đồ XML. Vùng tên "http://openurc.org/ns/res#" được xác định trong thuật ngữ lược đồ RDF và không thích hợp đối với nhập trong tệp XSD thông thường.

Thẻ scent có thể áp dụng bao gồm:

- <wsdl-urc:forDomain>

- <wsdI-urc:forLang>

- Tệp tạo nhóm khác từ DCMI

7.5.8.5  Thẻ <wsdl-urc:retrieveFrom>

Thẻ <wsdl-urc:grpSheet> phải có thẻ con <wsdl-urc:retrieveFrom>.

Thẻ <wsdl-urc:retrieveFrom> xác định URI (như đã xác định trong IETF RFC 3986), được đưa ra là nội dung thẻ, có thể được sử dụng để tìm kiếm bản sao của tệp tài nguyên tham chiếu mà theo đó được thực hiện sẵn đối với một thực thể trong môi trường mạng cục bộ.

CHÚ THÍCH  tệp tạo nhóm tham chiếu có thể được lưu giữ trong mạng cục bộ, hoặc trên internet. Tuy nhiên, nếu được lưu giữ trên internet, nó phải được công khai qua URI xác định. URI có thể liên quan, trong trường hợp này nó được dựa trên URI của tài liệu WSDL bao hàm.

7.5.9  Thẻ <wsdl-urc:uiid>

7.5.9.1  Khái quát

Bất kỳ số thẻ <wsdl-urc:uiid> nào có thể xuất hiện như thẻ con của thẻ <documentation> dưới thẻ gốc (<definitions> trong WSDL1, <description> trong WSDL2), mỗi thẻ đưa ra một tham chiếu đến mô tả thực hiện giao diện người sử dụng (UIID) do nhà sản xuất đích cung cấp và có sẵn trong mạng cục bộ.

CHÚ THÍCH 1  UIID là thực thể của vùng rộng các định dạng tệp, một số thực thể có thể riêng biệt.

UIID được tham chiếu theo phương thức này có thể áp dụng một hoặc nhiều socket đích

VÍ DỤ: đoạn mã này tham chiếu UIID thuộc kiểu MIME “text/html”.

CHÚ THÍCH 2  thẻ <wsdl-urc:uiid> đưa ra khả năng nhà sản xuất đích cung cấp UIID "default". Các UIID khác - có thể phù hợp hơn với ngữ cảnh sử dụng cụ thể - có thể có sẵn trên máy tài nguyên chủ (xem 7.5.11) do nhà sản xuất đích hoặc bên thứ ba cung cấp.

7.5.9.2  Thuộc tính 'about'

Thẻ <wsdl-urc:uiid> (xem 7.5.10.1) phải có thuộc tính ‘about’ của vùng tên ‘wsdl-urc’, xác định định danh rõ ràng của UIID tham chiếu. Đây phải là định danh thống nhất toàn cục dưới dạng định danh tài nguyên đồng nhất (URI), như đã xác định trong IETF RFC 3986, không có định danh mảnh nối thêm.

CHÚ THÍCH 1  thuộc tính ‘about’ tương ứng với định danh thống nhất toàn cục, như được sử dụng theo UIID

CHÚ THÍCH 2  URI do thuộc tính ‘about’ cung cấp có thể hoặc có thể không giải quyết được. Trong bất kỳ trường hợp nào, sử dụng URI do <wsdl-urc:retrieveFrom> cung cấp (xem 7.5.10.6) để tìm kiếm UIID.

CHÚ THÍCH 3  định danh là giá trị của thuộc tính ‘about’ phù hợp với định danh siêu dữ liệu Dublin Core, http://purl.org/dc/elements/1.1/identifier.

7.5.9.3  Thẻ <dcterms:conformsTo>

Thẻ <wsdl-urc:uiid> (xem 7.5.10.1) có thể có một hoặc nhiều thẻ con <dcterms:conformsTo>, mỗi thẻ xác định một tham chiếu đến một tiêu chuẩn được thiết lập mà theo đó UIID phù hợp. Giá trị của mỗi thẻ <dcterms.conformsTo> phải là URI (như đã xác định trong IETF RFC 3986), và phải được cung cấp như nội dung thẻ.

CHÚ THÍCH 1  giá trị của thẻ <dcterms:conformsTo> có thể được sử dụng khi thử gốc đối với sự phù hợp với UIID.

7.5.9.4  Thẻ <wsdl-urc:forLang>

Thẻ <wsdl-urc:uiid> (xem 7.5.10,1) có thể có bất kỳ số thẻ con <wsdl-urc:forLang>

Thẻ <wsdl-urc:forLang> xác định (như nội dung thẻ) mà ngữ cảnh ngôn ngữ UIID có thể được áp dụng. Ngữ cảnh ngôn ngữ phải là ba mã hóa chữ đối với thẻ <xml:lang> của XML 1.0. Thẻ trống <wsdl-urc:forLang> biểu thị rằng UIID không phải là ngôn ngữ xác định.

VÍ DỤ <wsdl-urc:forLang>en</wsdl-urc:forLang>

CHÚ THÍCH  UIID điển hình sẽ được xác định trong phương thức ngôn ngữ độc lập. Đối với các UIID này, thẻ trống <wsdl-urc:forLang> được khuyến nghị.

7.5.9.5  Các đặc tính UIID khác từ DCMI

Thẻ <wsdl-urc:uiid> (xem 7.5.10.1) có thể có bất kỳ số thẻ và bộ lọc thẻ từ thuật ngữ siêu dữ liệu Dublin Core (xem ISO 15836) là thẻ con, nếu thích hợp. Mỗi một thẻ có thể xuất hiện nhiều lần.

Cụ thể, thuật ngữ siêu dữ liệu Dublin Core có thể xuất hiện:

- <dc:creator>

- <dc:publisher>

- <dc:contributor>

- <dc:rights>

- <dc:title> (with optional ‘xml:lang’ attribute)

- <dc:format>

- <dcterms:audience>

7.5.9.6  Thẻ <wsdl-urc:retrieveFrom>

Thẻ <wsdl-urc:uiid> (xem 7.5.10.1) phải có thẻ con <wsdl-urc:retrieveFrom>.

Thẻ <wsdl-urc:retrieveFrom> xác định URI (như đã xác định trong IETF RFC 3986), được đưa ra là nội dung thẻ, có thể được sử dụng để tìm kiếm bản sao của UIID tham chiếu trong môi trường mạng cục bộ.

URI có thể liên quan, trong trường hợp này nó được dựa trên URI của tài liệu WSDL bao hàm.

7.5.10  Thẻ <wsdl-urc:resSvc>

7.5.10.1  Khái quát

Bất kỳ số thẻ <wsdl-urc:resSvc> nào đều có thể xuất hiện như thẻ con của <documentation> dưới thẻ gốc (<definitions> trong WSDL1, <description> trong WSDL2), mỗi thẻ đưa ra tham chiếu đối với dịch vụ tài nguyên có thể được truy vấn đối với bất kỳ kiểu tài nguyên, bao gồm:

- Tài nguyên nguyên tử như nhãn, cú pháp trợ giúp, từ khóa nhận dạng và khóa tiếp cận (như đã xác định theo TCVN 11523-5 (ISO/IEC 24752-5)

- Tài nguyên tạo nhóm (như đã xác định theo TCVN 11523-5 (ISO/IEC 24752-5), và

- UIID (dạng thức không được xác định theo tiêu chuẩn này).

Dịch vụ tài nguyên có thể cung cấp tài nguyên từ nhà sản xuất đích và bất kỳ bên thứ ba nào, so với tài nguyên (mặc định) do đích cung cấp trong môi trường mạng cục bộ.

VÍ DỤ  Phần mô tả dưới đây là ví dụ về mô tả dịch vụ tài nguyên. Dịch vụ tài nguyên phù hợp với đặc tả của giao diện OpenURC’s Resource Server HTTP 1.0 ngày 29-4-2009 (như đã xác định tại http://openurc.org/TR/res-serv-http1.0-20090429/), và mô tả giao diện của nó tại http://res.openurc.org.

7.5.10.2  Thuộc tính ‘about’

Thẻ <wsdI-urc:resSvc> (xem 7.5.11.1) phải có thuộc tính ‘about’ của vùng tên ‘wsdl-urc’, xác định định danh rõ ràng của dịch vụ tài nguyên. Đây phải là định danh thống nhất toàn cục dưới dạng định danh tài nguyên đồng nhất (URI), như đã xác định trong IETF RFC 3986.

URI này phải giải quyết được tổng thể và phải đưa ra tệp mô tả đối với dịch vụ tài nguyên.

Dạng mẫu tệp mô tả ngoài đối với dịch vụ tài nguyên không thuộc phạm vi của tiêu chuẩn này. Nếu hiện diện, dạng mẫu mô tả giao diện như đã xác định theo các tiêu chuẩn khác, có thể được áp dụng. Nếu được tiêu chuẩn hóa, thẻ có chứa <dcterms:conformsTo> và/hoặc gia hạn tệp của tệp mô tả dịch vụ tài nguyên có thể cảm sinh dạng mẫu.

CHÚ THÍCH  định danh là giá trị của thuộc tính ‘about’ phù hợp với định danh siêu dữ liệu Dublin Core, http://purl.org/dc/elements/1.1/identifier.

7.5.10.3  Thẻ <dcterms:conformsTo>

Thẻ <wsdl-urc:resSvc> (xem 7.5.11.1) có thể có thẻ con <dcterms:conformsTo>, xác định tham chiếu (như URI, như đã xác định trong IETF RFC 3986) với một tiêu chuẩn thiết lập mà theo đó dịch vụ tài nguyên phù hợp. URI phải được xác định là nội dung thẻ.

CHÚ THÍCH  <dcterms:conformsTo> phù hợp với bộ lọc thẻ siêu dữ liệu Dublin Core conformsTo, http://purl.org/dc/terms/conformsTo, là lọc của thẻ gốc Dublin http://purl.org/dc/elements/1.1/relation.

7.5.10.4  Các đặc tính máy chủ tài nguyên chủ khác từ DCMI

Thẻ <wsdl-urc:resSvc> (xem 7.5.11.1) có thể có bất kỳ số thẻ và bộ lọc thẻ nào từ thuật ngữ siêu dữ liệu Dublin Core (xem TCVN 7980 (ISO 15836)) là thẻ con, nếu phù hợp, để mô tả máy chủ tài nguyên và nội dung của nó. Mỗi một thẻ có thể xuất hiện nhiều lần.

Cụ thể, thuật ngữ siêu dữ liệu Dublin Core sau có thể xuất hiện:

- <dc:publisher>

- <dc:rights>

- <dc:title> (with optional ‘xml:lang’ attribute)

- <dcterms:audience>

7.5.11  Phân khu “target”

7.5.11.1  Khái quát

Dịch vụ web phải cung cấp phân khu chuyên dụng “_target” đối với việc cung cấp thẻ xác định thực thể đích, và bộ định vị, nếu hiện diện.

Tất cả bộ định vị của đích phải xuất hiện như hoạt động trong phân khu “_target” của dịch vụ web.

Trong WSDL1, phân khu “_target” phải xuất hiện như thẻ <portType> là thẻ con của thẻ gốc <definitions>. Phải có thuộc tính ‘name’ có giá trị “_target”.

VÍ DỤ 1  phân khu _target trong WSDL1, có hoạt động bắt buộc “getTargetInstanceld” và hoạt động định vị “beep”. Elip (“…”) biểu thị sự bỏ qua.

Trong WSDL2, phân khu “target” phải xuất hiện như thẻ <interface> là thẻ con của thẻ gốc <description>. Phải có thuộc tính ‘name’ có giá trị “target”.

VÍ DỤ 2  phân khu _target trong WSDL2, có hoạt động bắt buộc “getTargetInstanceld” và hoạt động định vị “beep”. Các hình Elip (“...”) biểu thị sự bỏ qua.

7.5.11.2  Hoạt động 'getTargetInstanceld'

Hoạt động ‘getTargetInstanceld’ phải có các mục đầu vào và đầu ra sau:

- Không có mục đầu vào.

- Có chính xác một mục đầu ra của thẻ <wsdl-urc:targetInstanceld>, phản ánh định danh thực thể của đích (xem TCVN 11523-1 (ISO/IEC 24752-1), phần “Target instance identifier”).

CHÚ THÍCH  xem 7.5.11.1 đối với mã hóa mẫu WSDL1 và WSDL2 đối với hoạt động ‘getTargetInstanceld’.

7.5.11.3  Chức năng định vị

7.5.11.3.1  Khái quát

Chức năng định vị phải xuất hiện như hoạt động (với bất kỳ tên gì) trong phân khu “_target”

Hoạt động định vị phải được người sử dụng gọi mà không đăng ý hoặc đăng nhập trước.

Hoạt động định vị phải không có mục đầu vào và đầu ra

CHÚ THÍCH  trong WSDL1, có nghĩa là hoạt động định vị phải có thông điệp <input> trống, và không có thẻ <output>. Trong WSDL2, có nghĩa là hoạt động định vị phải có thông điệp <input> và <output>, mỗi thông điệp có thẻ ="#none".

7.5.11.3.2  Kiểu định vị

Hoạt động định vị phải có thẻ <wsdl-urc:locatorType> là thẻ con của thẻ <documentation>. Nội dung của nó phải là giá trị bất kỳ của các giá trị sau.

“audio”: Định vị nghe được, nghĩa là đích phát ra một tín hiệu nghe được (ví dụ như tiếng bíp hoặc tiếng chuông) khi người sử dụng gọi.

“visual”: định vị nhìn được, nghĩa là đích phát ra một tín hiệu nhìn được (ví dụ như ánh sáng lóe lên) khi người sử dụng gọi.

“other”: khác có ý nghĩa đối với việc định vị một đích, ví dụ xung IR.

7.6  Mô tả socket ngầm định

7.6.1  Khái quát

Đích phải trình bày một hoặc nhiều mô tả socket ấn, được nhúng trong tài liệu WSDL, như được mô tả trong các tiểu mục sau. Tham chiếu TCVN 11523-2 (ISO/IEC 24752-2) về ngữ nghĩa học của mục thông tin về mô tả socket.

Mô tả socket ngầm định phải được xác định là phân khu dịch vụ web. Trong các phần sau, phân khu dịch vụ web như vậy cũng được tham chiếu là “socket”.

Trong tài liệu WSDL1, socket được mô tả bằng thẻ <portType> (dưới thẻ gốc <definitions>), thuộc tính ‘name’ của nó và thẻ con (<operation>) của nó.

Trong tài liệu WSDL2, socket được mô tả bằng thẻ <interface> (dưới thẻ gốc <description>), thuộc tính ‘name’ của nó, và thẻ con (<operation>) của nó.

VÍ DỤ 1  mô tả socket ngầm định trong WSDL1.

VÍ DỤ 2  mô tả socket ngầm định trong WSDL2.

Phân khu dịch vụ web biểu diễn cho socket không bao gồm các hoạt động khác ngoài các hoạt động được xác định trong mục này.

7.6.2  Socket yêu cầu phiên với socket không yêu cầu phiên

Socket biểu diễn bởi phân khu dịch vụ web có thể là yêu cầu phiên hoặc không yêu cầu phiên

Nếu phân khu dịch vụ web biểu diễn socket yêu cầu phiên:

- Nó phải xác định lỗi phiên (xem 7.6.14):

- Nó phải bao gồm các hoạt động sau: open-session-request (xem 7.6.15), close-session-request (xem 7.6.16), suspend-session-request (xem 7.6.17), resume-session-request (xem 7.6.18), get-session-status (xem 7.6.19):

- Tất cả các hoạt động của socket, ngoại trừ hoạt động open-session-request. Phải có “sessionId” là mục đầu vào đầu tiên, và

- Tất cả các hoạt động của socket, ngoại trừ hoạt động 'open-session-request’ và 'get-session-status', phải tham chiếu lỗi phiên.

Nếu phân khu dịch vụ web biểu diễn socket không yêu cầu phiên:

- Socket không xác định lỗi phiên (xem 7.6.14):

- Socket không chứa các hoạt động sau: open-session-request (xem 7.6.15), close-session-request (xem 7.6.16), suspend-session-request (xem 7.6.17), resume-session-request (xem 7.6.18), get-session-status (xem 7.6.19);

- Các hoạt động của socket không có “sessionId” là mục đầu vào; và

- Các hoạt động của socket không tham chiếu lỗi phiên.

Trong các phần sau, phân khu dịch vụ web biểu diễn socket yêu cầu phiên được tham chiếu là “session-full socket”, và phân khu dịch vụ web biểu diễn socket không yêu cầu phiên là “session-less socket”.

CHÚ THÍCH 1  hầu hết các ví dụ trong tiêu chuẩn này giả định socket không yêu cầu phiên (ví dụ socket bộ ổn nhiệt) đơn giản.

CHÚ THÍCH 2  khách dịch vụ web có thể sử dụng sự xuất hiện của hoạt động liên quan đến phiên -session-request, close-session-request, và get-session-status làm chỉ số đối với socket yêu cầu phiên. Chú ý rằng các hoạt động suspend-session-request và resume-session-request là tùy chọn đối với socket yêu cầu phiên.

7.6.3  Thuộc tính 'name'

Thuộc tính ‘name’ của phân khu dịch vụ web được sử dụng để xây dựng tên của socket ngầm định (URL) như sau (trong ký hiệu BNF mở rộng);

Tên socket ngầm định = implicit target name ,name attribute value;

Trong đó implicit target name là định danh thống nhất toàn cục của đích (xem 7,5.2), và name attribute value là giá trị của thuộc tính ‘name’ trên phân khu dịch vụ web (<portType> trong WSDL1, và <interface> trong WSDL2).

VÍ DỤ  tài liệu WSDL1 xác định "http://openurc.org/res/devices/hasic-thermostat/" là tên đích ngầm định, và "socketl" là giá trị của thuộc tính 'name’ của thẻ <portType> như sau (bỏ qua được biểu thị bằng hình elip):

Do vậy, tên socket ẩn là: http://openurc.org/TPL/basic-thermostat-1.0/socket1.

7.6.4  Thẻ <dcterms:conformsTo>

Thẻ <dcterms:conformsTo> phải xuất hiện như thẻ con của thẻ <documentation> của phân khu (<portType> trong WSDL1, <interface> trong WSDL2). Nó phải có URI là nội dung thẻ, xác định tiêu chuẩn được thiết lập mà theo đó mô tả socket ngầm định phù hợp. Giá trị http://openurc.org/ns/wsdl-urc/isoiec24752-6-2013 biểu thị rằng mô tả socket phù hợp với tiêu chuẩn này .

CHÚ THÍCH  mô tả dịch vụ web phù hợp có thể bao gồm cả phân khu phù hợp và không phù hợp. Khách cần kiểm tra tính phù hợp của phân khu khi phân tích tài liệu WSDL1 hoặc WSDL2

7.6.5  Thẻ <wsdl-urc:socketType>

Socket có thể có thẻ <wsdl-urc:socketType> là thẻ con của thẻ <documentation> của phân khu (<portType> trong WSDL1, <interface> trong WSDL2). Nếu hiện diện, giá trị của nó phải là một trong các giá trị sau:

"location-dependent". Socket phụ thuộc vị trí có vị trí xác định, và yêu cầu người sử dụng gần với đích và socket.

"location-informative". Socket thông tin vị trí có vị trí xác định, nhưng có thể được điều khiển từ bất kỳ nơi nào.

"location-free". Socket Location-free không có vị trí xác định, nghĩa là chúng tồn tại trong khoảng ảo. Socket mà kiểu của chúng không được xác định là "location-dependent" (giá trị mặc định).

VÍ DỤ 1  dịch vụ ATM là phụ thuộc vị trí, hệ thống an ninh nội bộ là thông tin vị trí, và dịch vụ thông tin tỷ giá dựa trên internet là không có vị trí xác định.

VÍ DỤ 2  dịch vụ ATM phụ thuộc vị trí (WSDL1 hoặc WSDL2).

7.6.6  Thẻ <wsdl-urc:hidden>

Socket có thể có thẻ <wsdl-urc:hidden> là thẻ con của thẻ <documentation> của phân khu (<portType> trong WSDL1, <interface> trong WSDL2). Nếu hiện diện, nó phải có giá trị Boolean (nghĩa là hoặc “true” hoặc “false”). Giá trị mặc định sẽ là “false”.

Điều này tương ứng với thuộc tính ‘hidden’ trên thẻ <td:socket> trong mô tả đích (xem TCV11523-4 (ISO/IEC 24752-4), điều 6.9.5).

VÍ DỤ  Trong ví dụ này, socket được xác định là bị ẩn (WSDL1 or WSDL2).

7.6.7  Thẻ <wsdl-urc:maxSessions>

Socket yêu cầu phiên có thể có thẻ <wsdl-urc:maxSessions> là thẻ con của thẻ <documentation> của phân khu (<portType> trong WSDL1, <interface> trong WSDL2). Nếu hiện diện, nó phải có số nguyên bằng hoặc lớn hơn “1” là nội dung.

Điều này tương ứng với thuộc tính ‘maxSessions’ trên thẻ <td:socket> trong mô tả đích (xem TCVN 11523-4 (ISO/IEC 24752-4), điều 6.9.6).

Không có giá trị mặc định đối với thẻ <wsdl-urc:maxSessions>. Nếu không hiện diện, thì sẽ không có thông tin về số phiên tối đa.

VÍ DỤ  trong ví dụ này, socket chỉ có thể duy trì một phiên tại một thời điểm (WSDL1 hoặc WSDL2).

7.6.8  Thẻ <wsdl-urc:sharedSessions>

Socket yêu cầu phiên có thể có thẻ <wsdl-urc:sharedSessions> là thẻ con của thẻ <documentation> của phân khu (<portType> trong WSDL1, <interface> trong WSDL2). Nếu hiện diện, nó phải có giá trị Boolean là nội dung, nghĩa là “true” hoặc “false”

Điều này tương ứng với thuộc tính ‘sharedSessions’ trên thẻ <td:socket> trong mô tả đích (xem TCVN 11523-4 (ISO/IEC 24752-4), điều 6.9.7).

Không có giá trị mặc định đối với thẻ <wsdl-urc:sharedSessions>. Nếu không hiện diện, không có thông tin về phân chia phiên.

VÍ DỤ  trong ví dụ này, socket phân chia phiên song song (WSDL1 hoặc WSDL2).

7.6.9  Thẻ <wsdl-urc:requestable>

Socket có thể có thẻ <wsdl-urc:requestable> là thẻ con của thẻ <documentation> của phân khu (<portType> trong WSDL1, <interface> trong WSDL2). Nếu hiện diện, nó phải có giá trị Boolean là nội dung, nghĩa là “true” hoặc “false”. Giá trị mặc định là “true”.

Điều này tương ứng với thuộc tính ‘requestable’ trên thẻ <td:socket> trong mô tả đích (xem TCVN 11523-4 (ISO/IEC 24752-4), điều 6.9.8).

VÍ DỤ  trong ví dụ này, socket có thể được yêu cầu được mở trực tiếp bằng URC (WSDL1 hoặc WSDL2).

7.6.10  Thẻ <wsdl-urc:sufficient>

Socket có thể có thẻ <wsdl-urc:sufficient> là thẻ con của thẻ <documentation> của phân khu (<portType> trong WSDL1, <interface> trong WSDL2). Nếu hiện diện, nó phải có giá trị Boolean là nội dung, nghĩa là “true” hoặc “false”.

Điều này tương ứng với thuộc tính 'sufficient' trên thẻ <uis:uiSocket> trong mô tả socket (xem TCVN 11523-2 (ISO/IEC 24752-2)).

VÍ DỤ  socket được đánh dấu là đủ (WSDL1 và WSDL2).

7.6.11  Thẻ <wsdl-urc:complete>

Socket có thể có thẻ <wsdl-urc:complete> là thẻ con của thẻ <documentation> của phân khu (<portType> trong WSDL1, <interface> trong WSDL2). Nếu hiện diện, nó phải có giá trị Boolean là nội dung, nghĩa là “true” hoặc “false”

Điều này tương ứng với thuộc tính ‘complete’ trên thẻ <uis:uiSocket> trong mô tả socket (xem TCVN 11523-2 (ISO/IEC 24752-2)).

VÍ DỤ  socket được đánh dấu là hoàn thiện (WSDL1 và WSDL2).

7.6.12  Các đặc tính socket từ DCMI

Mọi thẻ và bộ lọc thẻ nào từ 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ả đích, nếu phù hợp (như đã xác định trong ISO 15836 (TCVN 7980)). Mỗi thẻ có thể xuất hiện nhiều lần là thẻ con của thẻ <documentation> của phân khu (<portType> trong WSDL1, <interface> trong WSDL2).

Cụ thể, thuật ngữ DCMI sau có thể được áp dụng đối với socket (được trình bày qua phân khu dịch vụ web):

<dc:identifier> xác định mã hóa sản phẩm (hoặc mã hóa thực thể) của socket

<dc:creator> xác định nhà sản xuất socket

<dc:publisher> xác định nhà cung cấp socket

<dc:contributor> xác định nhà đồng sản xuất socket

Thuộc tính ‘xsi:type’ được sử dụng để xác định lược đồ mã hóa, nếu phù hợp.

VÍ DỤ  trong ví dụ này, tác giả của socket được xác định là “Gottfried Zimmermann" (WSDL1 và WSDL2).

7.6.13  Đường dẫn tập

Socket giao diện người sử dụng bao gồm các thẻ (biến, lệnh và thông báo) có thể được đặt vào trong các tập trong cấu trúc phân cấp. Mỗi thẻ có một “đường dẫn tập”, đó là danh sách của các định danh tập phản ánh đường đi từ gốc đến thẻ.

Trong các tiểu mục sau, đường dẫn tập của thẻ phải bao gồm danh sách các định danh chia tách điểm của tất cả các tập tạo thành đường dẫn từ gốc tới thẻ, có điểm quét.

Điều này có thể được biểu thị trong ký pháp BNF mở rộng (xem ISO/IEC 14977) như sau: đường dẫn tập = {set identifier, “.” };

Trong đó định danh tập là giá trị của thuộc tính ‘id’ của <set>.

VÍ DỤ 1  biến có id= “power” được bao gồm trong tập “powerControls” dưới <uiSocket>, có đường dẫn tập sau: powerControls.

VÍ DỤ 2  biến có id= “power” được bao gồm trong tập “powerControls” mà được bao gồm trong tập “tvControls” dưới <uiSocket>, có đường dẫn tập sau: tvControls.powerControls.

Thẻ ngay dưới socket (nghĩa là không được bao gồm trong bất kỳ tập nào) phải có đường dẫn tập trống (pathOfSets là một chuỗi trống).

7.6.14  Lỗi phiên

Socket yêu cầu phiên phải xác định lỗi phiên, được sử dụng bởi các hoạt động của socket như được chỉ báo đối với mỗi hoạt động.

Lỗi phiên phải có hoặc một trong các giá trị sau, mỗi giá trị chỉ báo một điều kiện lỗi liên quan đến phiên cụ thể:

“invalid”: thẻ xác định phiên không hợp lệ;

“expired”: phiên hết hiệu lực (khác đã đóng phiên);

“aborted”: đích đã hủy bỏ phiên;

“forwarded”: Đích đã đóng phiên và muốn khác mở phiên bằng socket khác. Khách gọi hoạt động get-session-status để biết về socket chuyển tiếp.

Trong WSDL1, phiên không thể được xác định trên mức <portType>; phiên phải xuất hiện trên hoạt động phù hợp như thẻ <fault> có name=”sessionFault”.

CHÚ THÍCH 1  xem phụ lục A đối với danh sách đầy đủ tài liệu WSDL1 phù hợp, bao gồm thẻ <fault> trên các hoạt động, và thẻ liên quan, kiểu và xác định thông điệp

Trong WSDL2, giao diện quản lý phiên phải xác định mức giao diện <fault> có name=”sessionFault”, được tham chiếu bằng thẻ <outfault> trên hoạt động thích hợp.

VÍ DỤ  trong WSDL2, lỗi phiên được xác định trong thẻ <interface> như sau:

CHÚ THÍCH 2  xem phụ lục A đối với danh sách đầy đủ tài liệu WSDL2 phù hợp, bao gồm <fault> trên <interface>, thẻ <outfault> trên các hoạt động, và thẻ liên quan và xác định kiểu.

7.6.15  Hoạt động open-session-request

Hoạt động open-session-request phải xuất hiện trong socket yêu cầu phiên. Thuộc tính ‘name’ của nó phải có giá trị “openSessionRequest”. Nó phải có mục đầu vào và đầu ra sau:

- Mục đầu vào có tên là là “authorizationCode” thuộc kiểu xs:string, xác định mã xác nhận được yêu cầu để mở phiên. Mã xác nhận có thể trống.

- Mục đầu ra có tên là là “sessionId” của kiểu xs:NMTOKEN, xác định định danh phiên, nếu hoạt động thành công. Nếu phiên mở được yêu cầu không thành công, “sessionId” sẽ trống.

- Mục đầu ra có tên là “forwardSocketName” của kiểu xs:anyURI. forwardSocketName phải là trống nếu “sessionId” không phải là trống; mặt khác nó có thể cung cấp đích tiếp theo (định vị tệp WSDL) và socket tiếp theo (phân khu) theo hình thức sau: “[URL của tệp WSDL file đích]#wsdl. interface([tên phân khu])”, trong đó

- “[URL of target WSDL file]” là URL của tệp WSDL biểu diễn đích dịch vụ web phù hợp với tiêu chuẩn này ;

- "[partition name]” là tên của phân khu dịch vụ web biểu diễn socket mà khách được chuyển tiếp đến;

CHÚ THÍCH  mặc dù WSDL1 sử dụng <portType> thay cho <interface> để biểu diễn socket, cú pháp “wsdl.interface([partition name])” được sử dụng để tham chiếm kiểu cổng.

- Mục đầu ra có tên là “forwardSocketAuthorizationCode” của kiểu xs: string.forwardSocketAuthorizationCode có thể có giá trị không trống chỉ khi mục đầu ra forwardSocketName là không trống; mặt khác nó sẽ là trống. Nếu được cung cấp, nó phải xác định mã được phép được yêu cầu để mở phiên bằng socket được xác định bởi forwardSocketName.

VÍ DỤ 1  trong WSDL1, hoạt động open-session-request được xác định như sau:

CHÚ THÍCH 1  xem phụ lục A đối với danh sách hoàn thiện tài liệu WSDL1 phù hợp và hoạt động open-session-request của nó, bao gồm thẻ thích hợp, kiểu và xác định thông điệp.

VÍ DỤ 2  trong WSDL2, hoạt động open-session-request được xác định như sau:

CHÚ THÍCH 2  xem phụ lục A đối với danh sách hoàn thiện tài liệu WSDL2 phù hợp và hoạt động resume-session-request của nó, bao gồm thẻ phù hợp, và xác định kiểu.

7.6.16  Hoạt động close-session-request

Hoạt động close-session-request phải xuất hiện trong socket yêu cầu phiên. Thuộc tính ‘name’ của nó phải có giá trị attribute “closeSessionRequest”. Nó phải có mục đầu vào và đầu ra:

- Mục đầu vào có tên là “sessionId” của kiểu xs:NMTOKEN, xác định phiên được yêu cầu bí mật.

- Mục đầu ra có tên là “requestResult” của kiểu xs:boolean. Mục này có giá trị “true” nếu phiên gần với kết quả yêu cầu, ngược lại là “false”.

- Lỗi phiên (xem 7.6.14).

VÍ DỤ 1  Trong WSDL1, hoạt động close-session-request được xác định như sau:

CHÚ THÍCH 1  xem phụ lục A đối với danh sách hoàn thiện tài liệu WSDL1 phù hợp và hoạt động yêu cầu phiên đóng của nó, bao gồm thẻ thích hợp, kiểu và xác định thông điệp.

VÍ DỤ 2  trong WSDL2, hoạt động close-session-request được xác định như sau:

CHÚ THÍCH 2  xem phụ lục A đối với danh sách hoàn thiện tài liệu WSDL2 phù hợp và hoạt động close-session-request của nó, bao gồm thẻ phù hợp và xác định kiểu.

7.6.17  Hoạt động suspend-session-request

Hoạt động suspend-session-request có thể xuất hiện trong socket yêu cầu phiên. Thuộc tính ‘name’ của nó phải có giá trị “suspendSessionRequest”. Hoạt động này phải có mục đầu vào và đầu ra sau:

- Mục đầu vào có tên là “sessionId” của kiểu xs:NMTOKEN, xác định phiên được yêu cầu treo.

- Mục đầu vào có tên là “suggestedTimeout” của kiểu xs:duration, xác định thời gian chờ do khách gợi ý.

- Mục đầu ra có tên là “tentativeTimeout” của kiểu xs:duration, xác định thời gian chờ dự kiến do dịch vụ mạng đưa ra. tentativeTimeout có thể khác với suggestedTimeout. Nó phải trống nếu yêu cầu treo bị từ chối.

- Lỗi phiên (xem 7.6.14).

VÍ DỤ 1  trong WSDL1, hoạt động thẻ suspend-session-request được xác định như sau:

CHÚ THÍCH 1  xem phụ lục đối với danh sách hoàn thiện tài liệu WSDL1 phù hợp và hoạt động suspend-session-request của nó, bao gồm thẻ phù hợp, kiểu và xác định thông điệp.

VÍ DỤ 2  trong WSDL2, hoạt động suspend-session-request được xác định như sau:

CHÚ THÍCH 2  xem phụ lục A đối với danh sách hoàn thiện tài liệu WSDL2 phù hợp và hoạt động suspend-session-request của nó, bao gồm thẻ phù hợp, xác định kiểu.

7.6.18  Hoạt động resume-session-request

Hoạt động resume-session-request có thể xuất hiện trong socket yêu cầu phiên. Thuộc tính ‘name’ của nó phải có giá trị “resumeSessionRequest”. Nó phải có mục đầu vào và đầu ra sau:

- Mục đầu vào có tên là “sessionId” của kiểu xs:NMTOKEN, xác định phiên được yêu cầu bắt đầu lại.

- Mục đầu ra có tên là “requestResult” của kiểu xs:boolean, nó phải có giá trị “true” nếu phiên được bắt đầu lại, ngược lại là “false”.

- Lỗi phiên (xem 7.6.14).

VÍ DỤ 1  trong WSDL1, hoạt động resume-session-request được xác định như sau:

CHÚ THÍCH 1  xem phụ lục A đối với danh sách hoàn thiện tài liệu WSDL1 phù hợp và hoạt động resume-session-request của nó, bao gồm thẻ phù hợp, kiểu và xác định thông điệp.

VÍ DỤ 2  trong WSDL2, hoạt động resume-session-request được xác định như sau:

CHÚ THÍCH 2  xem phụ lục A đối với danh sách hoàn thiện tài liệu WSDL2 phù hợp và hoạt động resume-session-request của nó, bao gồm thẻ phù hợp và xác định kiểu.

7.6.19  Hoạt động get-session-status

Hoạt động get-session-status phải xuất hiện trong socket yêu cầu phiên. Thuộc tính ‘name’ của nó phải có giá trị “getSessionStatus”. Hoạt động này phải có mục đầu vào và đầu ra sau:

- Mục đầu vào có tên là “sessionId” của kiểu xs:NMTOKEN.

- Mục đầu ra có tên là “sessionStatus” của kiểu liệt kê, có các giá trị cho phép sau:

- “invalid”: định danh không hợp lệ;

-“active”: phiên hiện đang hoạt động;

- “forwardRequested”: phiên vẫn hoạt động nhưng đích muốn khách đóng nó và mở phiên với forwardSocketName, ngày khi có thể;

-“expired”: phiên đã hết hạn (do khách đóng);

-“aborted”: phiên đã bị hủy bởi đích;

- “forwarded”: đích đã đóng phiên và muốn khách mở phiên với forwardSocketName.

- Mục đầu ra có tên là “forwardSocketName” của kiểu xs:anyURI. forwardSocketName phải có giá trị không trống chỉ khi sessionStatus có giá trị “forwardRequested” hoặc “forwarded”; mặt khác nó phải là trống. Nếu được cung cấp, nó phải xác định đích chuyển tiếp (định vị tệp WSDL) và socket chuyển tiếp (phân khu) theo dạng thức sau: “[URL of target WSDL file]#wsdl.interface([tên phân khu])” (xem 7.6.15. mục đầu ra forwardSocketName của hoạt động 'open-session-request', để biết rõ thêm).

Mục đầu ra có tên là “forwardSocketAuthorizationCode” của kiểu xs:string.forwardSocketAuthorizationCode có thể có giá trị không trống chỉ khi mục đầu ra forwardSocketName không trống; mặt khác nó phải là trống. Nếu được cung cấp, nó phải xác định mã được phép được yêu cầu để mở phiên với socket được xác định bằng forwardSocketName.

VÍ DỤ 1  giá trị sau đối với mục đầu ra “forwardSocketName” biểu diễn phân khu (socket) “control” trên đích dịch vụ web có tệp WSDL của nó được định vị tại “http://example.com/wsdl”: http://example.com/wsdl#wsdl.interface(control)

VÍ DỤ 2  trong WSDL1, hoạt động get-session-status được xác định như sau:

CHÚ THÍCH 1  xem phụ lục A đối với danh sách hoàn thiện tài liệu WSDL1 phù hợp và hoạt động get-session-status của nó, bao gồm thẻ phù hợp, kiểu và xác định thông điệp.

VÍ DỤ 3  trong WSDL2, hoạt động the get-session-status được xác định như sau:

CHÚ THÍCH 2  xem phụ lục A đối với danh sách hoàn thiện tài liệu WSDL2 phù hợp và hoạt động get-session-status của nó, bao gồm thẻ phù hợp, và xác định kiểu.

7.6.20  Hoạt động get-updates

Socket phải cung cấp hoạt động get-updates với tên =”getUpdates” đối với khách để kiểm soát theo định kỳ nhằm tìm ra rằng liệu trạng thái phiên có thay đổi hay không (chỉ đối với socket yêu cầu phiên), và/hoặc các cập nhật của giá trị biến, trạng thái lệnh, trạng thái thông báo và/hoặc tài nguyên nguyên tử động (đối với các biến, thông báo và chỉ số) xảy ra. Khách có thể gọi các get này, “getstat”, kiểm tra, hoạt động get-index và/hoặc get-resources để tìm kiếm giá trị cập nhật.

Dịch vụ web phải sử dụng kỹ thuật vòng dài HTTP đối với hoạt động get-updates, nghĩa là nó phải quay lại hoạt động nếu hiện diện cập nhật hoặc nếu đạt đến thời gian chờ. Thời gian chờ 30 giây được khuyến nghị, nghĩa là máy chủ gửi một hồi đáp trống đến khách nếu không có cập nhật trong 30 giây sau yêu cầu của khách.

CHÚ THÍCH  thời gian chờ 30 giây dựa trên IETF RFC 6202, xác định việc thực hiện tốt nhất đối với việc thực hiện kỹ thuật vòng dài HTTP trên máy chủ HTTP.

Khách nên gửi liên tục các yêu cầu get-updates đến máy chủ, nghĩa là gửi ngay lập tức yêu cầu get- updates tiếp theo ngay khi nhận được phản hồi của yêu cầu trước.

Hoạt động get-updates phải có mục đầu vào và đầu ra sau:

Đối với socket yêu cầu phiên: mục đầu vào có tên là “sessionId" của kiểu xs:NMTOKEN, xác định phiên mà yêu cầu này thuộc về.

Mục đầu ra có tên là “getOperations” mà kiểu của chúng phải là danh sách khoảng trống tách rời của xs:NCNames. getOperations phải bao gồm danh sách các tên của các hoạt động get và getidx này được khách gọi để tìm kiếm giá trị cập nhật. Đối với socket phiên đầy đủ, nó phải bao gồm tên của hoạt động get- session-status nếu trạng thái phiên thay đổi. Ngay khi get-updates được gọi đối với phiên cụ thể, dịch vụ web phải xóa bỏ danh sách này và trong lần gọi tiếp theo đối với get-updates chỉ phản ánh tình trạng cập nhật mới.

Đối với socket yêu cầu phiên: lỗi phiên (xem 7.6.14).

VÍ DỤ 1  trong WSDL1, hoạt động get-updates đối với socket yêu cầu phiên được xác định như sau:

CHÚ THÍCH 1  xem phụ lục A đối với danh sách hoàn thiện tài liệu WSDL1 phù hợp và hoạt động get-updates của nó, bao gồm thẻ phù hợp, kiểu và xác định thông điệp.

VÍ DỤ 3  trong WSDL2, hoạt động get-updates đối với socket yêu cầu phiên được xác định như sau:

<dc: description xml:lang="en"> hoạt động chung xác định trạng thái phiên được cập nhật, biến số, thông báo và các chỉ số. Khách kiểm tra hoạt động này liên tục để tìm ra vị trí cập nhật xảy ra và máy chủ sử dụng kiểm tra trong thời gian dài có thời gian chờ 30 giây (xem RFC 6202).

Nếu máy chủ quay lại danh sách các hoạt động trống, khách sẽ gọi các hoạt động này để đạt được giá trị cập nhật.</dc:description>

VÍ DỤ 4  trong WSDL2, hoạt động get-updates đối với socket không yêu cầu phiên được xác định như sau:

CHÚ THÍCH 2  xem phụ lục A đối với danh sách hoàn thiện tài liệu WSDL2 phù hợp và hoạt động get-updates của nó, bao gồm thẻ phù hợp, và xác định kiểu.

7.6.21  Biến

7.6.21.1  Khái quát

Đối với mỗi biến trong socket, cặp hoạt động get và set phải được bao gồm và hoạt động get- resources có thể được bao gồm trong phân khu dịch vụ web biểu diễn socket (xem 6.4). Đối với các biến read-only, chỉ hoạt động get được bao gồm và hoạt động get-resources có thể được bao gồm.

Tên đối với hoạt động get phải có tiền tố “get.”, theo sau là đường dẫn tập của biến, tiếp theo định danh biến. Tên đối với hoạt động set phải có tiền tố “set.”, theo sau là đường dẫn tập của biến, tiếp theo định danh biến. Tên của hoạt động get-resources phải có tiền tố “getres.”, theo sau là đường dẫn tập của biến, tiếp theo định danh biến.

Ký hiệu BNF mở rộng:

Tên hoạt động get = “get.”, đường dẫn tập, định danh biến;

Tên hoạt động set = “set.”, đường dẫn tập, định danh biến;

Tên hoạt động get-resource = “getres.”, đường dẫn tập, định danh biến; trong đó định danh biến là giá trị của thuộc tính ‘id’ của <variable>.

VÍ DỤ 1  đối với biến có id= “power” ngay dưới thẻ gốc <uiSocket>, hoạt động get phù hợp có tên là “get.power”, hoạt động set “set.power”, và hoạt động get-resources “getres.power”.

VÍ DỤ 2  đối với biến có id= “power” trong tập có id= “powerControls”, dưới <uiSocket>, hoạt động get phù hợp có tên là “get.powerControls.power”, hoạt động set “set.powerControls.power”, và hoạt động get-resources “getres.powerControls.power”.

VÍ DỤ 3  đối với biến có id= “power” trong tập có id= “powerControls”, trong tập có id= “dvd”, dưới <uiSocket>, hoạt động get phù hợp có tên là “get.dvd.powerControls.power”, hoạt động set “set.dvd. powerControls.power” và hoạt động get-resources “getres.dvd.powerControls.power”.

Tên của hoạt động get, set và get-resources không xuất hiện như giá trị của thuộc tính ‘name’ trên bất kỳ thẻ nào khác trong tệp mô tả dịch vụ web.

VÍ DỤ 4  hoạt động get và set đối với biến socket có id= “targetTemp”, ngay dưới <uiSocket>

(WSDL1 đối với socket không yêu cầu phiên). Ví dụ này giả định định nghĩa của thông điệp “empty” và “targetTemp” trước trong tài liệu WSDL.

VÍ DỤ 5  hoạt động get và set đối với biến socket có id=”targetTemp”, ngay dưới <uiSocket>

(WSDL2 đối với socket không yêu cầu phiên). Ví dụ này giả định định nghĩa thẻ “targetTemp” trong phần <types> của tài liệu WSDL.

7.6.21.1  Biểu diễn giá trị

Giá trị của các biến phải được mô tả dựa trên kiểu dữ liệu cài sẵn của định nghĩa lược đồ XML, khi phù hợp.

Đối với giá trị dựa trên chuỗi, chuỗi trống (“”) phải được mô tả là nội dung thẻ trống, có thuộc tính xsi:null= “false” hoặc không xuất hiện.

Đối với bất kỳ kiểu nào, giá trị không xác định phía được mô tả là phần tử trống có thuộc tính xsi:null= “true”.

CHÚ THÍCH  sử dụng nitlable= “true” trong xác định kiểu tương ứng.

7.6.21.3  Hoạt động get

7.6.21.3.1  Khái quát

Trong WSDL1, hoạt động get của biến phải không có mục đầu vào, và mục đầu ra mang giá trị của biến.

VÍ DỤ 1  WSDL1 đối với socket không yêu cầu phiên: hoạt động get đối với biến read-only “currentRoomTemp” của kiểu xs:float. Biến không được bao gồm trong tập. Tất cả các phần liên quan của tài liệu WSDL1 được liệt kê. Các hình elip (...) biểu thị sự bỏ qua.

Trong WSDL2, hoạt động get của biến phải xác định dạng “http://www.w3.org/ns/wsdl/in-out”. Và kiểu “http://www.w3.org/ns/wsdl/stvle/iri”.

VÍ DỤ 2  WSDL2 đối với socket không yêu cầu phiên: hoạt động get đối với biến read-only “currentRoomTemp” của kiểu xs:float. Biến không bao gồm trong tập. Tất cả các phần liên quan của tài liệu WSDL2 được liệt kê. Các hình elip (...) biểu thị sự bỏ qua.

7.6.21.3.2  Thẻ <wsdl-urc:secret>

Hoạt động get của biến có thể có thẻ <wsdl-urc:secret> là thẻ con của thẻ <documentation>. Nếu hiện diện, nó phải có giá trị Boolean là nội dung, nghĩa là “true” hoặc “false”. Giá trị mặc định là “false”.

Điều này tương ứng với thuộc tính 'secret' trên thẻ <uis:variable> trong mô tả socket (xem TCVN 11523-2 (ISO/IEC 24752-2)).

VÍ DỤ  biến được đánh dấu là mật (WSDL1 và WSDL2).

7.6.21.3.3  Thẻ <wsdl-urc:sensitive>

Hoạt động get của biến có thể có thẻ <wsdl-urc:sensitive> là thẻ con của <documentation>. Nếu hiện diện, nó phải có giá trị Boolean là nội dung, nghĩa là “true” hoặc “false”. Giá trị mặc định là “false”.

Điều này tương ứng với thuộc tính ‘sensitive’ trên thẻ <uis:variable> trong mô tả socket (xem TCVN 11523-2 (ISO/IEC 24752-2)).

VÍ DỤ  biến được đánh dấu là nhạy cảm (WSDL1 và WSDL2).

7.6.21.3.4  Thẻ <wsdl-urc:optional>

Hoạt động get của biến có thể có thẻ <wsdl-urc:optional> là thẻ con của thẻ <documentation>. Nếu hiện diện, nó phải có giá trị Boolean là nội dung, nghĩa là “true” hoặc “false”. Giá trị mặc định là “false”.

Điều này tương ứng với thuộc tính ‘optional’ trên thẻ <uis:variable> trong mô tả socket (xem TCVN 11523-2 (ISO/IEC 24752-2)).

VÍ DỤ  biến được đánh dấu là tùy chọn (WSDL1 và WSDL2).

7.6.21.3.5  Thẻ <wsdl-urc:final>

Hoạt động get của biến có thể có thẻ <wsdl-urc:final> là thẻ con của thẻ <documentation>. Nếu hiện diện, nó phải có giá trị Boolean là nội dụng, nghĩa là “true” hoặc “false”. Giá trị mặc định là “false”.

Điều này tương ứng với thuộc tính ‘final’ trên thẻ <uis:variable> trong mô tả socket (xem TCVN 11523-11523-2 (ISO/IEC 24752-2)).

VÍ DỤ  biến được đánh dấu là cuối cùng (WSDL1 và WSDL2).

CHÚ THÍCH  biến cuối cùng là read-only và do vậy không có hoạt động set.

7.6.21.3.6  Phần phụ thuộc biến

Tất cả phần phụ thuộc của biến phải được gắn với hoạt động get của nó như sau.

Hoạt động get của biến có thể có thẻ <wsdl-urc:dependency> là thẻ con của thẻ <documentation>. Nếu hiện diện, nó có thể có bất kỳ số thẻ con nào sau đây, mỗi thẻ xuất hiện zero hoặc một thời điểm:

- <wsdl-urc:relevant> với biểu thức XPath hợp lệ đánh giá giá trị Boolean, như đã xác định trong phần 2, điều “phần phụ thuộc biến”.

- <wsdl-urc :write> với biểu thức XPath hợp lệ đánh giá giá trị Boolean, như đã xác định trong TCVN 11523-2 (ISO/IEC 24752-2), điều “phần phụ thuộc biến”.

CHÚ THÍCH  biến read-only với phần phụ thuộc viết « falseO” không có hoạt động set.

- <wsdl-urc:insert> với biểu thức XPath hợp lệ đánh giá giá trị Boolean, như đã xác định trong TCVN 11523-2(ISO/IEC 24752-2), điều “phần phụ thuộc biến”.

CHÚ THÍCH  biến cuối cùng với kích cỡ có thể có phần phụ thuộc chèn (để bỏ đi các chỉ số), nhưng không có hoạt động set.

- <wsdl-urc:length> với biểu thức XPath hợp lệ đánh giá một số, như đã xác định trong TCVN 11523-2 (ISO/IEC 24752-2), điều “phần phụ thuộc biến”.

- <wsdl-urc:minLength> với biểu thức XPath hợp lệ đánh giá một số, như đã xác định trong TCVN 11523-2(ISO/IEC 24752-2), điều “phần phụ thuộc biến”.

- <wsdl-urc:maxLength> với biểu thức XPath hợp lệ đánh giá một số, như đã xác định trong TCVN 11523-2 (ISO/IEC 24752-2), điều “phần phụ thuộc biến”.

- <wsdl-urc:pattern> với biểu thức XPath hợp lệ đánh giá một chuỗi, như đã xác định trong TCVN 11523-2 (ISO/IEC 24752-2), điều “phần phụ thuộc biến”.

- <wsdl-urc:minInclusive> với biểu thức XPath hợp lệ đánh giá giá trị của cùng một kiểu với biến mà nó thuộc về, như đã xác định trong TCVN11523-2 (ISO/IEC 24752-2), điều “phần phụ thuộc biến”.

- <wsdl-urc:maxInclusive> với biểu thức XPath hợp lệ đánh giá giá trị của cùng một kiểu với biến mà nó thuộc về như đã xác định trong TCVN 11523-2 (ISO/IEC 24752-2), điều “phần phụ thuộc biến”.

- <wsdl-urc:minExclusive> với biểu thức XPath hợp lệ đánh giá giá trị của cùng một kiểu với biến mà nó thuộc về, như đã xác định trong TCVN 11523-2 (ISO/IEC 24752-2), điều “phần phụ thuộc biến”.

- <wsdl-urc:maxExclusive> với biểu thức XPath hợp lệ đánh giá giá trị của cùng một kiểu với biến mà nó thuộc về, như đã xác định trong TCVN 11523-2 (ISO/IEC 24752-2), điều “phần phụ thuộc biến”.

7.6.21.3.7  Thẻ <wsdl-urc:selection>

Tất cả các tập lựa chọn của biến phải được gắn với hoạt động get của nó như sau.

Hoạt động get của biến có thể có thẻ <wsdl-urc:selection> là thẻ con của thẻ <documentation>. Nếu hiện diện, nó phải phù hợp với thẻ <selection> trong mô tả socket 11523-2 (xem ISO/IEC 24752-2).

CHÚ THÍCH  lựa chọn được sử dụng để giới hạn khoảng giá trị của biến (lựa chọn đóng) hoặc cung cấp giá trị khuyến cáo đối với đầu vào người sử dụng (lựa chọn mở).

Thẻ <wsdl-urc:selection> có thể bao gồm bất kỳ số tập lựa chọn động và tĩnh là thẻ con, mỗi thẻ zero hoặc nhiều lần.

Tập lựa chọn tĩnh phải được thể hiện là thẻ <wsdl-urc:selectionSetStatic> có cú pháp như được mô tả trong ISO/IEC 24752-2, mục "The <selectionSetStatic> element''. Tuy nhiên, thuộc tính ‘name’ phải xuất hiện ở thuộc tính ‘id’, và giá trị của nó phải là độc nhất trong số tất cả các giá trị 'name’ trong tài liệu WSDL.

Thuộc tính 'typeRef phải tham chiếu kiểu hoặc được xác định trong tệp WSDL hoặc được bao gồm bởi nhập kiểu (<xs:include>) hoặc tham chiếu vùng tên ngoài (<xs:import>). Tên đủ điều kiện phải được sử dụng để tham chiếu xác định kiểu ngoài.

VÍ DỤ 1  biến với tập lựa chọn tĩnh đóng, tham chiếu kiểu cục bộ operating ModeType (WSDL1 và WSDL2).

Tập lựa chọn động phải được biểu thị là thẻ <wsdl-urc:selectionSetDynamic>, với cú pháp như được mô tả trong TCVN 11523-2 (ISO/IEC 24752-2), mục “The <selectionSetDynamic> element”. Tuy nhiên, thuộc tính ‘name’ phải xuất hiện ở thuộc tính ‘id’, và giá trị của nó phải là đơn nhất trong số tất cả các giá trị ‘name’ trong tài liệu WSDL.

Thuộc tính 'varRef' phải tham chiếu biến của socket phù hợp (như được mô tả bởi phân khu dịch vụ web).

VÍ DỤ 2  biến với tập lựa chọn động mở, tham chiếu biến danh sách (WSDL1 và WSDL2).

7.6.21.3.8  Các đặc tính từ DCMI

Mọi thẻ và bộ lọc thẻ từ 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ả hoạt động get, nếu phù hợp (như đã xác định trong TCVN 7980 (ISO 15836)). Mỗi thẻ có thể xuất hiện nhiều lần là thẻ con của hoạt động.

Thuộc tính ‘xsi:type’ được sử dụng để xác định lược đồ mã hóa, nếu phù hợp.

VÍ DỤ  mô tả bằng tiếng Anh được cung cấp đối với hoạt động get (WSDL1 và WSDL2). Elip (“...”) biểu thị sự bỏ qua.

7.6.21.3.9  Mục đầu vào "sessionId”

Hoạt động get thuộc về socket yêu cầu phiên phải có mục đầu vào có tên là “sessionId” của kiểu xs:NMTOKEN, xác định định danh của phiên phù hợp.

VÍ DỤ 1  trong WSDL1, nếu mục đầu vào “sessionId” chỉ là mục đầu vào, nó được xác định như sau (xem 7.6.21.3.1 để biết thêm thông tin về hoạt động get):

<input message="sessionId" />

VÍ DỤ 2  trong WSDL2, mục đầu vào “sessionId” được xác định như sau:

<input messageLabel="In" element=''sessionId" />

7.6.21.3.10  Mục đầu ra

Hoạt động get của biến phải có một mục đầu ra của kiểu biến, xác định giá trị hiện hành của biến.

VÍ DỤ  trong WSDL1, mục đầu ra “currentRoomTemp” đối với hoạt động get của biến read-only “currentRoomTemp” của kiểu xs:float được xác định như sau (xem 7.6.21.3.1 để biết thêm thông tin về hoạt động get):

<output message="currentRoomTemp''/>

VÍ DỤ 2  trong WSDL2, mục đầu ra “currentRoomTemp” đối với hoạt động get của biến read-only “currentRoomTemp” của kiểu xs:float được xác định như sau (xem 7.6.21.3.1 để biết thêm thông tin về hoạt động get):

<output messageLabel="Out" element="currentRoomTemp" />

CHÚ THÍCH  để biểu thị tính không có sẵn của biến tại thời gian chạy, dịch vụ web có thể quay lại giá trị không xác định như mục đầu ra (xem 7.6.21.2).

7.6.21.3.11  Mục lỗi

Hoạt động get thuộc về socket yêu cầu phiên phải xác định mục lỗi phiên (xem 7,6.14) để biểu thị lỗi phiên.

VÍ DỤ 1  trong WSDL1, mục lỗi “sessionFault” đối với hoạt động get được xác định như sau (xem 7.6.21.3.1 để biết thêm thông tin về hoạt động get):

fault name=''sessionFault" message="sessionStatus"/>

VÍ DỤ 2  trong WSDL2, hoạt động get tham chiếu mục lỗi giao diện “sessionFault”, như sau (xem 7.6.21.3.1 để biết thêm thông tin về hoạt động get):

<outfault ref=''sessionFault"/>

7.6.21.4  Hoạt động set

7.6.21.4.1  Khái quát

VÍ DỤ 1  WSDL1 đối với socket không yêu cầu phiên: hoạt động set đối với biến “targetTemp” của kiểu xs:float. Biến không chứa trong tập. Tất cả các phần liên quan của tài liệu WSDL1 được liệt kê. Elip (...) biểu thị sự bỏ qua.

Trong WSDL2, hoạt động set của biến phải xác định dạng mẫu “http://www.w3.org/ns/wsdl/in-out”. và thể kiểu “http://www.w3.org/ns/wsdl/style/iri”.

VÍ DỤ 2  WSDL2 đối với Socket không yêu cầu phiên: hoạt động set đối với biến “targetTemp” của kiểu xs:float. Biến không được chứa trong tập. Tất cả các phần liên quan khác của tài liệu WSDL2 được liệt kê. Elip (...) biểu thị sự bỏ qua.

7.6.21.4.2  Các đặc tính từ DCMI

Mọi thẻ và bộ lọc thẻ từ thuật ngữ siêu dữ liệu của sáng kiến siêu dữ liệu DublinCore (DCMI) có thể được sử dụng để mô tả hoạt động set, nếu phù hợp (như đã xác định trong TCVN 7980 (ISO 15836)). Mỗi thẻ có thể xuất hiện nhiều lần như thẻ con của hoạt động.

Thuộc tính ‘xsi:type’ được sử dụng để xác định lược đồ mã hóa, nếu phù hợp.

VÍ DỤ  mô tả bằng ngôn ngữ tiếng Anh được cung cấp đối với hoạt động set đối với biến socket “volume” (WSDL1 và WSDL2).

7.6.21.4.3  Mục đầu vào "sessionId''

Hoạt động set thuộc về yêu cầu phiên phải có mục đầu vào có tên là “sessionId” của kiểu xs:NMTOKEN, xác định định danh của phiên phù hợp.

CHÚ THÍCH  xem 7.6.21.3.9 đối với các ví dụ trong WSDL1 và WSDL2.

7.6.21.4.4  Mục đầu vào và đầu ra đối với giá trị của biến

Hoạt động set phải có thẻ đầu vào và đầu ra, cả hai thuộc kiểu của biến. Chúng phải chuyển giá trị được yêu cầu và kết quả của biến.

CHÚ THÍCH 1  xem 7.6.21.4.1 đối với các ví dụ trong WSDL1 và WSDL2.

CHÚ THÍCH 2  để biểu thị tính không có sẵn của biến tại thời gian chạy, dịch vụ web có thể quay lại giá trị không xác định là mục đầu ra (xem 7.6.21.2)

7.6.21.4.5  Mục lỗi

Hoạt động set phụ thuộc socket yêu cầu phiên phải xác định mục lỗi phiên (xem 7.6.14) để biểu thị lỗi phiên)

CHÚ THÍCH  xem 7.6.21.4.1 đối với các ví dụ trong WSDL1 và WSDL2.

7.6.21.4.6  Hoạt động get-resources

7.6.21.4.6.1  Khái quát

VÍ DỤ 1  WSDL1 đối với socket không yêu cầu phiên: hoạt động get-resources operation đối với biến “operatingMode” của kiểu uisistringListItem. Biến không được bao gồm trong tập. Tất cả các phần liên quan của tài liệu WSDL1 được liệt kê. Elip (...) biểu thị sự bỏ qua.

Trong WSDL2, hoạt động get-resources của biến phải xác định dạng mẫu “http://www.w3.org/ns/wsdl/in-out”. và kiểu “http://www.w3.Org/ns/wsdl/style/iri”.

VÍ DỤ 2  WSDL2 đối với Socket không yêu cầu phiên: hoạt động get-resources đối với biến “operatingMode” của kiểu uis:stringListItem. Biến không bao gồm trong tập. Tất cả các phần liên quan của tài liệu WSDL2 được liệt kê. Elip (...) biểu thị sự bỏ qua.

7.6.21.5.2  Các đặc tính từ DCMI

Mọi thẻ và bộ lọc thẻ từ tập các thuật ngữ siêu dữ liệu của sáng kiện dữ liệu Dublin Core (DCMI) có thể được sử dụng để mô tả hoạt động get-resources, nếu phù hợp (như đã xác định trong TCVN 7980 (ISO 15836)). Mỗi thẻ có thể xuất hiện một số lần như thẻ con của hoạt động.

Thuộc tính ‘xsi:type’ được sử dụng để xác định lược đồ mã hóa, nếu phù hợp.

VÍ DỤ  mô tả được cung cấp đối với hoạt động get-resources (WSDL1 và WSDL2).

7.6.21.5.3  Mục đầu vào "sessionId''

Hoạt động get-resources thuộc về yêu cầu phiên phải có mục đầu vào có tên là “sessionId” của kiểu xs:NMTOKEN, xác định định danh của phiên phù hợp.

CHÚ THÍCH  xem 7.6.21.3.9 đối với các ví dụ trong WSDL1 và WSDL2.

7.6.21.5.4  Mục đầu ra đối với tài nguyên nguyên tử động

Hoạt động get-resources phải có mục đầu ra của thẻ “wsdl-urc:resItems” (xem 6.4.4).

CHÚ THÍCH 1  xem 7.6.21.5.1 đối với các ví dụ trong WSDL1 và WSDL2.

CHÚ THÍCH 2  để biểu thị tính không sẵn có của biến tại thời gian chạy, dịch vụ web có thể quay lại giá trị không xác định là mục đầu ra (xem 7.6.21.2).

7.6.21.5.5  Mục lỗi

Hoạt động get-resources thuộc về socket yêu cầu phiên phải xác định mục lỗi phiên (xem 7.6.14) để cho biết lỗi phiên.

CHÚ THÍCH  xem 7.6.21.4.1 đối với các ví dụ trong WSDL1 và WSDL2.

7.6.22  Lệnh

7.6.22.1  Khái quát

Đối với mỗi lệnh trong socket, hoạt động lệnh phải được bao gồm trong phân khu dịch vụ web biểu diễn socket (xem 6.5). Nếu kiểu của lệnh khác với 'uis:voidCommand', phân khu phải bao gồm hoạt động get-status. Hoạt động get-resources có thể được bao gồm nếu dịch vụ web muốn cung cấp tài nguyên nguyên tử động đối với lệnh.

7.6.22.2  Biểu diễn giá trị

Giả trị của biến phải được thể hiện dựa trên kiểu dữ liệu được cài đặt sẵn của định nghĩa lược đồ XML, khi thích hợp.

Đối với giá trị dựa trên chuỗi, chuỗi trống (“”) phải được biểu thị là nội dung thẻ trống, với thuộc tính xsi:null= “false” hoặc không được biểu thị.

Đối với các kiểu bất kỳ, giá trị không xác định phải được biểu thị là thẻ trống với thuộc tính xsi:null= “true”.

CHÚ THÍCH  sử dụng nillable= “true” trong xác định kiểu tương ứng.

7.6.22.3  Hoạt động lệnh

VÍ DỤ 1  đoạn mã WSDL1 đối với socket không yêu cầu phiên: hoạt động get đối với biến read-only “numberOfTicketsIssuedToday” của kiểu “xs:integer, và hoạt động lệnh đối với lệnh “orderTicket”. Lệnh “orderTicket” có thông số đầu ra toàn cục “numberOfTicketsIssuedToday” (tham chiếu biến theo tên), một thông số đầu vào cục bộ “creditCardNumber”, một thông số đầu vào-đầu ra “time”, và một thông số đầu ra cục bộ “transactionNumber”. Lưu ý rằng thông số ''lime" xuất hiện hai lần là đầu vào và mục đầu ra.

VÍ DỤ 2  tương tự như ví dụ 1, nhưng dành cho WSDL2:

Nếu lệnh thuộc kiểu uis:voidCommand, hoạt động lệnh có thể đồng bộ hoặc không đồng bộ. Đối với các kiểu lệnh khác, hoạt động lệnh phải đồng bộ.

Tên của hoạt động lệnh phải có tiền tố “cmd.”, theo sau bởi đường dẫn tập của lệnh, tiếp theo bởi định danh lệnh.

Trong ký hiệu BNF mở rộng:

Tên hoạt động lệnh = “cmd.”, đường dẫn tập, định danh lệnh; trong đó; command identifier là giá trị của thuộc tính ‘id’ của <command>.

VÍ DỤ 1  đối với lệnh với id= “resetProgram” dưới <uiSocket>, hoạt động phù hợp có tên là “cmd.resetProgram”.

VÍ DỤ 2  đối với lệnh với id=''TesetProgram", trong tập với id="advancedFunctions'', dưới <uiSocket>, hoạt động phù hợp có tên là “cmd.advancedFunctions.resetProgram”.

Tên của hoạt động lệnh không được xuất hiện như giá trị của thuộc tính ‘name’ trên bất kỳ thẻ nào khác trong tệp mô tả dịch vụ web.

7.6.22.3.1  Thẻ <wsdl-urc:sensitive>

Hoạt động lệnh có thể có thẻ <wsdl-urc:sensitive> là thẻ con của <documentation>. Nếu hiện diện, nó phải có giá trị Boolean là nội dung, nghĩa là “true” hoặc “false”. Giá trị mặc định là “false”.

Điều này tương ứng với thuộc tính ‘sensitive’ trên thẻ <uis:command> trong mô tả socket (xem TCVN 11523-2 (ISO/IEC 24752-2)).

VÍ DỤ  A lệnh được đánh dấu là sensitive (WSDL1 và WSDL2).

7.6.22.3.2  Thẻ <wsdl-urc:sufficlent>

Hoạt động lệnh có thể có thẻ <wsdl-urc:sufficient> là thẻ con của <documentation>. Nếu hiện diện, nó phải có giá trị Boolean là nội dung, nghĩa là “true” hoặc “false”.

Điều này tương ứng với thuộc tính ‘sufficient’ trên thẻ <uis:command> trong mô tả socket (xem TCVN 11523-2(ISO/IEC 24752-2)).

Nếu hiện diện, thẻ <wsdl-urc:sufficient> của hoạt động lệnh ghi đè thẻ <wsdl- urc:sufficient> của socket (xem 7.6.10). nhưng chỉ dành cho lệnh cụ thể. Nếu không hiện diện, giá trị của thẻ socket <wsdl-urc:sufficient> áp dụng đối với lệnh.

VÍ DỤ  lệnh được đánh dấu là đủ (WSDL1 và WSDL2).

7.6.22.3.3  Thẻ <wsdl-urc:complete>

Hoạt động lệnh có thể có thẻ <wsdl-urc:complete> là thẻ con của <documentation>. Nếu hiện diện, nó phải có giá trị Boolean là nội dung, nghĩa là “true” hoặc “false”.

Điều này tương ứng với thuộc tính ‘complete’ trên thẻ <uis:command> trong mô tả socket (xem TCVN 11523-2 (ISO/IEC 24752-2)).

Nếu hiện diện, thẻ <wsdl-urc:complete> của hoạt động lệnh ghi đè thẻ <wsdl- urc:complete> của socket (xem 7.6.11). nhưng chỉ dành cho lệnh cụ thể. Nếu không hiện diện, giá trị của thẻ socket <wsdl-urc:complete> áp dụng đối với lệnh.

VÍ DỤ  lệnh được đánh dấu là hoàn thiện (WSDL1 và WSDL2).

7.6.22.3.4  Thẻ <wsdl-urc:optional>

Hoạt động lệnh có thể có thẻ <wsdl-urc:optional> là thẻ con của thẻ <documentation>. Nếu hiện diện, nó phải có giá trị Boolean là nội dung, nghĩa là “true” hoăc “false”. Giá trị mặc định là “false”.

Điều này tương ứng với thuộc tính ‘optional’ trên thẻ <uis:command> trong mô tả socket (xem TCVN 11523-2 (ISO/IEC 24752-2)).

VÍ DỤ  lệnh được đánh dấu là tùy chọn (WSDL1 và WSDL2).

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

Hoạt động lệnh có thể có thẻ <wsdl-urc:dependency> là thẻ con của thẻ <documentation>. Nếu hiện diện, nó có thể có bất kỳ số thẻ con nào sau, mỗi phân tử xảy ra nhiều nhất là một lần:

- <wsdl-urc:relevant> với biểu thức XPath hợp lệ đánh giá giá trị Boolean, như đã xác định trong TCVN 11523-2 (ISO/IEC 24752-2), điều “phần phụ thuộc lệnh”.

- <wsdl-urc:write> với biểu thức XPath hợp lệ đánh giá giá trị Boolean, như đã xác định trong I TCVN 11523-2 (ISO/IEC 24752-2), điều “phần phụ thuộc lệnh”.

- <wsdl-urc:insert> với biểu thức XPath hợp lệ đánh giá giá trị Boolean, như đã xác định trong TCVN 11523-2(ISO/IEC 24752-2), điều “phần phụ thuộc lệnh”.

- <wsdl-urc:assert> với biểu thức XPath hợp lệ đánh giá giá trị Boolean, như đã xác định trong TCVN 11523-2 (ISO/IEC 24752-2), điều “phần phụ thuộc lệnh”.

7.6.22.3.6  Đặc tính lệnh từ DCMI

Mọi thẻ và bộ lọc thẻ từ tập các thuật ngữ siêu dữ liệu của sáng kiến siêu dữ liệu DublinCore (DCMI) có thể được sử dụng để mô tả hoạt động lệnh, nếu phù hợp (như đã xác định trong TCVN 7980 (ISO 15836)). Mỗi thẻ có thể xuất hiện một số lần như thẻ con của hoạt động lệnh.

Thuộc tính ‘xsi:type’ được sử dụng để xác định lược đồ mã hóa, nếu phù hợp.

VÍ DỤ  mô tả bằng ngôn ngữ tiếng Anh được cung cấp đối với hoạt động lệnh (WSDL1 và WSDL2) - sự bỏ qua được biểu thị bằng hình elip.

7.6.22.3.7  Thẻ <wsdl-urc:globalParam>

Hoạt động lệnh có thể có một hoặc nhiều thẻ <wsdl-urc:param> là thẻ con của thẻ <documentation>. Nếu hiện diện, bất kỳ thẻ nào phản ánh thông số lệnh toàn cục, như đã xác định trong TCVN 11523-2 (ISO/IEC 24752-2), điều “thông số lệnh”.

VÍ DỤ  thông số đầu vào toàn cục tham chiếu biến “power” trong socket (WSDL1 và WSDL2).

CHÚ THÍCH  thứ tự của mục đầu vào không quan trọng do chúng được xác nhận theo tên.

7.6.22.3.7.1  Thuộc tính ‘idref’

Thẻ <wsdl-urc:globalParam> phải có thuộc tính ‘idref’, với giá trị của nó tham chiếu định danh biến, như đã xác định trong phần 2, điều “thuộc tính ‘idref’ (thông số toàn cục)”.

7.6.22.3.7.2  Thuộc tính 'dir'

Thẻ <wsdl-urc:globalParam> phải có thuộc tính ‘dir’, với một trong các giá trị: “in”, “out”, or “inout”.

Điều này tương ứng với thuộc tính ‘dir’ trên thông số toàn cục trong mô tả socket (xem phần 2, mục “thuộc tính ‘dir’”).

7.6.22.3.8  Mục đầu vào “sessionId”

Hoạt động lệnh thuộc về socket yêu cầu phiên phải có mục đầu vào có tên là “sessionId” của kiểu xs:NMTOKEN, xác định định danh của phiên phù hợp.

CHÚ THÍCH  xem 7.6.22.1 đối với các ví dụ trong WSDL1 và WSDL2.

7.6.22.3.9  Mục đầu vào đối với các thông số lệnh

Mục đầu vào của hoạt động lệnh phải phản ánh thông số đầu vào-đầu ra cục bộ và đầu vào cục bộ của lệnh, như danh sách theo thứ tự. Trong tài liệu WSDL, phải có một mục đầu vào đối với mỗi thông số đầu vào-đầu ra cục bộ và đầu vào cục bộ.

CHÚ THÍCH  xem 7.6.22.1 đối với các ví dụ trong WSDL1 và WSDL2.

7.6.22.3.9.1  Thẻ <wsdl-urc:secret>

Mục đầu vào phản ánh thông số lệnh có thể được đánh dấu là mật. Trong WSDL1, thẻ phù hợp <part> của mục đầu vào có thể có thẻ <documentation> với thẻ <wsdl-urc:secret>. Trong WSDL2, thẻ phù hợp <input> có thể có thẻ <documentation> với thẻ <wsdl-urc:secret>.

Nếu thẻ <wsdl-urc:secret> xuất hiện, nó phải có giá trị Boolean là nội dung, nghĩa là “true” hoặc “false”. Giá trị mặc định là “false”.

Điều này tương ứng với thuộc tính ‘secret’ trên thông số lệnh trong mô tả socket (xem TCVN 11523-2 (ISO/IEC 24752-2)).

7.6.22.3.9.2  Thẻ <wsdl-urc:sensitive>

Mục đầu váo phản ánh thông số lệnh có thể được đánh dấu là nhạy cảm. Trong WSDL1, thẻ phù hợp <part> của mục đầu vào có thể có thẻ <documentation> với thẻ <wsdl-urc:sensitive>. Trong WSDL2, thẻ phù hợp <input> có thể có thẻ <documentation> với thẻ <wsdl-urc:sensitive>.

Nếu thẻ <wsdl-urc:sensitive> xuất hiện, nó phải có giá trị Boolean là nội dung, nghĩa là “true” hoặc “false”. Giá trị mặc định là “false”.

Điều này tương ứng với thuộc tính ‘sensitive’ trên thông số lệnh trong mô tả socket (xem TCVN 11523-2 (ISO/IEC 24752-2)).

7.6.22.3.9.3  Thẻ <wsdl-urc:selection>

Mục đầu vào phản ánh thông số lệnh có thể có tập các lựa chọn. Trong WSDL1, thẻ phù hợp <part> của mục đầu vào có thể có thẻ <documentation> với thẻ <wsdl-urc:selection>. Trong WSDL2, thẻ phù hợp <input> có thể có thẻ <documentation> với thẻ <wsdl-urc:selection>.

Nếu thẻ <wsdl-urc:selection> xuất hiện, nó phải phù hợp với thẻ <selection> trên thông số lệnh trong mô tả socket (xem TCVN 11523-2 (ISO/IEC 24752-2)), nhưng với thẻ con <wsdl-urc:selectionSetStatic> và <wsdl-urc:selectionSetDynamic> ở vị trí của <selectionSetStatic> và <selectionSetDynamic>.

CHÚ THÍCH  lựa chọn được sử dụng để hoặc giới hạn khoảng không giá trị của thông số lệnh (lựa chọn đóng) hoặc cung cấp giá trị đề nghị đối với đầu vào người sử dụng (lựa chọn mở).

7.6.22.3.10  Mục đầu ra đối với trạng thái lệnh

Hoạt động lệnh phải có mục đầu ra phản ánh trạng thái lệnh (giá trị hoàn lại), phụ thuộc vào kiểu lệnh như sau:

Nếu lệnh thuộc kiểu “uis:voidCommand”, không có mục đầu ra tương ứng với trạng thái lệnh.

Nếu lệnh thuộc kiểu “uis:basicCommand” hoặc "uis:timedCommand”, phải có mục đầu ra của thẻ “wsdl-urc:commandStatus”.

Nếu lệnh thuộc kiểu “uis:timedCommand”, phải có mục đầu ra bổ sung của thẻ“wsdl-urc:timeToComplete”. của kiểu xs:duration.

CHÚ THÍCH 1  xem 7.6.22.1 đối với các ví dụ trong WSDL1 và WSDL2.

Trong mô tả socket giao diện người sử dụng phù hợp, không có thông số lệnh nào (đầu vào, đầu ra, và đầu vào-đầu ra) có tên “commandStatus” hoặc “timeToComplete”.

CHÚ THÍCH 2  để biểu thị tính không sẵn có của lệnh tại thời gian chạy, dịch vụ web có thể quay lại giá trị không xác định là mục đầu ra 'status’ (xem 7.6.22.2)

7.6.22.3.11  Mục đầu ra đối với thông số lệnh

Đối với mỗi thông số đầu ra cục bộ và đầu vào-đầu ra của lệnh, mục đầu ra phải được cung cấp bởi hoạt động lệnh. Đối với mỗi thông số, thẻ phải có tên là sau tên thông số. Trong WSDL1, đây là giá trị thuộc tính ‘element’ của thẻ <part> phù hợp trong thẻ <message> được tham chiếu từ thẻ <output>. Trong WSDL2, đây là giá trị thuộc tính ‘element’ trên thẻ <output> phù hợp.

CHÚ THÍCH 1  thông số đầu vào-đầu ra xuất hiện hai lần trong hoạt động lệnh, lần đầu là mục đầu vào, và lần hai là mục đầu ra.

CHÚ THÍCH 2  thứ tự mục đầu ra không quan trọng do chúng được nhận dạng theo tên.

CHÚ THÍCH  xem 7.6.22.1 đối với các ví dụ trong WSDL1 và WSDL2.

7.6.22.3.11.1  Thẻ <wsdl-urc:secret>

Mục đầu ra phản ánh thông số lệnh đầu ra cục bộ hoặc đầu vào-đầu ra có thể có thẻ <wsdl-urc:secret> là thẻ con của thẻ <documentation>. Nếu hiện diện, nó phải có giá trị Boolean là nội dung, nghĩa là “true” hoặc “false”. Giá trị mặc định là “false”.

Điều này tương ứng với thuộc tính ‘secret’ trên thông số lệnh trong mô tả socket (xem TCVN 11523-2 (ISO/IEC 24752-2)).

7.6.22.3.11.2  Thẻ <wsdl-urc:sensitive>

Mục đầu ra phản ánh thông số lệnh đầu ra cục bộ hoặc đầu vào-đầu ra có thể có thẻ <wsdl-urc:sensitivet> là thẻ con của thẻ <documentation>. Nếu hiện diện, nó phải có giá trị Boolean là nội dung, nghĩa là “true” hoặc “false”. Giá trị mặc định là “false”.

Điều này tương ứng với thuộc tính ‘sensitive’ trên thông số lệnh trong mô tả socket (xem TCVN 11523-2 (ISO/IEC 24752-2)).

7.6.22.3.12  Mục lỗi

Hoạt động lệnh thuộc về socket yêu cầu phiên phải xác định mục lỗi phiên (xem 7.6.14) để biểu thị lỗi phiên.

CHÚ THÍCH  xem 7.6.22.1 đối với các ví dụ trong WSDL1 và WSDL2.

7.6.22.4  Hoạt động get-status

Đối với mỗi lệnh socket ngoại trừ kiểu uis:voidCommand, phải có hoạt động get-status được xác định, như sau:

- Tên của hoạt động phải như sau (trong ký hiệu BNF mở rộng):

Tên hoạt động = “getstat.”, đường dẫn tập lệnh, định danh lệnh;

- nếu hoạt động thuộc về socket yêu cầu phiên, nó phải có mục đầu vào có tên là “sessionId” của kiểu xs:NMTOKEN, xác định định danh của phiên phù hợp;

- hoạt động phải có mục đầu ra của thẻ element <wsdl-urc:commandStatus>, biểu thị trạng thái hiện thời của lệnh;

- nếu lệnh thuộc uis:timedCommand, hoạt động phải có mục đầu ra thứ hai <wsdl-urc:timeToComplete> của kiểu xs:duration, phản ánh ước lượng của đích trên thời gian cần thiết để hoàn thiện lệnh phù hợp (xem TCVN 11523-2 (ISO/IEC 24752-2), mục “uis:timedCommand”);

- nếu hoạt động thuộc socket yêu cầu phiên, nó phải có mục lỗi (xem 7.6.14) để biểu thị lỗi phiên;

hoạt động có thể có các đặc tả từ DCMI, như đã xác định trong 7.6.21.3.8.

CHÚ THÍCH 1  thay đổi trạng thái hoặc giá trị thời gian để hoàn thiện của lệnh sẽ được biểu thị khi khách gọi hoạt động get- updates (7.6.20).

CHÚ THÍCH 2  để biểu thị tính không sẵn có của lệnh tại thời gian chạy, dịch vụ web có thể quay lại giá trị không xác định là mục đầu ra ‘commandStatus’ (xem 7.6.22.2)

VÍ DỤ 1  hoạt động get-status đối với lệnh ''orderTicket" trong WSDL1.

VÍ DỤ 2  hoạt động get-status đối với lệnh ''orderTicket'' trong WSDL2.

7.6.22.5  Hoạt động get-resources

Hoạt động get-resources đối với lệnh socket, nếu hiện diện, phải giống như đối với biến (xem 7.6.21.5).

CHÚ THÍCH  để biểu thị tính không sẵn có của lệnh tại thời gian chạy, dịch vụ web có thể quay lại giá trị không xác định là mục đầu ra (xem 7.6.22.2)

7.6.23  Thông báo

7.6.23.1  Khái quát

Đối với mỗi thông báo trong socket, hoạt động kiểm tra phải được bao gồm trong phân khu dịch vụ web biểu diễn socket (xem 6.6). Nếu thông báo có thuộc tính ‘timeout’, hoạt động thời gian chờ gia hạn phải được bao gồm, và mặt khác nó có thể được bao gồm. Nếu kiểu của thông báo khác với “show”, phân khu phải bao gồm hoạt động báo nhận. Hoạt động get-resources có thể được bao gồm nếu dịch vụ web muốn cung cấp tài nguyên nguyên tử động đối với thông báo.

Tên của hoạt động kiểm tra phải có tiền tố “chk.”, theo sau bởi đường dẫn tập thông báo, tiếp sau bởi định danh thông báo. Tên của hoạt động báo nhận phải có tiền tố “ack.”, theo sau bởi đường dẫn tập thông báo, tiếp sau bởi định danh thông báo. Tên của hoạt động thời gian chờ gia hạn phải có tiền tố “ext.”, theo sau bởi đường dẫn tập thông báo, tiếp sau bởi định danh thông báo. Tên của hoạt động get-resources phải có tiền tố “getres.”, theo sau bởi đường dẫn tập thông báo, tiếp sau bởi định danh thông báo.

Trong ký hiệu BNF mở rộng:

- Tên hoạt động kiểm tra = “chk.”, đường dẫn tập, định danh thông báo;

- Tên hoạt động báo nhận = “ack.”, đường dẫn tập, định danh thông báo;

- Tên hoạt động thời gian chờ gia hạn = “ext.”, đường dẫn tập, định danh thông báo;

- Tên hoạt động get-resources = “getres.”, đường dẫn tập, định danh thông báo; trong đó định danh thông báo là giá trị của thuộc tính ‘id’ của <notify>.

VÍ DỤ 1  đối với thông báo với id="errorOccurred'' dưới <uiSocket>, hoạt động kiểm tra phù hợp có tên là “chk.errorOccurred", và hoạt động báo nhận "ack.errorOccurred”.

VÍ DỤ 2  đối với thông báo với id="errorOccurred'' trong tổ hợp với id="errors”, dưới <uiSocket>, hoạt động kiểm tra phù hợp có tên là “chk.errors.errorOccurred”, và hoạt động báo nhận “ack.errors.errorOccurred”.

Tên của hoạt động kiểm tra, thời gian chờ gia hạn, báo nhận get-resources phải không xuất hiện như giá trị của thuộc tính ‘name’ trên bất kỳ thẻ nào khác trong tệp mô tả dịch vụ web.

7.6.23.2  Biểu thị giá trị

Giá trị thông báo phải được thể hiện dựa trên kiểu dữ liệu được cài đặt sẵn của định nghĩa lược đồ XML, khi phù hợp.

Đối với giá trị dựa trên chuỗi, chuỗi trống (“”) phải được biểu thị là nội dung thẻ trống, với thuộc tính xsi:null= “false” hoặc không được biểu thị.

Đối với các kiểu bất kỳ, giá trị không xác định phải được biểu thị là thẻ trống với thuộc tính xsi:null=”true”.

CHÚ THÍCH  sử dụng nillable= “true” trong xác định kiểu tương ứng.

7.6.23.3  Hoạt động kiểm tra

7.6.23.3.1  Khái quát

VÍ DỤ 1  mã WSDL1 dành cho hoạt động kiểm tra đối với thông báo với id=''confirmReset", của kiểu ''confirmCancel'', và kiểu ''alert''. Thông báo không được bao gồm trong tập. Socket là yêu cầu phiên. Elip (“...”) biểu thị sự bỏ qua.

VÍ DỤ 2  mã WSDL2 đối với ví dụ 1. Elip (“...”) biểu thị sự bỏ qua.

VÍ DỤ 3  đoạn mã WSDL1 dành cho hoạt động kiểm tra đối với thông báo id="connectionError'', của kiểu “show”, và kiểu “error”. Thông báo có thời gian chờ mặc định là 10 giây. Được bao gồm trong tập. Socket là yêu cầu phiên.

VÍ DỤ 4  đoạn mã WSDL2 đối với ví dụ 3.

7.6.23.3.2  Thẻ <wsdl-urc:category>

Hoạt động kiểm tra có thể có thẻ <wsdl-urc:category> là thẻ con của <documentation>. Nếu hiện diện, nó phải có bất kỳ giá trị sau là nội dung thẻ: “info”, “alert”, hoặc “error”. Giá trị mặc định là “info”.

Điều này tương ứng với thuộc tính ‘category’ trên thẻ <uis:notify> trong mô tả socket (xem TCVN 11523-2 (ISO/IEC 24752-2)).

7.6.23.3.3  Thẻ <wsdl-urc:sensitive>

Hoạt động kiểm tra có thể có thẻ <wsdl-urc:sensitive> là thẻ con của phân tử <documentation>. Nếu hiện diện, nó phải có giá trị Boolean là nội dung, nghĩa là “true” hoặc “false”. Giá trị mặc định là “false”.

Điều này tương ứng với thuộc tính ‘sensitive’ trên thẻ <uis:notify> trong mô tả socket (xem TCVN 11523-2 (ISO/IEC 24752-2)).

7.6.23.3.4  Thẻ <wsdl-urc:optional>

Hoạt động kiểm tra có thể có thẻ <wsdl-urc:optional> là thẻ con của thẻ documentations. Nếu hiện diện, nó phải có giá trị Boolean là nội dung, nghĩa là “true” hoặc “false”. Giá trị mặc định là “false”.

Điều này tương ứng với thuộc tính ‘optional’ trên thẻ <uis:notify> trong mô tả socket (xem TCVN 11523-2 (ISO/IEC 24752-2)).

7.6.23.3.5  Thẻ <wsdl-urc:timeout>

Hoạt động kiểm tra có thể có thẻ <wsdl-urc:timeout> là thẻ con của thẻ <documentations>. Nếu hiện diện, nó phải có giá trị thuộc kiểu xs:duration.

Điều này tương ứng với thuộc tính ‘timeout’ trên thẻ <uis:notify> trong mô tả socket (xem TCVN 11523-2 (ISO/IEC 24752-2), mục “thuộc tính ‘timeout’”).

VÍ DỤ  mục sau xác định thời gian chờ mặc định 1 phút và 15 giây.

7.6.23.3.6  Phần phụ thuộc thông báo

Hoạt động kiểm tra của thông báo có thể có thẻ <wsdl-urc:dependency> là thẻ con của thẻ <documentations>. Nếu hiện diện, nó có thể có một lần xuất hiện của thẻ con sau:

- <wsdl-urc:insert> với biểu thức XPath hợp lệ đánh giá giá trị Boolean, như đã xác định trong TCVN 11523-2 (ISO/IEC 24752-2).

7.6.23.3.7  Các đặc tính từ DCMI

Mọi thẻ và bộ lọc thẻ từ 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ả thông báo, nếu phù hợp (như đã xác định trong TCVN 7980 (ISO 15836)). Mỗi thẻ có thể xuất hiện một số lần như thẻ con của hoạt động kiểm tra.

Điều này tương ứng với các đặc tả DCMI được gắn với thông báo trong socket, xem TCVN 11523-2 (ISO/IEC 24752-2).

Thuộc tính ‘xsi:type’ được sử dụng để xác định lược đồ mã hóa, nếu phù hợp.

VÍ DỤ  mô tả bằng ngôn ngữ tiếng Anh được cung cấp đối với hoạt động kiểm tra (WSDL1 và WSDL2) - sự bỏ qua được biểu thị bằng hình elip.

7.6.23.3.8  Mục đầu vào "sessionId''

Hoạt động kiểm tra thuộc về socket yêu cầu phiên phải có mục đầu vào có tên là “sessionId” của kiểu xs:NMTOKEN, xác định định danh của phiên phù hợp.

CHÚ THÍCH  xem 7.6.23.1 đối với các ví dụ trong WSDL1 và WSDL2.

7.6.23.3.9  Mục đầu ra "notifyStatus”

Hoạt động kiểm tra phải có mục đầu ra có tên là “notifyStatus” của thẻ <wsdl-uis:notifyStatus>, chuyển trạng thái hiện thời của thông báo (“inactive”, “active” hoặc giá trị không xác định).

CHÚ THÍCH 1  xem 7.6.23.1 đối với các ví dụ trong WSDL1 và WSDL2.

CHÚ THÍCH 2  để biểu thị tính không sẵn có của thông báo tại thời gian chạy, dịch vụ web có thể quay lại giá trị không xác định là mục đầu ra “notifyStatus” (7.6.23.2).

7.6.23.3.10  Mục lỗi

Hoạt động kiểm tra thuộc về socket yêu cầu phiên phải xác định mục lỗi phiên (xem 7.6.14) để biểu thị lỗi phiên.

CHÚ THÍCH  xem 7.6.23.1 đối với các ví dụ trong WSDL1 và WSDL2.

7.6.23.4  Hoạt động thời gian chờ mở rộng

7.6.23.4.1  Khái quát

VÍ DỤ 1  mã WSDL1 đối với hoạt động thời gian chờ mở rộng dành cho thông báo với id= “connectionError”, của kiểu “show”, và của kiểu “error”. Thông báo không bao gồm trong tập. Socket là yêu cầu phiên.

VÍ DỤ 2  mã WSDL2 đối với ví dụ 1.

7.6.23.4.2  Mục đầu vào "sessionId”

Hoạt động thời gian chờ mở rộng thuộc về socket yêu cầu phiên phải có mục đầu vào có tên là “sessionId” của kiểu xs:NMTOKEN, xác định định danh của phiên phù hợp.

CHÚ THÍCH xem 7.6.23.1 đối với các ví dụ trong WSDL1 và WSDL2.

7.6.23.4.3  Mục đầu vào "requestedTimeout”

Hoạt động thời gian chờ mở rộng phải có mục đầu vào với thẻ <wsdl-urc:requestedTimeout> và của kiểu xs:duration, biểu thị thời gian chờ yêu cầu của khách đối với thông báo. Đây là khoảng thời gian chờ hoàn thiện (từ khi kích hoạt thông báo cho đến rút tự động) mà khách yêu cầu từ đích.

Giá trị của mục đầu vào ''TequestedTimeout'' có thể không xác định, trong trường hợp như vậy dịch vụ web sẽ đáp ứng thời gian chờ mặc định là giá trị của mục đầu ra ''grantedTimeout'' (xem 7.6.23.4.4).

CHÚ THÍCH  khách có thể gọi hoạt động thời gian chờ mở rộng nhiều lần, mỗi lần có thời gian chờ yêu cầu gia tăng. Tuy nhiên, luôn phụ thuộc vào đích để quyết định liệu nó sẵn sàng gia hạn thời gian chờ. Chú ý rằng đích đưa ra gia hạn thời gian chờ 5 lần so với thời gian chờ mặc định (xem TCVN 11523-1 (ISO/IEC 24752-1)).

7.6.23.4.4  Mục đầu ra "grantedTimeout''

Hoạt động thời gian chờ mở rộng phải có mục đầu vào đơn với thẻ <wsdl-urc:grantedTimeout> và của kiểu xs:duration, biểu thị thời gian chờ thông báo được đưa ra của dịch vụ web. Đây là khoảng thời gian chờ hoàn thiện từ khi kích hoạt thông báo cho đến rút tự động) mà dịch vụ web cấp cho khách.

7.6.23.4.5  Mục lỗi

Hoạt động thời gian chờ mở rộng thuộc về socket yêu cầu phiên phải xác định mục lỗi phiên (xem 7.6.14) để biểu thị lỗi phiên.

CHÚ THÍCH  xem 7.6.23.1 đối với các ví dụ trong WSDL1 và WSDL2.

7.6.23.5  Hoạt động báo nhận

7.6.23.5.1  Khái quát

VÍ DỤ 1  mã WSDL1 đối với hoạt động báo nhận dành cho thông báo với id=''confirmReset'', của kiểu "confirmCancel'', và của kiểu "alert''. Thông báo không bao gồm trong tập. Socket là yêu cầu phiên.

VÍ DỤ 2  mã WSDL2 cho ví dụ 1.

7.6.23.5.2  Mục đầu vào "sessionId"

Hoạt động báo nhận thuộc về socket yêu cầu phiên phải có mục đầu vào có tên là “sessionId” của kiểu xs:NMTOKEN, xác định định danh của phiên phù hợp.

CHÚ THÍCH  xem 7.6.23.1 đối với các ví dụ trong WSDL1 và WSDL2.

7.6.23.5.3  Mục đầu vào hoạt động

Hoạt động báo nhận phải có mục đầu vào đơn lẻ (có tên tùy ý), phản ánh hoạt động của người sử dụng đối với thông báo. hoạt động này phụ thuộc vào kiểu thông báo:

- Mục đầu vào của thẻ <wsdl-urc:confirm> đối với thông báo của kiểu “confirm”;

- Mục đầu vào của thẻ <wsdl-urc:confirmCancel> đối với thông báo của kiểu “confirmCancel”;

- Mục đầu vào của thẻ <wsdl-urc:yesNo> đối với thông báo của kiểu “yesNo”;

- Mục đầu vào của thẻ <wsdl-urc:yesNoCancel> đối với thông báo của kiểu “yesNoCancel”:

- Mục đầu vào của thẻ <wsdl-urc:option> đối với thông báo của kiểu “option”:

- Mục đầu vào của thẻ <wsdl-urc:optionCancel> đối với thông báo của kiểu “optionCancel”:

- Mục đầu vào trống đối với thông báo của kiểu “custom”.

CHÚ THÍCH  thông báo của kiểu “show” không yêu cầu báo nhận người sử dụng, và vì vậy không có hoạt động báo nhận.

VÍ DỤ  hoạt động báo nhận WSDL2 đối với thông báo "confirmReset" của kiểu "confimnCancel". Socket là không yêu cầu phiên. Elip (“...”) biểu thị sự bỏ qua.

7.6.23.5.4  Không có mục đầu ra

Không có mục đầu ra trên hoạt động báo nhận.

CHÚ THÍCH  trong WSDL1, điều này có nghĩa rằng không có thẻ <output>. Trong WSDL2, điều này có nghĩa rằng thông điệp <output> có thẻ = “#none”.

7.6.23.5.5  Mục lỗi

Hoạt động báo nhận thuộc về socket yêu cầu phiên phải xác định mục lỗi phiên (xem 7.6.14) để biểu thị lỗi phiên.

CHÚ THÍCH  xem 7.6.23.1 đối với các ví dụ trong WSDL1 và WSDL2.

7.6.23.6  Hoạt động get-resources

Hoạt động get-resources đối với thông báo socket, nếu hiện diện, phải giống như đối với biến (xem 7.6.21.5)

7.6.24  Lệnh và biến thông báo

Biến và lệnh thuộc về thông báo phải được biểu thị trong dịch vụ web giống biến thường (xem 7.6.13) và lệnh (xem 7.6.22).

Tuy nhiên, tên của hoạt động tương ứng phải phản ánh quan hệ cấu trúc với thông báo bằng cách tuân theo các quy định sau (trong ký hiệu BNF mở rộng):

Tên hoạt động get đối với biến thông báo = “get.”, đường dẫn tập, tên thông báo, “-”, tên hoạt động set thẻ xác nhận biến đối với biến thông báo = “set.”, đường dẫn tập, tên thông báo, “-”, tên hoạt động lệnh thẻ xác nhận biến đối với biến thông báo = “cmd.”, đường dẫn tập, tên thông báo, thẻ xác nhận lệnh.

VÍ DỤ 1  thông báo với id= “shutdownWarning” với type= “custom” có biến read-only với id= “timeRemaining”, và lệnh với id= “saveAll”. Thông báo được bao gồm trong tập với id= “wamings” dưới <uiSocket>. Do vậy, tệp WSDL tương ứng bao gồm các hoạt động sau:

7.6.25  Thẻ thứ nguyên

Mục chỉ số đối với get, set, get-resources, command, get-status, check, extend-timeout và hoạt động báo nhận

Nếu thẻ socket (biến, lệnh hoặc thông báo) là thứ nguyên, hoặc bất kỳ tập nào của nó cùng với đường dẫn tập là thứ nguyên, hoạt động phù hợp get, set, get-resources, command, get-status, check, extend-timeout và acknowledge phải có mục đầu vào bổ sung (được gọi là “index items”), như sau:

Mục chỉ số (phản ánh thứ nguyên) phải được bổ sung trước mục đầu vào khác.

Đối với mỗi thứ nguyên cùng với đường dẫn tập, mục chỉ số phải được bổ sung (theo thứ tự từ góc đến thẻ).

Tên thẻ của mục chỉ số phải như sau (trong ký hiệu BNF mở rộng):

Tên thẻ mục chỉ số = đường dẫn tập đến tập/thẻ, định danh tập/thẻ , “.”, số chỉ số;

Trong đó set/element là tập hoặc thẻ mà chỉ số đi kèm, và index number là số chỉ số, bắt đầu bằng 0 đối với mỗi thẻ/tập thứ nguyên.

Kiểu mục chỉ số phải là kiểu thứ nguyên phù hợp.

VÍ DỤ 1  cú pháp WSDL1 đối với hoạt động set dành cho biến thứ nguyên với id="targetTempProgram" (có chỉ số đầu tiên của kiểu dayType, và chỉ số thứ hai của kiểu xs:time), được bao gồm trong tập thứ nguyên với id="program” (có chỉ số đơn nhất của kiểu roomType). Socket là không yêu cầu phiên. Elip (“...”) biểu thị sự bỏ qua.

VÍ DỤ 2  cú pháp WSDL2 đối với hoạt động set dành cho biến thứ nguyên với id="targetTempProgram" (có chỉ số đầu tiên của kiểu dayType, và chỉ số thứ hai của kiểu xs:time), được bao gồm trong tập thứ nguyên với id="program" (có chỉ số đơn nhất của kiểu roomType). Socket là không yêu cầu phiên. Elip (“...”) biểu thị sự bỏ qua.

7.6.25.2  Hoạt động get-index

Đối với mỗi thứ nguyên xuất hiện trên bất kỳ tập hoặc thẻ trong socket, hoạt động get-index phải được bổ sung vào tài liệu WSDL. Hoạt động get-index có thể được sử dụng để tìm kiếm giá trị (các chỉ số) của thứ nguyên xuất hiện trong socket, căn cứ giá trị chỉ số cố định đối với tất cả thứ nguyên trước.

CHÚ THÍCH 1  điều này tạo điều kiện "duyệt từng bước một" trên dữ liệu thứ nguyên trong cùng kiểu như nghiên cứu cấu trúc phân cấp. Người sử dụng bắt đầu bằng việc chọn chỉ số đầu tiên, sau đó nhận danh sách các chỉ số thứ hai xuất hiện đối với chỉ số đầu tiên được chọn, và tiếp tục như vậy cho đến khi đạt được dữ liệu cuối cùng. Ví dụ, người sử dụng có thể duyệt thông qua dữ liệu EPG bằng cách chọn ngày đầu tiên, sau đó thời gian và cuối cùng là kênh.

Giá trị của thuộc tính ‘name’ của hoạt động get-index phải như sau (trong ký hiệu BNF mở rộng):

Tên hoạt động get-index = “getidx.”, đường dẫn tập của tập/thẻ, định danh tập/thẻ, số chỉ số;

Trong đó set/element là tập hoặc thẻ mà thứ nguyên thuộc về, và index number là số chỉ số yêu cầu, bắt đầu bằng 0 đối với mỗi thẻ/tập thứ nguyên.

Hoạt động get-index không có phần phụ thuộc.

Hoạt động get-index operation phải có mục đầu vào và đầu ra sau:

- Đối với socket yêu cầu phiên: mục đầu vào có tên là “sessionId” của kiểu xs:NMTOKEN, xác định định danh của phiên thích hợp.

- Mục đầu vào đối với mỗi thứ nguyên trước cùng với đường dẫn tập, như sau:

- Tên thẻ mục đầu vào = đường dẫn của tập/thẻ, định danh tập/thẻ, số chỉ số; trong đó set/element là tập hoặc thẻ mà thứ nguyên thuộc về, và index number là thứ nguyên trước, bắt đầu bằng 0 đối với mỗi thẻ/tập thứ nguyên.

- Kiểu của mục đầu vào phải là kiểu thứ nguyên trước.

- Mục đầu ra như sau:

- Tên thẻ của mục đầu ra phải là (trong ký hiệu BNF mở rộng): Tên thẻ mục đầu ra = đường dẫn tập của tập/thẻ, định danh tập/thẻ, số chỉ số “.list”; trong đó set/element là tập hoặc thẻ mà thứ nguyên thuộc về, và index number là thứ nguyên, bắt đầu bằng 0 đối với mỗi thẻ/tập thứ nguyên.

- Kiểu của mục đầu ra phải là kiểu trong danh sách đối với kiểu thứ nguyên mà hoạt động get-index thuộc về.

- Đối với socket yêu cầu phiên: mục lỗi (xem 7.6.14) để biểu thị lỗi phiên.

VÍ DỤ  socket không yêu cầu phiên có tập thứ nguyên với một biến cũng là thứ nguyên. Trong ngôn ngữ mô tả socket, điều này được phản ánh như sau:

Trong WSDL1, điều này dẫn đến hoạt động get-index và xác định thông điệp và thẻ sau đây. Elip (“…”) biểu thị sự bỏ qua.

Trong WSDL2, điều này dẫn đến hoạt động get-index, xác định thông điệp và thẻ sau đây. Elip (“...”) biểu thị sự bỏ qua.

CHÚ THÍCH 2  không có hoạt động set-index cho thứ nguyên trên tập hoặc thẻ. Các chỉ số sẽ được cài đặt một cách ngầm định bằng cách cài đặt giá trị thẻ.

7.6.25.3  Hoạt động remove-index

Đối với mỗi thẻ socket thứ nguyên (biến, lệnh hoặc thông báo), hoạt động remove-index được bổ sung vào tài liệu WSDL. Hoạt động remove-index có thể được sử dụng để bỏ đi một thành phần của thẻ thứ nguyên.

CHÚ THÍCH 1  chỉ một thành phần có thể được bỏ đi tại một thời điểm. Việc xóa bỏ nhiều thành phần yêu cầu nhiều lần gọi hoạt động remove-index.

Giá trị của thuộc tính ‘name’ của hoạt động remove-index phải như sau (trong ký hiệu BNF mở rộng): tên hoạt động remove-index = “remidx.”, đường dẫn tập của thẻ, nhận dạng thẻ: trong đó element là thẻ thứ nguyên mà hoạt động remove-index gắn với.

Hoạt động remove-index không có phần phụ thuộc.

Hoạt động remove-index phải có mục đầu vào sau:

- Đối với các socket yêu cầu phiên: mục đầu vào có tên là “sessionId” của kiểu xs:NMTOKEN, xác định định danh của phiên phù hợp.

- Mục đầu vào đối với mỗi thứ nguyên trước thuộc đường dẫn tập như sau:

- Tên thẻ của mục đầu vào phải là (trong ký hiệu BNF mở rộng); Tên thẻ mục đầu vào = đường dẫn tập của tập/thẻ, định danh tập/thẻ, số chỉ số, trong đó set/element là tập hoặc thẻ mà thứ nguyên thuộc về, và index number là số của thứ nguyên trước, bắt đầu bằng 0 đối với mỗi thẻ/tập thứ nguyên.

- Kiểu của mục đầu vào phải là kiểu của thứ nguyên trước

- Mục đầu ra của thẻ “wsdl-urc:remidxResult”, với các giá trị có thể sau:

- “success” - yêu cầu được hoàn thành thành công;

- “notAllowed” - yêu cầu không được hoàn thành do không được phép kiểu chuyển:

- “notExisting” - yêu cầu không được hoàn thành do thành phần yêu cầu không tồn tại;

 -“otherFailure” - yêu cầu không được hoàn thành do bất kỳ lý do nào khác.

- Đối với socket yêu cầu phiên: mục lỗi (xem 7.6.14) để biểu thị lỗi phiên.

VÍ DỤ  kết nối không yêu cầu phiên có tập thứ nguyên với một biến cũng là thứ nguyên (xem ví dụ trong 7.6.25.2).

Trong WSDL1, điều này dẫn đến hoạt động remove-index và xác định thông điệp và thẻ sau đây. Elip (“…”) biểu thị sự bỏ qua.

Trong WSDL2, điều này dẫn đến hoạt động remove-index và định nghĩa thẻ sau đây. Elip (“...”) biểu thị sự bỏ qua.

CHÚ THÍCH 2  không có hoạt động remove-index cho thứ nguyên trên tập. Chỉ số tập chỉ có thể bị bỏ đi bằng cách bỏ đi thành phần thẻ thứ nguyên thích hợp trong tập.

7.7  Tài nguyên

Tài nguyên nguyên tử và tài nguyên khác phải được xác định theo TCVN 11523-5 (ISO/IEC 24752-5), tham chiếu thuộc tính ‘id’ của thẻ socket được gắn (một cách ngầm định), như đã biểu thị bằng hoạt động WSDL phù hợp. Nếu tài nguyên được xác định áp dụng cho phiên bản cụ thể của giao diện người sử dụng thì chúng có thể tham chiếu thuộc tính ‘id’ của mô tả thực hiện giao diện người sử dụng phù hợp (UIID).

Phụ lục A

(Tham khảo)

Tài liệu mẫu về bộ điều nhiệt số

Phụ lục thông tin này bao gồm tham chiếu trực tuyến với tài liệu mẫu, mô tả việc áp dụng tiêu chuẩn này trên bộ điều nhiệt số. Các tài liệu này được thuê ngoài đối với mạng chủ của OpenURC Alliance.

Tài liệu WSDL1 đối với bộ điều nhiệt số có socket phiên bản không đầy đủ, phù hợp với tiêu chuẩn này: http://www.openurc.org/TPL/basic-thermostat-1/basic-thermostat.wsdl1

Tài liệu WSDL2 đối với bộ điều nhiệt số có socket phiên bản không đầy đủ, phù hợp với tiêu chuẩn này: http://www.openurc.org/TPL/basic-thermostat-1/basic-thermostat.wsdl2

Mô tả đích đối với bộ điều nhiệt số, khi được nhúng trong tài liệu WSDL: http://www.openurc.org/TPL/basic-thermostat-1/basic-thermostat.td

Mô tả đích đối với bộ điều nhiệt số, khi được nhúng trong tài liệu WSDL: http://www.openurc.org/TPL/basic-thermostat-1/basic-thermostat.uis

Thư mục tài liệu tham khảo

[1] ISO/IEC 10646:2011, Information technology - Universal Coded Character Set (UCS)

[2] ISO/IEC 14977:1996, Information technology - Syntactic metalanguage - Extended BNF

[3] 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

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

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

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

[7] W3C Recommendation: XML Path Language (XPath) 2.0 (Second Edition), W3C Recommendation 14 December 2010 (Link errors corrected 3 January 2011), http://www.w3.org/TR/2010/RECxpath20-20101214/

[8] W3C Recommendation: XQuery 1.0 and XPath 2.0 Functions and Operators (Second Edition), W3C Recommendation 14 December 2010, http://www.w3.org/TR/2010/REC-xpathfunctions- 20101214/

[9] W3C Recommendation: XML Schema Part 1: Structures Second Edition, 28 October 2004, http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/

[10] W3C Recommendation: XML Schema Part 2: Datatypes Second Edition, 28 October 2004, http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/

[11] W3C Recommendation: Web Services Description Language (WSDL) 1.1. W3C Note 15 March 2001, http://www.w3.org/TR/2001/NOTE-wsdl-20010315

[12] W3C Recommendation: Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language. W3C Recommendation 26 June 2007, http://www.w3.org/TR/2007/RECwsdl20- 20070626/

[13] W3C Recommendation: Web Services Description Language (WSDL) Version 2.0 Part 2: Adjuncts. W3C Recommendation 26 June 2007, http://www.w3.org/TR/2007/REC-wsdl20-adjuncts-20070626/

[14] letf R.F.C. 6202. Known Issues and Best Practices for the Use of Long Polling and Streaming in Bidirectional HTTP. IETF, April 2011.http.//tools.ietf.org/html/rfc6202

MỤC LỤC

Lời nói đầu

1  Phạm vi áp dụng

2  Sự phù hợp

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

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

5  Mối quan hệ với các tiêu chuẩn khác

5.1  Mối quan hệ với XML

6  Mô tả ánh xạ

6.1  Khái quát

6.2  Ánh xạ một đích đối với dịch vụ web

6.3  Ánh xạ socket với phân khu dịch vụ web

6.4  Ánh xạ biến socket

6.5  Ánh xạ lệnh socket

6.6  Ánh xạ thông báo socket

6.7  Ánh xạ xác định kiểu socket bên trong với xác định kiểu của dịch vụ web

7  Mô tả đích nhúng và mô tả socket trong tài liệu WSDL

7.1  Khái quát

7.2  Giới hạn về vùng tên đích của phần lược đồ trong

7.3  Giới hạn về định danh trong mô tả socket và đích

7.4  Giá trị thuộc tính ‘name’

7.5  Mô tả đích ngầm định

7.6  Mô tả socket ngầm định

7.7  Tài nguyên

Phụ lục A (Tham khảo) Tài liệu mẫu về bộ điều nhiệt số