Thuộc tính
Nội dung
Tiếng Anh (English)
Văn bản gốc/PDF
Lược đồ
Liên quan hiệu lực
Liên quan nội dung
Thuộc tính
Tải về
Các bản dự thảo

Đang tải văn bản...

Tiêu chuẩn quốc gia TCVN 11523-5:2016 về Công nghệ thông tin - Phần 5

Số hiệu:	TCVN11523-5:2016	Loại văn bản:	Tiêu chuẩn Việt Nam
Nơi ban hành:	***	Người ký:	***
Ngày ban hành:	Năm 2016	Ngày hiệu lực:
ICS:	35.240.20	Tình trạng:	Đã biết

TIÊU CHUẨN QUỐC GIA

TCVN 11523-5:2016

ISO/IEC 24752-5: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 5: MÔ TẢ TÀI NGUYÊN

Information technology - User interfaces - Universal remote console - Part 5: Resource description

Lời nói đầu

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

TCVN 11523-5: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ạn phải đăng nhập hoặc đăng ký Thành Viên TVPL Pro để sử dụng được đầy đủ các tiện ích gia tăng liên quan đến nội dung TCVN.

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

- 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 5: MÔ TẢ TÀI NGUYÊN

Information technology - User interfaces - Universal remote console - Part 5: Resource description

...

Bộ tiêu chuẩn này hỗ trợ việc vận hành các sản phẩm thông tin và điện tử thông qua các giao diện từ xa, thay thế và các tác nhân thông minh.

Tiêu chuẩn này xác định cú pháp và ngữ nghĩa để mô tả các tài nguyên nguyên tử, các tệp tài nguyên, các nhóm và các tệp tạo nhóm liên quan đến giao diện người sử dụng của thiết bị hoặc dịch vụ (“đích”).

2 Sự phù hợp

Đoạn ngôn ngữ đánh dấu mở rộng (XML) là một mô tả tài nguyên nguyên tử tuân theo tiêu chuẩn này nếu nó phù hợp với Điều 6. Mô tả tài nguyên nguyên tử có thể sử dụng các phần mở rộng ngôn ngữ nếu các phần mở rộng đó được mã hóa trong cú pháp XML và tuân theo cú pháp và các yêu cầu trình bày sơ lược trong bộ tiêu chuẩn này cho tất cả các phần không mở rộng.

Tệp XML là tệp tài nguyên tuân theo tiêu chuẩn này nếu nó phù hợp với Điều 7. Tệp tài nguyên có thể sử dụng các phần mở rộng ngôn ngữ nếu các phần mở rộng đó được mã hóa trong cú pháp XML và nếu tuân theo cú pháp và các yêu cầu trình bày sơ lược trong tiêu chuẩn này cho tất cả các phần không mở rộng.

Đoạn XML là tài nguyên tạo nhóm tuân theo tiêu chuẩn này nếu nó phù hợp với Điều 8. Tài nguyên tạo nhóm có thể sử dụng các phần mở rộng ngôn ngữ nếu các phần mở rộng đó được mã hóa trong cú pháp XML và nếu tuân theo cú pháp và các yêu cầu trình bày sơ lược trong tiêu chuẩn này cho tất cả các phần không mở rộng.

Tệp XML là tệp tạo nhóm tuân theo tiêu chuẩn này nếu nó phù hợp với Điều 9. Tệp tạo nhóm có thể sử dụng các phần mở rộng ngôn ngữ nếu các phần mở rộng đó được mã hóa trong cú pháp XML và nếu tuân theo cú pháp và các yêu cầu trình bày sơ lược trong tiêu chuẩn này cho tất cả các phần không mở rộng.

CHÚ THÍCH Các nhà sản xuất URC được khuyến khích cài đặt các URC sao cho việc đánh dấu chưa được công nhận được bỏ qua (có thể thuộc về các phần mở rộng ngôn ngữ không được biết đến) mà không gây ra lỗi.

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

...

TCVN 7980:2015 (ISO 15836:2009) Công nghệ thông tin - Bộ phần tử siêu dữ liệu Dublin Core

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

TCVN 11523-2 (ISO/IEC 24752-2) 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

TCVN 11523-4 (ISO/IEC 24752-4) Công nghệ thông tin - Giao diện người sử dụng - Bộ điều khiển từ xa phổ dụng - Phần 4: Mô tả đích

ISO/IEC 10646:20111) Information technology - Universal coded character set (USC) (Công nghệ thông tin - Bộ ký tự mã hóa tiếng Việt)

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

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

4.1

Tài nguyên nguyên tử không tên (anonymous atomic resource)

...

4.2

Tài nguyên không tên (anonymous resource)

Tài nguyên mà không có định danh toàn cục.

4.3

Mở rộng ngôn ngữ (language extension)

Thêm vào các thẻ, các thuộc tính hoặc các giá trị cho ngôn ngữ dựa trên XML ngoài đặc tả ngôn ngữ gốc.

CHÚ THÍCH Các phần mở rộng ngôn ngữ có thể được cung cấp bởi các tổ chức tiêu chuẩn, các hiệp hội hoặc các tổ chức khác.

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

5.1 Liên quan đến Bộ phần tử siêu dữ liệu Dublin Core

...

5.2 Liên quan đến XML

Tiêu chuẩn này xác định ngôn ngữ dựa trên XML. Đánh dấu trên 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.

Tất cả các tên của thẻ và thuộc tính sử dụng trong Điều 6 và 7 mà không có tiền tố vùng tên được xác định bởi tiêu chuẩn này và là một phần của vùng tên tệp tài nguyên với URI http://openurc.org/ns/rsheet2 . Định danh vùng tên ‘rs’ nên được sử dụng cho nó nếu không được xác định như vùng tên mặc định.

Tất cả các tên của thẻ và thuộc tính sử dụng trong Điều 8 và 9 mà không có tiền tố vùng tên được xác định bởi tiêu chuẩn này và là một phần của vùng tên tệp tạo nhóm với URI http://openurc.org/ns/grpsheet2. Định danh vùng tên ‘gs’ nên được sử dụng cho nó nếu không được xác định như vùng tên mặc định.

Xuyên suốt tiêu chuẩn này, các tiền tố vùng tên và các định danh vùng tên tương ứng sau đây được sử dụng cho việc tham chiếu các vùng tên nước ngoài”

- dc: Bộ phần tử dữ liệu Dublin Core V1.1 vùng tên (http://purl.org/dc/elements/1.1/), như đã quy định trong 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);

...

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

6 Mô tả tài nguyên nguyên tử - <AResDesc>

6.1 Khái quát

Mô tả tài nguyên nguyên tử mô tả một tài nguyên nguyên tử dưới dạng các đặc tính của nó, bao gồm ngữ cảnh mà tài nguyên nguyên tử có thể gắn vào. Một tài nguyên nguyên tử là tài nguyên được sử dụng như thực thể nguyên tử trong khi xây dựng giao diện người sử dụng cụ thể. Một số đặc tính của tài nguyên nguyên tử là tùy chọn và một số có thể xuất hiện một vài lần cho một tài nguyên nguyên tử.

Mô tả tài nguyên nguyên tử phải ở trong định dạng XML và phải được mã hóa trong UCS theo TCVN 8271 (ISO/IEC 10646). Nó phải có thẻ <AResDes> như thẻ gốc của nó.

VÍ DỤ

6.2 Thuộc tính ‘about’

Thẻ <AResDesc> phải có thuộc tính ‘about’ quy định một định danh rõ ràng của tài nguyên nguyên tử. Đây phải là một định danh toàn cục duy nhất theo dạng Định danh tài nguyên thống nhất (URI), như đã quy định trong IETF RFC 3986, bao gồm định danh đoạn kéo theo. URI này có thể hoặc không thể giải quyết được.

...

CHÚ THÍCH 2 Đối với việc lấy lại bản sao của tài nguyên, sử dụng giá trị <contentAt> hơn là thuộc tính ‘about’.

Nếu thuộc tính ‘about’ không hiện diện thì mô tả tài nguyên nguyên tử thích hợp được gọi là “mô tả tài nguyên nguyên tử không tên”.

Mô tả tài nguyên nguyên tử càng ổn định càng tốt.

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

6.3 Thẻ <content>

6.3.1 Khái quát

Thẻ <AResDesc> có thể có một thẻ con <content>, cung cấp nội dung của tài nguyên nguyên tử theo dạng mã hóa XML. Tuy nhiên, một thẻ <AResDesc> không có thẻ con <content> và thẻ <contentAt> (xem điều 6.4) tại cùng một thời điểm.

VÍ DỤ

<content xml:lang=”en”>Temperature</content>

...

CHÚ THÍCH 2 Không có thẻ siêu dữ liệu Dublin Core thích hợp cho <content>.

CHÚ THÍCH 3 Thẻ <content> có thể chứa nội dung mà áp đặt các rủi ro an toàn khi đang được trình diễn. Người sử dụng các tài nguyên nguyên tử được khuyến khích thực hiện các biện pháp bảo vệ thích hợp.

6.3.2 Thuộc tính ‘xsi:type’

Thẻ <content> có thể có thuộc tính ‘xsi:type’ để định danh kiểu nội dung văn bản cho bộ phân tách XML. Các tài nguyên nguyên tử nhị phân (như là hình ảnh) có thể được quy định trong mã hóa nguyên bản, ví dụ trong mã hóa theo chuẩn Base64. Giá trị của thuộc tính ‘xsi:type’ phải là Qname của kiểu dữ liệu dựng sẵn (xem Định nghĩa lược đồ XML Phần 2).

VÍ DỤ Qname xsd:base64Binary tham chiếu base64Binary kiểu dữ liệu XSD nguyên gốc đối với mã hóa nhị phân bất kỳ sử dụng bảng chữ cái Base64.

Các tài nguyên nguyên tử nhị phân có thể được lưu trữ như các tệp riêng biệt và được tham chiếu qua URI (xem điều 6.4).

CHÚ THÍCH Việc sử dụng thuộc tính ‘xsi:type’ tuân theo Định nghĩa lược đồ XML Phần 1.

6.3.3 Thuộc tính ‘xml:lang’

Thẻ <content> có thể có thuộc tính ‘xml:lang’ để quy định ngôn ngữ của nội dung tài nguyên nguyên tử. Các giá trị của thuộc tính ‘xml:lang’ phải là các mã ngôn ngữ như đã xác định bởi Ngôn ngữ đánh dấu mở rộng (XML) 1.0.

...

6.3.4 Thẻ 

6.3.4.1 Khái quát

Thẻ <content> có thể có một hoặc nhiều thẻ con nhằm mục đích quy định các thay đổi ngôn ngữ bên trong nội dung nguyên bản và phân đoạn các văn bản trợ giúp dài (“trợ giúp phân tầng”), các thẻ có thể được xếp lồng với nhau.

VÍ DỤ Từ tiếng Pháp được sử dụng bên trong văn bản tiếng Anh.

Bạn có ’Carnet de Passages en Douane’ được ban hành bởi Hiệp hội ô tô Canada không ?

</content>

Thẻ có thể có thuộc tính ‘id’.

6.3.4.2 Thuộc tính ‘xml:lang’

...

Các thay đổi ngôn ngữ bên trong các tài nguyên nguyên tử văn bản nên được định danh bằng cách bao quanh chuỗi nội dung ngôn ngữ nước ngoài trong thẻ với thuộc tính ‘xml:lang’, như đã xác định bởi Ngôn ngữ đánh dấu mở rộng (XML) 1.0.

6.3.4.3 Thuộc tính ‘title’

Thẻ có thể có thuộc tính ‘title’. Thuộc tính ‘title’ có ích trong việc chia cắt các văn bản trợ giúp dài trong “các tầng”. Mỗi tầng được chứa trong thẻ , với thuộc tính ‘title’ quy định tiêu đề ngôn ngữ tự nhiên cho tầng.

VÍ DỤ

Tiêu đề của thẻ trong ngôn ngữ được quy định bởi thuộc tính ‘xml:lang’ của thẻ hoặc nếu không hiện diện thì trong ngôn ngữ của thuộc tính ‘xml:lang’ gần nhất của mọi thẻ hoặc <content> đang chứa đựng.

6.3.4.4 Thẻ <value>

Thẻ có thể chứa một hoặc nhiều thẻ con <value>. Các tài nguyên nguyên tử văn bản gắn với các thẻ của mô tả socket hoặc UIID, do đó có thể chứa các tham chiếu đến các biến socket để làm thuận tiện cho việc bao gồm các đoạn văn bản động trong tài nguyên nguyên tử. Tham chiếu trong tài nguyên nguyên tử sẽ được thay thế bởi giá trị của biến socket tham chiếu tại thời gian chạy và được cập nhật bất cứ lúc nào giá trị thay đổi.

Thẻ <value> trống phải được sử dụng để quy định vị trí trong tài nguyên nguyên tử nơi giá trị của biến socket được chèn vào. Giá trị của thuộc tính ‘ref’ phải quy định biến socket đang nói đến trong cú pháp Xpointer, tức là URI (xem IETF RFC 3986) của mô tả socket, dấu thăng (#) và id của biến socket.

...

Thẻ <value> không được gắn với các tài nguyên nguyên tử văn bản liên quan đến các thẻ của mô tả đích.

CHÚ THÍCH Vì không có phiên điều khiển trong pha khám phá nên không có truy cập đến các biến socket tại thời điểm đó.

6.4 Thẻ <contentAt>

Thẻ <AResDesc> có thể có một hoặc nhiều thẻ con <contentAt>, mỗi thẻ con quy định URI cục bộ (như đã mô tả trong IETF RFC 3986) có thể được sử dụng để lấy lại nội dung bên ngoài cho tài nguyên nguyên tử đã mô tả từ mạng cục bộ (tức là mạng URC đích (TUN) trong khung tổng quát URC). Tuy nhiên, một thẻ <AResDesc> không có thẻ <content> (xem điều 6.3) và <contentAt> tại cùng một thời điểm.

CHÚ THÍCH 1 <contentAt> có thể xuất hiện nhiều lần để định danh nhiều bản sao sẵn có trên mạng cục bộ

URI phải được quy định như giá trị của thuộc tính 'resource’. URI có thể liên quan, nếu vậy nó được dựa trên URI của tệp tài nguyên. Định dạng này áp dụng cho tài nguyên nguyên tử văn bản lẫn nhị phân.

VÍ DỤ 1 <contentAt resource=“images/temperature.gif” />

Trong ví dụ này, URI liên quan được quy định; việc trình diễn tuyệt đối của nó được dựa trên URI của tệp tài nguyên đang chứa đựng.

...

CHÚ THÍCH 2 Thẻ <contentAt> chỉ có ý nghĩa trong môi trường mạng cục bộ và không ở trên phạm vi toàn cục.

CHÚ THÍCH 3 Đối với mỗi nhãn phi văn bản cung cấp thông qua thẻ <contentAt>, ở đó cần là một nhãn văn bản thuần túy cho cùng một ngữ cảnh sử dụng được cung cấp để đảm bảo rằng việc biểu diễn văn bản thuần túy có thể xảy ra. Nhìn chung, nhãn văn bản có thể được sử dụng như văn bản thay thế cho nhãn phi văn bản.

CHÚ THÍCH 4 Thẻ <contentAt> có thể tham chiếu nội dung bên ngoài mà áp đặt các rủi ro an toàn khi được trình diễn. Người sử dụng được khuyến khích thực hiện các biện pháp bảo vệ thích hợp.

6.5 Thẻ <dc:type>

Thẻ <AResDesc> có thể có một hoặc nhiều thẻ con <dc:type>, mỗi thẻ con quy định một bản chất hoặc loại tài nguyên nguyên tử, <dc:type> gắn với các tài nguyên nguyên tử mà được xác định là một phần của mô tả tài nguyên nguyên tử (xem điều 6.3), cũng như với các tài nguyên nguyên tử mà được lưu trữ bên ngoài mô tả tài nguyên nguyên tử (xem điều 6.4).

Nếu một thẻ <AResDesc> không có thẻ con <dc:type> thì giá trị của thẻ <dc:type> đầu tiên cho tệp tài nguyên bao quanh (xem điều 7.6.2) phải được thừa nhận.

Thẻ <dc:type> phải có nội dung thẻ như đã xác định bởi từ vựng Dublin Core cho kiểu (http://www.dublincore.org/documents/dcmi-type-vocabulary/).

Các giá trị bao gồm:

- “Text” cho các tài nguyên nguyên tử văn bản (giá trị mặc định);

...

VÍ DỤ 1 Các đặc tính cho nhãn văn bản được cung cấp trong văn bản gốc sau đây.

VÍ DỤ 2 Các đặc tính cho nhãn biểu tượng mà không có văn bản được cung cấp như ảnh JPEG.

VÍ DỤ 3 Các đặc tính cho nhãn biểu tượng với văn bản trong ảnh, được cung cấp như ảnh JPEG.

CHÚ THÍCH <dc:type> phù hợp với kiểu thẻ siêu dữ liệu Dublin Core, http://purl.org/dc/elements/1.1/type. Giá trị của nó được quy định trong từ vựng Dublin Core cho kiểu (http://www.dublincore.org/documents/dcmitype- vocabulary/)

6.6 Thẻ <dc:format>

Thẻ <AResDesc> có thể có một thẻ con <dc:format>, thẻ con này quy định biểu thị số của tài nguyên nguyên tử như kiểu định dạng được xác định bởi Bộ phần tử siêu dữ liệu Dublin Core (xem TCVN 7980 (ISO 15836)). <dc:format> phải hiện diện nếu <dc:type> là “Image” hoặc nếu tài nguyên nguyên tử được cung cấp bên ngoài đến tệp tài nguyên (xem điều 6.4). Nếu vắng mặt thì giá trị mặc định của “text/xml” được thừa nhận.

...

Nếu thẻ <AResDesc> không có thẻ con <dc:format > thì giá trị của thẻ <dc:format> đầu tiên cho tệp tài nguyên bao quanh (xem điều 7.6.3) phải được thừa nhận.

Nhãn mà nội dung của nó là chuỗi ký tự không được định dạng với giá trị dc:type là “Text” và giá trị dc:format là “text/xml” hoặc “application/xml” được gọi là “text label”.

CHÚ THÍCH <dc:format> phù hợp với định dạng thẻ siêu dữ liệu Dublin Core, http://purl.org/dc/elements/1.1/format

6.7 Thẻ <useFor>

6.7.1 Khái quát

Thẻ <AResDesc> có thể có một thẻ con <useFor>, thẻ con này quy định thời điểm và vị trí tài nguyên nguyên tử có thể gắn. Ngữ cảnh sử dụng bao gồm trên sáu thành phần khác nhau: “tham chiếu thẻ”, “tham chiếu giá trị”, “tham chiếu thao tác”, “vai trò”, “ngữ cảnh ngôn ngữ” và “đối tượng đích”

VÍ DỤ

CHÚ THÍCH Nếu mô tả tài nguyên không có thẻ <useFor> thì ngữ cảnh sử dụng có thể được thêm vào cho nó bởi mô tả tài nguyên khác với cùng một giá trị thuộc tính ‘about’.

...

6.7.2.1 Khái quát

Thẻ <useFor> có thể có một số thẻ con <Context>, mỗi thẻ con đưa ra một bộ chứa cho các thành phần của ngữ cảnh sử dụng.

6.7.2.2 Thẻ <eltRef>

Thẻ <Context> phải có một thẻ con <eltRef>, mỗi thẻ con này quy định một tham chiếu đến thẻ cụ thể trong cấu trúc cụ thể. Cấu trúc có thể là socket, UIID hay mô tả đích hoặc mọi tài nguyên có liên quan khác cho giao diện người sử dụng cụ thể trong ngữ cảnh khung tổng quát URC.

Tham chiếu phải được quy định như giá trị của thuộc tính ‘resource’ mà phải hiện diện trên <eltRef>. Giá trị phải là URI (như đã quy định trong IETF RFC 3986) và bao gồm định danh đoạn. Khi thích hợp, cú pháp URI và các ngữ nghĩa nên tuân theo khung tổng quát của Xpointer.

VÍ DỤ 1 Tham chiếu đến biến với id =“varld” trong mô tả socket http://example. com/thermometer/socket

CHÚ THÍCH 1 Các tham chiếu đến tập, lệnh và thông báo của mô tả socket tuân theo cùng một mẫu (“socketURI#elementld”).

VÍ DỤ 2 Tham chiếu đến nhóm ngầm định mà được tạo tự động bởi một số URC như một trình bao bọc cho biến thứ nguyên với id = “dimVarld” trong mô tả socket http://example.com/thermometer/socket_. Ví dụ này tham chiếu toàn bộ tập các thành phần của biến, trái với tham chiếu đến thành phần đơn của biến, như đã trình bày trong ví dụ 1.

...

CHÚ THÍCH 2 Các tham chiếu đến trình bao bọc đối với tập, lệnh hoặc thông báo thứ nguyên tuân theo cùng một kiểu (“socketURI#group(dimElementld)”).

VÍ DỤ 3 Tham chiếu đến nhóm với tài nguyên =http://example.com/thermometer/socket/a.gsheet#groupld trong tệp tạo nhóm

CHÚ THÍCH 3 Các tham chiếu đến nhóm đề cập đến việc cung cấp các nhãn và các tài nguyên nguyên tử khác cho các nhóm quy định trong tệp tạo nhóm (xem Điều 9).

VÍ DỤ 4 Tham chiếu đến định nghĩa của kiểu với tên = “typeName” trong mô tả socket “http:// example.com/thermometer/socket”.

CHÚ THÍCH 4 Các tham chiếu đến kiểu bên trong socket đề cập đến việc cung cấp các nhãn và các tài nguyên nguyên tử khác cho các biến của kiểu đó và cho các chỉ số xuất hiện trong các tập và các thẻ thứ nguyên khi chỉ số là của kiểu đó. Chú ý rằng tham chiếu đến tên giá trị thuộc tính ‘name’ của kiểu (hơn là đến giá trị thuộc tính ‘id’) yêu cầu rằng tất cả các giá trị thuộc tính ‘id’ và ‘name’ là duy nhất trong mô tả socket (xem TCVN 11523-2 (ISO/IEC 24752-2)).

VÍ DỤ 5 Tham chiếu đến định nghĩa của kiểu với tên= “typeName” trong tệp lược đồ XML tại URI “http://example.com/types.xsd”.

...

VÍ DỤ 6 Tham chiếu đến thẻ gốc <uiSocket> với id = “socketld” trong mô tả socket “http://example.com/thermometer/socket”.

CHÚ THÍCH 6 Tham chiếu này đề cập đến việc cung cấp tiêu đề/nhãn và các tài nguyên khác cho giao diện người sử dụng (socket).

VÍ DỤ 7 Tham chiếu đến thẻ gốc <target> với id = “targetld” trong mô tả đích “http://example.com/thermometer”.

CHÚ THÍCH 7 Tham chiếu này đề cập đến việc cung cấp tiêu đề/nhãn, mô tả vị trí và các tài nguyên khác cho đích.

VÍ DỤ 8 Tham chiếu đến thẻ <locator> với id = “locatorld” trong mô tả đích “http://example.com/thermometer”.

CHÚ THÍCH 8 Tham chiếu này đề cập đến việc cung cấp tiêu đề/nhãn và các tài nguyên khác cho chức năng định vị của đích.

...

CHÚ THÍCH 9 Tham chiếu này đề cập đến việc cung cấp tiêu đề/nhãn và các tài nguyên khác cho mô tả cài đặc giao diện người sử dụng trong HTML.

VÍ DỤ 10 Tham chiếu đến thẻ XML <container> xuất hiện trong giá trị của biến socket với id = “didlLiteContent” (của kiểu XML phức hợp để trình duyệt thư mục các mục truyền thông số) trong mô tả socket “http://example.com/mediaPlayer/socket”.

<eltRef> http://example.com/mediaPlayer/socket#didlLiteContent//container </eltRef>

CHÚ THÍCH 10 Tham chiếu này đề cập đến việc cung cấp nhãn và các tài nguyên nguyên tử khác cho nội dung phân cách, ví dụ như ngôn ngữ mô tả DIDL-LITE đối với tài nguyên số sử dụng trong UPnP. Điển hình là, nội dung phân cấp được biểu diễn là tài liệu XML của kiểu XML phức hợp hoặc kiểu xsd:anyType (tức là cây nội dung XML tùy ý nhưng chính xác).

VÍ DỤ 11 Tham chiếu đến thẻ XML <container> xuất hiện trong giá trị của kiểu XML phức hợp với tên = “root.type” được xác định trong vùng tên “um:schemas-upnp-org:metadata-1-0/DIDL-Lite’’.

<eltRef> um:schemas-upnp-org:metadata-1-0/DIDL-Lite#root.type//container </eltRef>

CHÚ THÍCH 11 Tham chiếu này đề cập đến việc cung cấp nhãn và các tài nguyên nguyên tử khác cho nội dung phân cấp, được biểu diễn là giá trị của kiểu XML phức hợp (ví dụ như kiểu “root.type” của vùng tên DIDL-LITE) hoặc của kiểu xsd:anyType. Ví dụ này tương tự với ví dụ 10 nhưng khác ở chỗ tham chiếu đến kiểu bên ngoài socket hơn là biến socket. Do đó, nhãn hoặc tài nguyên nguyên tử khác gắn với nội dung XML của mọi biểu socket của kiểu “root.type” của vùng tên “um:schemas-upnp-org:metadata-1-0/DIDL-Lite”.

6.7.2.3 Thẻ <valRef>

...

VÍ DỤ Nhãn “Fahrenheit” được xác định cho giá trị “F” của thẻ với id =”scale” trong socket của nhiệt kế.

Nếu thẻ <valRef> không hiện diện hoặc trống thì tài nguyên nguyên tử sẽ gắn với thẻ tham chiếu nói chung hơn là với giá trị cụ thể. Nếu được quy định nhiều lần thì tài nguyên nguyên tử sẽ gắn với nhiều giá trị của thẻ tham chiếu.

Thẻ <valRef> không được gắn với các thẻ của mô tả đích.

6.7.2.4 Thẻ <opRef>

Phần tử <Context> có thể có một hoặc nhiều thẻ con <opRef>, mỗi thẻ con quy định tham chiếu đến thao tác cụ thể trên thẻ đã định (đưa ra bởi <eltRef>). Các thao tác được tham chiếu bởi URI (xem IETF RFC 3986) như giá trị của thuộc tính ‘resource’ mà xuất hiện trên <opRef>.

VÍ DỤ <opRef resource=“http://openurc.org/ns/res#up” />

Các tham chiếu thao tác bao gồm:

...

-http://openurc.org/ns/res#down - giảm thao tác cho các kiểu mà có khoảng trống giá trị được sắp xếp theo thứ tự. URI này chỉ được sử dụng trong <useFor> tham chiếu biến socket mà kiểu của nó có facet cơ bản được sắp xếp theo thứ tự = “total” hoặc tham chiếu bộ tương tác khoảng chuyển.

CHÚ THÍCH Các mô tả của các thao tác tham chiếu có thể tìm thấy tại các URI (ví dụ: tại http://openurc.org/ns/res#up). Các nhà cung cấp tài nguyên được khuyến khích xác định các URI tham chiếu thao tác mới (trong các miền ngoài http://openurc.org) và được khuyến khích cung cấp các mô tả thích hợp tại các vị trí của các URI mới.

Thẻ <opRef> có thể được sử dụng để cung cấp tài nguyên (ví dụ như nhãn, văn bản trợ giúp, từ khóa hay khóa truy cập) cho thao tác cụ thể trên thẻ trong cấu trúc cụ thể (ví dụ: trên biến socket hoặc bộ tương tác UIID).

Nếu <opRef> không hiện diện thì tài nguyên nguyên tử sẽ gắn với thẻ tham chiếu hoặc với giá trị của nó một cách trực tiếp, hơn là với thao tác cụ thể trên thẻ. Nếu quy định nhiều lần thì tài nguyên sẽ gắn với nhiều thao tác trên thẻ tham chiếu.

Thẻ <Context> phải có:

a) các thẻ không phải <valRef> và không phải <opRef>;

b) ít nhất một thẻ <valRef> và thẻ không phải <opRef>; hoặc

c) thẻ không phải <valRef> và ít nhất một thẻ <opRef>.

6.7.2.5 Thẻ <role>

...

Vai trò phải được quy định như giá trị của thuộc tính ‘resource’ trên URI của <role>, (xem IETF RFC 3986).

VÍ DỤ <role resource=“http://openurc.org/ns/res#laber” />

Các URI của thẻ role cho phép bao gồm:

http://openurc.org/ns/res#label - Tài nguyên nguyên tử được sử dụng để giới thiệu thẻ trong giao diện người sử dụng.

http://openurc.org/ns/res#help , http://openurc.org/ns/res#help-purpose, hoặc http/openurc.org/ns/res#help-effect - Tài nguyên nguyên tử được sử dụng như mục trợ giúp trong giao diện người sử dụng. Tiêu chuẩn này xác định hai hạng mục trợ giúp “purpose (mục đích)” và “effect (kết quả)”. http://openurc.org/ns/res#helppurpose quy định rằng tài nguyên nguyên tử là một tuyên bố về mục đích của thẻ. http://openurc.org/ns/res#help-effect quy định rằng tài nguyên nguyên tử là một sự giải thích (dài hơn) về mối quan hệ giữa trạng thái của thẻ và trạng thái của đích.

http://openurc.org/ns/res#accesskey - Vai trò này quy định một ký tự đơn mà có thể được sử dụng trong liên kết với khóa sửa đổi chuyên về nền tảng để di chuyển trọng tâm đến thẻ. Nếu thẻ được liên kết với lệnh socket thì nó sẽ được kích hoạt.

http://openurc.org/ns/res#keyword - Tài nguyên nguyên tử là từ khóa liên quan đến thẻ tham chiếu. Các từ khóa có thể được sử dụng để hỗ trợ các kiểu điều hướng khác thông qua giao diện người sử dụng, ví dụ như dựa trên tìm kiếm hoặc ngôn ngữ tự nhiên.

http://openurc.org/ns/res#location - Tài nguyên nguyên tử là mô tả vị trí liên quan đến thẻ tham chiếu. Các mô tả vị trí có thể được gắn với các thẻ <target> của các mô tả đích (xem TCVN 11523-4 (ISO/IEC 24752-4)) để cung cấp thông tin vị trí của các thiết bị đích.

CHÚ THÍCH Các mô tả về vai trò có thể được tìm thấy tại các URI (ví dụ: tại http://openurc.org/ns/res#label). Các nhà cung cấp tài nguyên được khuyến khích xác định các URI của thẻ role mới (trong các miền ngoài miềm http://openurc.org) và cung cấp các mô tả thích hợp tại các vị trí của các URI mới.

...

6.7.2.6 Thẻ <forLang>

Thẻ <Context> có thể có một hoặc nhiều thẻ <forLang>, mỗi thẻ mô tả ngữ cảnh ngôn ngữ chung mà tài nguyên nguyên tử có thể gắn. Nếu <forLang> xuất hiện nhiều lần với các giá trị khác nhau thì tài nguyên có thể được gắn trong nhiều ngữ cảnh ngôn ngữ.

Thẻ <forLang> phải chứa định danh ngôn ngữ như nội dung thẻ, hoặc là trống. Định dạng và lược đồ mã hóa của định danh ngôn ngữ phải dành cho thuộc tính ‘xml:lang’ của Ngôn ngữ đánh dấu mở rộng (XML) 1.0. Ngoài ra, thẻ <forLang> trống cho biết tài nguyên nguyên tử không đặc trưng cho ngôn ngữ.

VÍ DỤ Tài nguyên nguyên tử chỉ được sử dụng như một phần của giao diện người sử dụng bằng tiếng Anh được quy định là:

CHÚ THÍCH Nhìn chung, ngữ cảnh ngôn ngữ (quy định bởi <forLang>) khác với mã hóa ngôn ngữ (quy định bởi thuộc tính ‘xml:lang’ trên , xem 6.3.5.2). Ví dụ, tài nguyên nguyên tử như là tiêu đề phim bằng tiếng Anh (xml:lang=”en”) có thể được biểu diễn như một phần của giao diện người sử dụng tivi bằng tiếng Tây Ban Nha (<forLang>es</forLang>).

Nếu thẻ <Context> không có thẻ con <forLang> thì giá trị của thẻ <forLang> đầu tiên cho tệp tài nguyên bao quanh (xem điều 7.6.5) phải được thừa nhận.

6.7.2.7 Thẻ <forTargetInstance>

Thẻ <Context> có thể có một hoặc nhiều thẻ con <forTargetInstance>, mỗi thẻ con quy định đối tượng đích như nội dung thẻ mà tài nguyên nguyên tử có thể gắn. Nếu <forTargetInstance> xuất hiện nhiều lần thì tài nguyên nguyên tử sẽ gắn với mỗi đối tượng đích đã quy định.

...

CHÚ THÍCH Thẻ <forTargetInstance> giúp ích cho tài nguyên nguyên tử mang thông tin về việc cài đặt. Ví dụ, các tài nguyên này có thể được lưu trữ trên máy chủ tài nguyên cục bộ mà nằm trong mạng gia đình.

6.7.3 Thêm một số ví dụ về <useFor>

Điều này bao gồm thêm một số ví dụ về các mô tả <useFor> cho các tài nguyên nguyên tử.

VÍ DỤ 1 Nhãn cho biến volume (âm lượng) trong mô tả socket của tivi từ văn phòng. Nó gắn với các ngữ cảnh ngôn ngữ tiếng Anh. Chú ý rằng nó không chứa tham chiếu giá trị.

VÍ DỤ 2 Xem xét một dịch vụ du lịch trực tuyến (phiên bản 1.0) từ công ty du lịch. Tài nguyên nguyên tử của văn bản trợ giúp đơn giản (vai trò là “help/purpose”) đặc trưng cho biến socket ‘airport’ và giá trị “ORD" được biểu diễn dưới đây. Nó có thể được sử dụng trong mọi ngữ cảnh ngôn ngữ, do đó thẻ <forLang> trống được quy định.

VÍ DỤ 3 Nhãn bằng tiếng Pháp cho tháng Model-2000 của công ty “LiftMaker”. Tài nguyên nguyên tử này tham chiếu thẻ của mô tả đích với id “elevatorTarget”. Không có tham chiếu giá trị nào được đưa ra.

...

VÍ DỤ 4 Nhãn bằng tiếng Anh được cung cấp cho việc làm tăng biến socket trong đó quy định âm lượng cho máy thu thanh. Nhãn này có thể được sử dụng để ghi nhãn nút “louder” nhỏ như một phần của con trượt âm lượng (nút “louder” sẽ là một phần ngầm định của sự biểu diễn UI). Hoặc nó có thể được sử dụng để tạo thuận lợi cho lệnh ngôn ngữ tự nhiên đơn giản nhằm mục đích tăng âm lượng.

VÍ DỤ 5 Mô tả vị trí đích bằng tiếng Anh được cung cấp cho danh mục công trình điện tử (đối tượng thiết bị đích) được cài đặt trong công trình công cộng.

6.8 Thẻ <dc:creator>

Thẻ <AResDesc> có thể có một hoặc nhiều thẻ con <dc:creator>, mỗi thẻ con quy định bộ tạo cho tài nguyên nguyên tử như nội dung thẻ. Bộ tạo phải được quy định như một chuỗi và có thể là URI (như đã quy định trong IETF RFC 3986).

CHÚ THÍCH 1 Bộ tạo là một thực thể chịu trách nhiệm tạo nội dung của tài nguyên nguyên tử (ví dụ: cá nhân, tổ chức hoặc dịch vụ). Một tài nguyên nguyên tử có thể có nhiều bộ tạo.

VÍ DỤ 1 <dc:creator>MyCorp, Inc.</dc:creator>

...

Nếu được sử dụng để quy định bộ tạo theo lược đồ định danh chính thức thì thuộc tính ‘xsi:type’ nên được sử dụng trên <dc:creator> để định danh kiểu dữ liệu đưa ra là Qname.

VÍ DỤ 3 Mã sau đây quy định bộ tạo với mã "XYZ”, theo kiểu ‘creators’ xác định trong vùng tên với tiền tố ‘myns’: <dc:creator xsi:type=“myns:”> XYZ </dc:creator>

Nếu thẻ <AResDesc> không có thẻ con <dc:creator> thì giá trị của tất cả các thẻ <dc:creator> cho tệp tài nguyên bao quanh (xem điều 7.6.8) phải được thừa nhận.

6.9 Thẻ <dc:publisher>

Thẻ <AResDesc> có thể có một hoặc nhiều thẻ con <dc:publisher>, mỗi thẻ con quy định một thực thể tạo sẵn tạo tài nguyên nguyên tử như nội dung thẻ (ví dụ: cá nhân, tổ chức hoặc dịch vụ). Bộ xuất bản phải được quy định như một chuỗi và có thể là URI (như đã quy định trong IETF RFC 3986). Một tài nguyên nguyên tử có thể có nhiều bộ xuất bản.

VÍ DỤ <dc:publisher>MyCorp, Inc.</dc:publisher>

CHÚ THÍCH <dc:publisher> phù hợp với bộ xuất bản thẻ siêu dữ liệu Dublin Core, http://purl.org/dc/ elements/1.1/publisher

Nếu được sử dụng để quy định bộ xuất bản theo lược đồ định danh chính thức thì thuộc tính ‘xsi:type’ nên được sử dụng trên <dc:creator> để định danh kiểu dữ liệu đưa ra là Qname.

Nếu thẻ <AResDesc> không có thẻ con <dc:publisher> thì giá trị của tất cả các thẻ <dc:publisher> cho tệp tài nguyên bao quanh (xem điều 7.6.8) phải được thừa nhận.

...

Thẻ <AResDesc> có thể có một hoặc nhiều thẻ con <dc:contributor>, mỗi thẻ con quy định một bộ phân phối cho nội dung của tài nguyên nguyên tử như nội dung thẻ (ví dụ: cá nhân, tổ chức hoặc dịch vụ). Bộ phân phối phải được quy định như một chuỗi và có thể là URI (như đã quy định trong IETF RFC 3986). Một tài nguyên nguyên tử có thể có nhiều bộ phân phối.

VÍ DỤ <dc:contributor>MyCorp, Inc.</dc:contributor>

CHÚ THÍCH <dc:contributor> phù hợp với bộ phân phối thẻ siêu dữ liệu Dublin Core http://purl.org/dc/elements/1.1/contributor

Nếu được sử dụng để quy định bộ phân phối theo lược đồ định danh chính thức thì thuộc tính ‘xsi:type’ nên được sử dụng trên <dc:contributor> để định danh kiểu dữ liệu đưa ra là Qname.

Nếu thẻ <AResDesc> không có thẻ con <dc:contributor> thì giá trị của tất cả các thẻ <dc:contributor> cho tệp tài nguyên bao quanh (xem điều 7.6.8) phải được thừa nhận.

6.11 Thẻ <dc:rights>

Thẻ <AResDesc> có thể có một hoặc nhiều thẻ con <dc:rights>, mỗi thẻ con quy định bản quyền và các thuật ngữ sử dụng liên quan đến quản lý bản quyền số (DCM) khác như nội dung thẻ và là chuỗi văn bản (không có cú pháp chính thức được yêu cầu).

CHÚ THÍCH <dc:rights> phù hợp với các bản quyền về thẻ siêu dữ liệu Dublin Core, http://purl.org/dc/elements/1.1/rights

...

Nếu thẻ <AResDesc> không có thẻ con <dc:rights> thì giá trị của tất cả các thẻ <dc:rights> cho tệp tài nguyên bao quanh (xem điều 7.6.8) phải được thừa nhận.

6.12 Thẻ <dcterms:audience>

Thẻ <AResDesc> có thể có một hoặc nhiều thẻ con <dcterms:audience>, mỗi thẻ con quy định nội dung thẻ như một lớp thực thể mà tài nguyên nguyên tử có ích cho nó. Nội dung thẻ có thể là mọi giá trị chuỗi (không có cú pháp chính thức được yêu cầu).

VÍ DỤ <dcterms:audience>K-2</dcterms:audience>

Lớp thực thể có thể được định rõ bởi bộ tạo và bộ xuất bản hoặc bên thứ ba. Lớp này có thể được sử dụng theo hai cách: để định danh lớp người sử dụng hoặc lớp URC có thể sử dụng tài nguyên này. Tiêu chuẩn này không xác định và giới hạn việc sử dụng đặc tính này. Tuy nhiên, các ấn bản tương lai của tiêu chuẩn này có thể xác định từ vựng mà có thể được sử dụng để mô tả đặc tính về sự liên quan đến các khách hàng của tài nguyên nguyên tử.

CHÚ THÍCH <dcterms:audience>phù hợp với các audience thẻ siêu dữ liệu Dublin Core, http://purl.org/dc/terms/audience

Nếu được sử dụng để quy định các bản quyền theo lược đồ định danh chính thức thì thuộc tính ‘xsi:type’ nên được sử dụng trên <dcterms:audience> để định danh kiểu dữ liệu đưa ra là Qname.

Nếu thẻ <AResDesc> không có thẻ con <dcterms:audience> thì giá trị của tất cả các thẻ <dcterms:audience> cho tệp tài nguyên bao quanh (xem điều 7.6.6) phải được thừa nhận.

6.13 Thẻ <dcterms:hasVersion>

...

VÍ DỤ dcterms:hasVersion>http://example.com/thermometer/anotherRsheet#temp_label_version </dcterms:hasVersion>

CHÚ THÍCH 1 Thay đổi mô tả tài nguyên nguyên tử có thể dẫn tới một định danh thay đổi (URI). <dcterms:hasVersion> là một cách để diễn tả quan hệ giữa mô tả tài nguyên nguyên tử gốc và tài nguyên nguyên tử dẫn xuất.

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

Nếu Thẻ <AResDesc> không có thẻ con <dcterms:hasVersion> thì không có giá trị nào được kế thừa từ tệp tài nguyên bao quanh.

CHÚ THÍCH 3 Việc kế thừa giá trị <dcterms:hasVersion> của tệp tài nguyên là không có ý nghĩa bởi vì nó tham chiếu một tệp tài nguyên (hơn là một tài nguyên nguyên tử).

6.14 Thẻ <dcterms:isVersionOf>

Thẻ <AResDesc> có thể có một hoặc nhiều thẻ con <dcterms:isVersionOf>, mỗi thẻ con tham chiếu phiên bản, xuất bản, từ viết tắt, tóm tắt hoặc mọi đáp ứng của tài nguyên nguyên tử đã mô tả. Tài nguyên nguyên tử tham chiếu phải được quy định như nội dung thẻ và phải là URI (như đã quy định trong IETF RFC 3986).

VÍ DỤ <dcterms:isVersionOf>http://example.com/thermometer/anotherRsheet#temp_label </dcterms:isVersionOf>

...

Nếu Thẻ <AResDesc> không có thẻ con <dcterms:isVersionOf> thì không có giá trị nào được kế thừa từ tệp tài nguyên bao quanh.

CHÚ THÍCH 3 Việc kế thừa giá trị <dcterms:isVersionOf> của tệp tài nguyên là không có ý nghĩa bởi vì nó tham chiếu một tệp tài nguyên (hơn là một tài nguyên nguyên tử).

6.15 Thẻ <dcterms:isReplacedBy>

Thẻ <AResDesc> có thể có một hoặc nhiều thẻ con <dcterms:isReplacedBy>, mỗi thẻ quy định tài nguyên nguyên tử thay thế, đổi chỗ hoặc không dùng tài nguyên nguyên tử đã mô tả. Tài nguyên nguyên tử tham chiếu phải được quy định như giá trị của thuộc tính ‘resource’ trên <dcterms:isReplaceBy> và phải là URI (như đã quy định trong IETF RFC 3986).

VÍ DỤ <dcterms:isReplacedBy resource=“http://example.com/thermometer/anotherRsheet#temp_label_repl”/>

CHÚ THÍCH 1 <dcterms:isReplacedBy> là một cách để diễn tả một mô tả tài nguyên nguyên tử lỗi thời và mô tả tài nguyên nguyên tử khác nên được sử dụng để thay thế.

CHÚ THÍCH 2 <dcterms:isReplacedBy> phù hợp với isReplaceBy của bộ lọc phần tử siêu dữ liệu Dublin Core http://purl.org/dc/terms/isReplacedBy là bộ lọc của http://purl/org/dc/elements/1.1/relation

Nếu Thẻ <AResDesc> không có thẻ con <dcterms:isVersionOf> thì không có giá trị nào được kế thừa từ tệp tài nguyên bao quanh.

CHÚ THÍCH 3 Việc kế thừa giá trị <dcterms:isReplacedBy> của tệp tài nguyên là không có ý nghĩa bởi vì nó tham chiếu một tệp tài nguyên (hơn là một tài nguyên nguyên tử).

...

Thẻ <AResDesc> có thể có một hoặc nhiều thẻ con <dcterms:replaces>, mỗi thẻ quy định tài nguyên nguyên tử thay thế, đổi chỗ hoặc không dùng tài nguyên nguyên tử tham chiếu. Điều này có nghĩa là tài nguyên nguyên tử đã mô tả có thể được sử dụng thay cho tài nguyên nguyên tử tham chiếu trong mọi ngữ cảnh sử dụng được quy định bởi tài nguyên nguyên tử tham chiếu. Tài nguyên nguyên tử tham chiếu phải được quy định là giá trị của thuộc tính ‘resource’ trên <dcterms:replaces> và phải là URI (như đã quy định trong IETF RFC 3986).

VÍ DỤ <dcterms:isReplacedBy resource= “http://example.com/thermometer/anotherRsheet#temp label”/>

CHÚ THÍCH 1 <dcterms:replaces> có thể được sử dụng nếu mô tả tài nguyên nguyên tử được tạo để thay thế cái lỗi thời.

VÍ DỤ 2 Một trường hợp sử dụng đối với các thẻ <dcterms:isReplacedBy> và <dcterms:replaces> là nhà sản xuất đích muốn thay thế tài nguyên sai sót (và mô tả của nó) mà là mã hóa cứng trong đích bằng một tài nguyên sẵn có thông qua dịch vụ tài nguyên của nhà sản xuất đích. Tài nguyên (mã hóa cứng) cũ được gắn thẻ với thẻ <dcterms:isReplacedBy> và một tài nguyên mới (trong dịch vụ tài nguyên) với thẻ <dcterms:replaces>.

CHÚ THÍCH 2 <dcterms:replaces> phù hợp với isReplaceBy của bộ lọc phần tử siêu dữ liệu Dublin Core http://purl.org/dc/terms/replaces là bộ lọc của http://purl/org/dc/elements/1.1/relation

Nếu Thẻ <AResDesc> không có thẻ con <dcterms:replaces> thì không có giá trị nào được kế thừa từ tệp tài nguyên bao quanh.

CHÚ THÍCH 3 Việc kế thừa giá trị <dcterms:replaces> của tệp tài nguyên là không có ý nghĩa bởi vì nó tham chiếu một tệp tài nguyên (hơn là một tài nguyên nguyên tử).

6.17 Các thẻ khác từ DCMI

Ngoài ra, thẻ <AResDesc> có thể có một số thẻ và bộ lọc phần tử từ tài liệu thuật ngữ về sáng kiến siêu dữ liệu Dublin Core (DCMI) (TCVN 7980 (ISO 15836)) là các thẻ con để mô tả tài nguyên nguyên tử nếu thích hợp. Mỗi thẻ có thể xuất hiện nhiều lần.

...

Đối với mọi thuật ngữ siêu dữ liệu DCMI mà không hiện diện trên thẻ <AResDesc> nhưng hiện diện trên thẻ <ResSheet> bao quanh (xem điều 7.5) thì thẻ <AResDesc> phải kế thừa tất cả các giá trị từ thẻ <ResSheet> bao quanh.

7 Tệp tài nguyên - <ResSheet>

7.1 Khái quát

Tệp tài nguyên là một tệp chứa các mô tả tài nguyên nguyên tử. Các mô tả tài nguyên nguyên tử này mô tả các tài nguyên nguyên tử của miền, ngôn ngữ hoặc kiểu riêng hay mọi kết hợp của miền, ngôn ngữ hoặc kiểu này. Tuy nhiên, cấu trúc này không được yêu cầu bởi tiêu chuẩn này.

Tệp tài nguyên có thể được cung cấp bởi đích (tham chiếu từ mô tả đích của nó) hoặc bởi mọi dịch vụ tài nguyên.

Tệp tệp tài nguyên phải có kiểu MIME “application/urc-ressheet+xml” nếu thích hợp (như đã quy định trong IETF RFC 2046). Thông số ‘charset’ (xem IETF RFC 3023) nên được sử dụng để quy định mã hóa ký tự của tệp tài nguyên. Giá trị của nó phải là “utf-8” hoặc “utf-16”. Nếu thông số ‘charset’ vắng mặt thì thủ tục quy định trong “Ngôn ngữ đánh dấu mở rộng (XML) 1.0 (xuất bản lần 5)”, điều 4.3.3 phải được tuân theo để định rõ việc mã hóa ký tự.

Tệp tài nguyên phải được ghi trong định dạng XML và được mã hóa trong UCS theo TCVN 8271 (ISO/IEC 10646). Đối với việc mã hóa ký tự thì “UTF-8” hoặc “UTF-16” phải được sử dụng.

Tệp tài nguyên phải có thẻ <ResSheet> là thẻ gốc của vùng tên http://openurc.org/ns/rsheet-2. Định danh vùng tên ‘rs’ nên được sử dụng trong các tệp tài nguyên hoặc vùng tên này nên được tạo vùng tên mặc định (như trong ví dụ dưới đây).

Tệp tài nguyên được mô tả dưới dạng các đặc tính, các thẻ scent và các mô tả tài nguyên nguyên tử được chưa. Các đặc tính gắn với tệp tài nguyên nói chung (xem các điều 7.2, 7.3, 7.4 và 7.5). Thẻ scent mô tả sự xuất hiện của giá trị đặc tính riêng trên ít nhất một trong các mô tả tài nguyên nguyên tử được chứa (xem điều 7.6).

...

VÍ DỤ Các mã sau đây là ví dụ thu gọn của tệp tài nguyên cho bộ ổn nhiệt điện tử. Xem Phụ lục A để có một ví dụ đầy đủ. Điển hình, các định danh vùng tên được xác định trong thẻ gốc <ResSheet>.

7.2 Thuộc tính ‘about’

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

CHÚ THÍCH 1 Các nhà sản xuất đích và các nhà cung cấp tài nguyên được khuyến khích tạo các tệp tài nguyên sẵn có một cách công khai bằng cách đặt tệp tài nguyên tại URI được quy định bởi thuộc tính ‘about’.

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

Nếu thuộc tính ‘about’ không hiện diện thì tệp tài nguyên thích hợp được gọi là tệp tài nguyên không tên”.

...

Thẻ <ResSheet> có thể có thẻ con <dcterms:modified>. Tuy nhiên, nó được khuyến cáo được sử dụng các tệp tài nguyên mà bị thay đổi sau khi triển khai. Sự hiện diện của <dcterms:modified> cho biết rằng tệp tài nguyên được sửa đổi từ phiên bản gốc của nó nhưng vẫn sử dụng cùng một định danh (thuộc tính ‘about’, xem điều 7.2).

Nếu hiện diện thì thẻ <dcterms:modified> phải chứa ngày tháng sửa đổi mới nhất của tệp tài nguyên như nội dung thẻ là kiểu xsd:date hoặc xsd:dateTime.

VÍ DỤ <dcterms:modified>2003-12-30</dcterms:modified>

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

Tệp tài nguyên càng ổn định càng tốt khi mà nó được tạo sẵn cho các URC hoặc các dịch vụ tài nguyên. Tệp tài nguyên mà được triển khai rồi thì chỉ có thể được thay đổi nếu định danh của nó (thuộc tính ‘about’) hoặc ngày tháng sửa đổi của nó được thay đổi.

7.4 Thẻ <dcterms:conformsTo>

Thẻ <ResSheet> phải có một hoặc nhiều thẻ con <dcterms:conformsTo>, mỗi thẻ con quy định tham chiếu cho một chuẩn được thiết lập mà tệp tài nguyên và nội dung của nó (các 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ư đã quy định trong IETF RFC 3986) và phải được cung cấp như nội dung thẻ.

VÍ DỤ < dcterms:conformsTo>http://openurc.org/ns/rsheet-2/isoiec 24752-5-2013<dcterms:conformsTo/>

Giá trị “http://openurc.org/ns/rsheet-2/isoiec24752-5-2013” cho biết rằng tệp tài nguyên đã mô tả phù hợp với tiêu chuẩn này.

...

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

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

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

Thẻ <ResSheet> có thể có một số thẻ và bộ lọc thẻ từ Thuật ngữ siêu dữ liệu Dublin Core (xem TCVN 7980 (ISO 15836)) như các thẻ con, nếu thích hợp để mô tả tệp tài nguyên. Mỗi thẻ con có thể xuất hiện nhiều lần.

Cụ thể, các thuật ngữ siêu dữ liệu Dublin Core sau đây có thể xảy ra:

- <dc:creator>

- <dc:publisher>

- <dc:contributor>

- <dc:rights>

...

CHÚ THÍCH Các thẻ này mô tả tệp tài nguyên nói chung. Ngược lại, các thẻ scent của tệp tài nguyên (xem điều 7.6) mô tả các tài nguyên nguyên tử riêng lẻ trong tầng tài nguyên và các đặc tính của chúng.

7.6 Thẻ <scents>

7.6.1 Khái quát

Thẻ <ResSheet> có thể có thẻ con <scents>.

Nếu hiện diện, thẻ <scents> có thể có một số thẻ con, cung cấp các gợi ý cho thẻ mà tệp tài nguyên chứa. Sự hiện diện của mỗi thẻ scent này cho biết rằng giá trị scent gắn 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 giống nhau có thể xuất hiện nhiều lần nhưng với các giá trị khác nhau.

CHÚ THÍCH Các thẻ Scents gắn với các tài nguyên nguyên tử riêng lẻ. Ngược lại, các đặc tính của tệp tài nguyên (xem các điều 7.2, 7.3, 7.4 và 7.5) gắn với tệp tài nguyên nói chung.

7.6.2 Thẻ <dc:type>

Thẻ <dc:type> có thể xuất hiện một số lần bên dưới thẻ <scents>. Nếu hiện diện thì nó sẽ quy định kiểu tài nguyên nguyên tử mà gắn với một hoặc nhiều tài nguyên nguyên tử trong tệp tài nguyên.

Khoảng trống giá trị là giống với thẻ <dc:type> cho các mô tả tài nguyên nguyên tử (xem điều 6.5).

...

7.6.3 Thẻ <dc:format>

Thẻ <dc:format> có thể xuất hiện một số lần bên dưới thẻ <scents>. Nếu hiện diện thì nó sẽ quy định kiểu tài nguyên nguyên tử mà gắn với một hoặc nhiều tài nguyên nguyên tử trong tệp tài nguyên.

Khoảng trống giá trị là giống với thẻ <dc:format> cho các mô tả tài nguyên nguyên tử (xem điều 6.6).

CHÚ THÍCH <dc:format>Text</dc:format>

7.6.4 Thẻ <forDomain>

Thẻ <forDomain> có thể xuất hiện một số lần bên dưới thẻ <scents>. Nếu hiện diện thì mỗi thẻ <forDomain> phải quy định một URI (như đã quy định trong IETF RFC 3986) như nội dung thẻ. Mỗi URI cho biết rằng một miền với URI cho trước được sử dụng như ngữ cảnh sử dụng trong một hoặc nhiều mô tả tài nguyên nguyên tử trong tệp tài nguyên. Miền của một tài nguyên nguyên tử là phần đầu tiên (URI) của giá trị <eltRef>, tham chiếu cấu trúc (ví dụ: socket) mà tài nguyên nguyên tử gắn với (xem điều 6.7.3.2).

VÍ DỤ <forDomain>http://example.com/thermometer/socket</forDomain>

7.6.5 Thẻ <forLang>

Thẻ <forLang> có thể xuất hiện một số lần bên dưới thẻ <scents>. Nếu hiện diện thì nó sẽ quy định ngữ cảnh ngôn ngữ mà gắn với một hoặc nhiều tài nguyên nguyên tử trong tệp tài nguyên.

...

VÍ DỤ < forLang >en</ forLang >

7.6.6 Thẻ <dcterms:audience>

Thẻ <dcterms:audience> có thể xuất hiện một số lần bên dưới thẻ <scents>. Nếu hiện diện thì nó sẽ quy định một audience mà một hoặc nhiều tài nguyên nguyên tử được gán cho.

Khoảng trống giá trị là giống với thẻ <dcterms:audience> cho các mô tả tài nguyên nguyên tử (xem điều 6.12).

VÍ DỤ <dcterms:audience>K-2</dcterms:audience>

7.6.7 Thẻ <role>

Thẻ <role> có thể xuất hiện một số lần bên dưới thẻ <scents>. Nếu hiện diện thì nó sẽ quy định một URI vai trò mà được sử dụng trong ngữ cảnh sử dụng của một hoặc nhiều mô tả tài nguyên nguyên tử trong tệp tài nguyên.

Vai trò phải được quy định như giá trị của thuộc tính ‘resource’ trên <role> (xem IETF RFC 3986). Khoảng trống giá trị cho <role> là giống với <role> cho các ngữ cảnh sử dụng của tài nguyên nguyên tử (xem điều 6.7.2.5).

VÍ DỤ <role resource=“http://openurc.org/ns/res#laber” />

...

Mọi thẻ và bộ lọc phần tử khác từ tài liệu thuật ngữ siêu dữ liệu của sáng kiến siêu dữ liệu Dublin Core (xem TCVN 7980 (ISO 15836)) có thể xuất hiện như các thẻ con của <scents> nhiều lần, cho biết một thẻ scent mà gắn với một hoặc nhiều mô tả tài nguyên trong tệp tài nguyên.

7.7 Thẻ <resItems>

7.7.1 Khái quát

Thẻ <resItems> phải xuất hiện chính xác một lần như thẻ con của <ResSheet>.

7.7.2 Thẻ con của <resItems>

Thẻ <resItems> phải chứa một hoặc nhiều thẻ <AResDesc> như các thẻ con (xem Điều 6).

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

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

8 Tài nguyên tạo nhóm - <Grouping>

...

Tài nguyên tạo nhóm (ngắn gọn là “grouping”) quy định cấu trúc trình diễn của các thẻ socket giao diện người sử dụng hoặc các thẻ UIID theo kiểu trên-xuống là không thuộc mô tả socket. Trong tài nguyên tạo nhóm, các nhóm con riêng lẻ và các thẻ giao diện người sử dụng có thể xuất hiện nhiều lần (trong các nhóm cha khác nhau).

Tài nguyên tạo nhóm phải được ghi theo định dạng XML và được mã hóa trong UCS theo ISO/IEC 10646. Nó được quy định bởi thẻ <Grouping> mà có thể xuất hiện nhiều lần trong tệp tạo nhóm (xem Điều 9). Nhóm trong một tệp tạo nhóm có thể tham chiếu nhóm khác trong cùng hoặc tệp tạo nhóm khác nhau như nhóm con của nó.

CHÚ THÍCH Phần 1 của bộ tiêu chuẩn này yêu cầu ít nhất một tài nguyên tạo nhóm mỗi socket, chứa các tham chiếu đến tất cả các thẻ của nó trong đó giả sử được đưa ra cho người sử dụng xem xét nhưng không có các tham chiếu đến các thẻ của các socket hoặc UIID khác.

VÍ DỤ Tài nguyên tạo nhóm cho mô tả socket UI của bộ ổn nhiệt số

8.2 Thuộc tính ‘about’

Thẻ <Grouping> phải có thuộc tính ‘about’ quy định một định danh rõ ràng của tài nguyên tạo nhóm. Đây phải là một định danh toàn cục duy nhất theo dạng Định danh tài nguyên thống nhất (URI), như đã quy định trong IETF RFC 3986, bao gồm định danh đoạn kéo theo. URI này có thể hoặc không thể giải quyết được.

CHÚ THÍCH 1 Các nhà sản xuất đích và các nhà cung cấp tài nguyên được khuyến khích tạo các tài nguyên tạo nhóm sẵn có một cách công khai bằng cách đặt tệp tài nguyên tại URI được quy định bởi thuộc tính ‘about’.

...

Nếu thuộc tính ‘about’ không hiện diện thì mô tả tài nguyên tạo nhóm thích hợp được gọi là “mô tả tài nguyên tạo nhóm không tên”.

Mô tả tài nguyên nguyên tử càng ổn định càng tốt. Nếu tài nguyên tạo nhóm cần được thay đổi sau khi nó được tạo sẵn cho các URC hoặc các dịch vụ tài nguyên thì định danh của nó (giá trị thuộc tính ‘about’) hoặc ngày tháng sửa đổi mới nhất của tệp tạo nhóm (xem điều 9.3) nên được thay đổi.

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

8.3 Thẻ <forDomain>

Thẻ <forDomain> có thể xuất hiện một hoặc nhiều lần như thẻ con của <Grouping>. Nó được sử dụng để quy định (các) miền của các thẻ giao diện người sử dụng mà xuất hiện như các nhánh của cây nhóm mô tả bởi tài nguyên tạo nhóm.

Mỗi thẻ <forDomain> phải có một URI (như đã quy định trong IETF RFC 3986) như nội dung thẻ, tham chiếu socket UI hoặc UIID bởi tên của nó. Tuy nhiên, URI không có định danh đoạn.

VÍ DỤ 1 Mã sau đây quy định rằng tài nguyên tạo nhóm tham chiếu các thẻ của socket http://example.com/bigapplicant/socket:

<forDomain>http://example.com/bigapplicant/socket</forDomain>

VÍ DỤ 2 Mã sau đây quy định rằng tài nguyên tạo nhóm tham chiếu các thẻ từ hai socket khác nhau

...

8.4 Thẻ <forLang>

Thẻ <forLang> có thể xuất hiện một hoặc nhiều lần trong thẻ <Grouping>. Nếu được quy định nhiều lần với các giá trị khác nhau (các định danh ngôn ngữ), tài nguyên tạo nhóm có thể được gắn trong nhiều ngữ cảnh ngôn ngữ.

<forLang> mô tả ngữ cảnh ngôn ngữ chung mà tài nguyên tạo nhóm được gắn với. <forLang> phải chứa định danh ngôn ngữ như nội dung văn bản hoặc là trống. Định dạng và lược đồ mã hóa của định danh ngôn ngữ là giống với thuộc tính ‘xml:lang’ (xem điều 6.3.5.2). Ngoài ra, thẻ <forLang> trống cho biết rằng tài nguyên tạo nhóm là độc lập với ngôn ngữ.

VÍ DỤ Tài nguyên tạo nhóm được sử dụng như một phần của giao diện người sử dụng bằng tiếng Anh có thể được quy định là:

Nếu thẻ <Grouping> không có thẻ con <forLang> thì nó sẽ kế thừa các giá trị ngôn ngữ được quy định cho thẻ <GrpSheet> bao quanh (xem điều 9.6.3), nếu có.

8.5 Các thẻ từ DCMI

Mọi thẻ và bộ lọc phần tử từ tài liệu thuật ngữ về sáng kiến siêu dữ liệu Dublin Core (DCMI) (TCVN 7980 (ISO 15836)) có thể được sử dụng để chú thích một nhóm, nếu thích hợp. Mỗi thẻ có thể xuất hiện nhiều lần như thẻ con của <Grouping>.

Đối với các thẻ này, thuộc tính ‘xsi:type’ có thể được sử dụng để định danh kiểu dữ liệu (được đưa ra là QName) sử dụng cho việc mã hóa chuỗi ký tự.

...

Đối với mọi thuật ngữ siêu dữ liệu DCMI mà không hiện diện trên thẻ <Grouping> nhưng lại hiện diện trên thẻ <GrpSheet> bao quanh của nó (xem điều 9.6.4), thẻ <Grouping> phải kế thừa tất cả các giá trị từ thẻ <GrpSheet> bao quanh.

8.6 Thẻ <mainGroup>

Thẻ <mainGroup> phải xuất hiện chính xác một lần như thẻ con của Nó quy định nhóm chính cho tài nguyên tạo nhóm đã mô tả.

Nhóm chính phải được tham chiếu bởi URI của nó (như đã quy định trong IETF RFC 3986) mà được mã hóa như giá trị của thuộc tính ‘resource’ phải xuất hiện một lần.

CHÚ THÍCH Nhóm tham chiếu như nhóm chính có thể ở bên trong (tức là xác định bên trong của cùng thẻ <Grouping> hoặc bên ngoài (tức là xác định trong thẻ <Grouping> khác nhau mà có thể hoặc không ở trong cùng một tệp))

8.7 Thẻ <modalGroup>

Thẻ <modalGroup> có thể xuất hiện một số lần như thẻ con của <Grouping>. Nó quy định nhóm được sử dụng như hội thoại theo chế độ, được kích khởi bởi thông báo socket đã định.

Nhóm hội thoại theo chế độ phải được tham chiếu bởi URI của nó (như đã quy định trong IETF RFC 3986) mà được mã hóa như giá trị của thuộc tính ‘resource’ phải xuất hiện một lần.

CHÚ THÍCH 1 Nhóm tham chiếu như nhóm hội thoại theo chế độ có thể ở bên trong (tức là xác định bên trong của cùng thẻ <Grouping> hoặc bên ngoài (tức là xác định trong thẻ <Grouping> khác nhau mà có thể hoặc không ở trong cùng một tệp))

...

CHÚ THÍCH 2 Điển hình, nhóm được sử dụng như hội thoại theo chế độ không được tham chiếu từ hội thoại chính hoặc mọi thành phần con của nó, bởi vì nó không được kích khởi bởi thông báo khởi tạo đích hơn là bởi điều hướng khởi tạo người sử dụng.

8.8 Thẻ <groups>

8.8.1 Khái quát

Thẻ <groups> có thể xuất hiện một lần như thẻ con của <Grouping>.

8.8.2 Thẻ <Group>

Thẻ <Group> có thể xuất hiện một hoặc nhiều lần như thẻ con của <groups>. Nếu hiện diện thì nó sẽ xác định một nhóm với định danh đã định (thuộc tính ‘about’, xem điều 8.8.2.1).

Thứ tự của các thẻ <groupRef> (xem điều 8.8.2.1) xuất hiện trong cùng một thẻ <Group> là quan trọng.

VÍ DỤ Thứ tự của các thẻ <groupRef> có thể được sử dụng cho việc điều hướng, ví dụ khi người sử dụng ấn nút TAB để xem xét thông qua hệ đẳng cấp của các nhóm theo thứ tự tuyến tính.

CHÚ THÍCH 1 Tài nguyên tạo nhóm không chứa thông tin rõ ràng về việc điều hướng tuyến tính, như là được cung cấp bởi thuộc tính ‘tabindex’ của HTML. Khi điều hướng tuyến tính được cung cấp cho người sử dụng thì người cài đặt được khuyến khích xem xét cây nhóm và cây thẻ theo chiều sâu, theo sau thứ tự của các thẻ <groupRef>, <eltRef> và <setRef> thuộc cùng một thẻ <Group>

...

CHÚ THÍCH 3 Cấu trúc của các nhóm trình diễn là số mục nhập của chúng là khía cạnh quan trọng của thiết kế giao diện người sử dụng và nên được chọn cẩn thân. Khi thiết kế giao diện người sử dụng không thuộc phạm vi của bộ tiêu chuẩn này thì cỡ menu của 5 đến 7 thẻ được tìm thấy phù hợp với nhiều hoàn cảnh sử dụng.

8.8.2.1 Thuộc tính ‘about’

Thuộc tính ‘about’ phải hiện diện trên thẻ <Group>. Nó quy định định danh rõ ràng cho nhóm. Đây phải là một định danh toàn cục duy nhất theo dạng Định danh tài nguyên thống nhất (URI), như đã quy định trong IETF RFC 3986, bao gồm định danh đoạn kéo theo. URI này có thể hoặc không thể giải quyết được.

CHÚ THÍCH 1 Nhóm có thể được tham chiếu bởi URI của nó từ các thẻ <mainGroup> hoặc <groupRef> mà có thể là một phần của cùng hoặc các thẻ <Grouping> khác.

CHÚ THÍCH 2 Một phương pháp thực hành hiệu quả là sử dụng như một định danh, định danh (URI) tài nguyên tạo nhóm chứa nhóm, được theo sau bởi dấu thăng ‘#’, được theo sau bởi định danh đoạn là duy nhất trong tài nguyên tạo nhóm.

8.8.2.2 Thẻ <cohesion>

Thẻ <cohesion> có thể xuất hiện một lần như thẻ con của <Group>.

Nó mô tả mức độ kết dính của nhóm, tức là các thẻ của nhóm kết dính chặt chẽ với nhau mức nào liên quan đến sự kết dính của chúng với phần tử gần giống của nhóm. Các phần tử gần giống được định rõ bằng cách tuân theo cấu trúc phân cấp của thẻ <Grouping> thích hợp theo kiểu trên-xuống: các phần tử gần giống là tất cả các thẻ <Group> khác mà được tham chiếu bởi <groupRef> từ nhóm cha.

Mức độ kết dính phải được mã hóa như nội dung thẻ. Các mức độ kết dính hợp lệ là “strong”, “normal” hoặc “weak”, với các giải thích sau đây:

...

- “normal”: Đây là nhóm các mục mà phù hợp với nhau. Nó được khuyến cáo sử dụng nhãn của nhóm khi trình bày nhóm này.

- “weak”: Các mục này có thể được nhóm lại với nhau nhưng không cần được định danh rõ ràng như một nhóm.

Giá trị mặc định là “normal”.

8.8.2.3 Thẻ <groupRef>

Thẻ <groupRef> có thể xuất hiện một hoặc nhiều lần như thẻ con của <Group>, nhưng chỉ khi <Group> không bao gồm thẻ <forNotify> (xem điều 8.8.2.6). Nó tham chiếu nhóm được sử dụng như nhóm con của nhóm đã mô tả. Do đó, nhiều mức độ của nhóm có thể được xác định trong các tài nguyên tạo nhóm.

<groupRef> phải có chính xác một thuộc tính ‘resource’. Giá trị của thuộc tính ‘resource’ phải tham chiếu nhóm con bởi định danh của nó (được đưa ra bởi giá trị của thuộc tính ‘about’ của nhóm con).

Các vòng lặp trong tài nguyên tạo nhóm không được cho phép, tức là nhóm không tự tham chiếu và cũng không tham chiếu mọi nhóm sơ khai như nhóm con.

CHÚ THÍCH Điều này không loại trừ rằng một nhóm có thể có nhiều nhóm cha, xem điều 8.1.

8.8.2.4 Thẻ <eltRef>

...

CHÚ THÍCH 1 Các thẻ socket là các nhánh của cây tài nguyên tạo nhóm như đã mô tả bởi tài nguyên tạo nhóm.

<eltRef> phải có chính xác một thuộc tính ‘resource’. Giá trị của thuộc tính ‘resource’ phải tham chiếu thẻ socket hoặc thẻ UIID bởi định danh của nó là URI (xem IETF RFC 3986).

Thẻ <Group> không có nhiều thẻ <eltRef> với cùng một giá trị ‘resource’, tức là một thẻ không được tham chiếu nhiều lần từ cùng một nhóm.

CHÚ THÍCH 2 Điều này không loại trừ rằng thẻ socket có thể được chứa trong nhiều nhóm, xem điều 8.1.

8.8.2.5 Thẻ <setRef>

Thẻ <setRef> có thể xuất hiện một hoặc nhiều lần như thẻ con của <Group>. Nó tham chiếu một tập trong mô tả socket. Tất cả các thẻ biến hoặc lệnh (không tính các thẻ thông báo) là các bộ phận trực tiếp của tập tham chiếu phải được sử dụng như các thẻ của nhóm đã mô tả. Các tập con của tập tham chiếu và các bộ phận của nó không được bao gồm trong nhóm đã mô tả.

CHÚ THÍCH 1 Nếu <setRef> chỉ là thẻ con của <Group> thì các nhãn và các tài nguyên nguyên tử khác cho tập tham chiếu cũng thích hợp với nhóm quy định bởi thẻ <Group> như một quy ước. Tuy nhiên, nhiều nhãn và tài nguyên nguyên tử cụ thể có thể được quy định bằng cách tham chiếu giá trị ‘about’ của thẻ <Group> bao quanh.

CHÚ THÍCH 2 Nhóm có thể thêm vào thẻ khác không chứa trong (các) tập tham chiếu bằng cách sử dụng thẻ <eltRef>.

<setRef> phải có chính xác một thuộc tính ‘resource’. Giá trị của thuộc tính ‘resource’ tham chiếu một thẻ <set> của mô tả socket bởi định danh của nó (URI, xem IETF RFC 3986).

...

CHÚ THÍCH 3 Điều này không loại trừ rằng một tập có thể được tham chiếu từ nhiều nhóm, xem điều 8.1.

8.8.2.6 Thẻ <forNotify>

Thẻ <forNotify> có thể xảy ra một hoặc nhiều lần bên trong thẻ <Group> nhưng chỉ khi điều sau đây là đúng: (1) nhóm đang chứa không bao gồm thẻ <groupRef> (xem điều 8.8.2.3); và (2) nhóm đang chứa được sử dụng trong một kiểu theo chế độ, tức là được tham chiếu bởi thẻ <modalGroup> (xem điều 8.7).

Thẻ <forNotify> quy định thẻ thông báo socket mà nhóm theo chế độ được liên kết, tức là kích khởi việc trình bày nhóm theo chế độ. Nhiều thẻ thông báo có thể kích khởi việc trình bày một nhóm.

Tham chiếu thẻ thông báo được quy định như giá trị của thuộc tính ‘resource’ phải hiện diện. Định dạng của nó phải là URI (xem IETF RFC 3986), được theo sau bởi dấu thăng ‘#’ và định danh đoạn kéo theo.

CHÚ THÍCH 1 Thông báo thường không phải một phần của điều hướng phân cấp được quy định bởi nhóm chính và các nhóm con của nó. Để bao gồm nó như một hội thoại theo chế độ được kích khởi khi thông báo hoạt động, người thực hiện cần xác định nhóm cho nó (bởi thẻ <Group> xem điều 8.8.2) và tham chiếu thông báo trong nhóm bởi thẻ <notifyFor>.

CHÚ THÍCH 2 Nhóm theo chế độ được kích khởi bởi thông báo có thể có các tham chiếu bổ sung cho các thẻ socket (bởi các thẻ <eltRef> và <setRef>). Trong trường hợp thông báo hoạt động thì các thể tham chiếu sẽ được đưa ra cho người sử dụng như một phần của hội thoại theo chế độ, ngoài bản thân thông báo.

CHÚ THÍCH 3 Việc tạo <forNotify> thành thẻ con của <Group> không giới hạn việc sử dụng lại định nghĩa Group. Ví dụ, một thẻ con có thể sử dụng lại định nghĩa nhóm trong định nghĩa nhóm bên ngoài bằng cách mở rộng định nghĩa Group bên ngoài bởi thẻ <forNotify> như được biểu diễn trong đoạn mã sau đây:

...

9.1 Khái quát

Tệp tạo nhóm là một tệp chứa một hoặc nhiều tài nguyên tạo nhóm.

Tệp tạo nhóm có thể được cung cấp bởi đích (tham chiếu từ mô tả đích của nó) hoặc bởi mọi dịch vụ tài nguyên.

Tệp tạo nhóm phải có kiểu MIME “application/urc-grpsheet+xml”, nếu thích hợp (xem IETF RFC 2046). Thông số ‘charset’ (xem IETF RFC 3023) nên được sử dụng để quy định mã hóa ký tự của tệp tạo nhóm. Giá trị của nó phải là “utf-8” hoặc “utf-16”. Nếu thông số ‘charset’ không hiện diện thì thủ tục quy định trong “Ngôn ngữ đánh dấu mở rộng (XML) 1.0 (xuất bản lần 5)”, điều 4.3.3 phải được tuân theo để định rõ việc mã hóa ký tự.

Tệp tạo nhóm được ghi trong định dạng XML và được mã hóa trong UCS theo TCVN 8271 (ISO/IEC 10646). Đối với việc mã hóa ký tự thì “UTF-8” hoặc “UTF-16” phải được sử dụng.

Tầng tạo nhóm phải có các thẻ <GrpSheet> như thẻ gốc của vùng tên http://openurc.org/ns/gsheet-2. Định danh vùng tên ‘gs’ nên được sử dụng trong các tệp tạo nhóm hoặc vùng tên này nên được tạo vùng tên mặc định (như trong ví dụ dưới đây).

Tệp tạo nhóm được mô tả dưới dạng các đặc tính của nó, các thẻ scent và các tài nguyên tạo nhóm đã chứa. Các đặc tính gắn với tệp tạo nhóm nói chung (ví dụ: quy định bộ xuất bản bởi <dc:publisher> hoặc tiêu đề của nó <dc:title>). Các thẻ scent mô tả sự xuất hiện của giá trị đặc tính riêng trên ít nhất một trong các tài nguyên tạo nhóm đã chứa (ví dụ: quy định ngữ cảnh ngôn ngữ bởi <forLang>).

Thẻ scent của tệp tạo nhóm được kế thừa tự động bởi các tài nguyên tạo nhóm được chứa, trừ khi được quy định trên mức độ của tài nguyên tạo nhóm (xem các điều 8.3, 8.4 và 8.5).

VÍ DỤ Mã sau đây là một đoạn trích của tệp tạo nhóm cho nhiệt kế điện tử. Các định danh vùng tên được xác định trong thẻ gốc <GrpSheet>. Phụ lục A là bản liệt kê đầy đủ của tệp tạo nhóm.

...

9.2 Thuộc tính ‘about’

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

CHÚ THÍCH 1 Các nhà sản xuất đích và các nhà cung cấp tài nguyên được khuyến khích tạo các tệp tạo nhóm sẵn có một cách công khai bằng cách đặt tệp tạo nhóm tại URI được quy định bởi thuộc tính ‘about’.

Nếu thuộc tính ‘about’ không hiện diện thì tệp tạo nhóm thích hợp được gọi là tệp tạo nhóm không tên”.

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

9.3 Thẻ <dcterms:modified>

Thẻ <dcterms:modified> có thể xuất hiện một lần như thẻ con của <GrpSheet>, mỗi thẻ con quy định ngày tháng sửa đổi của tệp tạo nhóm như nội dung thẻ của kiểu xsd:date hoặc xsd:dateTime. Điều này cho biết rằng tệp tạo nhóm được sửa đổi từ phiên bản gốc của nó nhưng vẫn sử dụng cùng một định danh (thuộc tính ‘about’, xem điều 9.2).

VÍ DỤ <dcterms:modified>2003-12-30</dcterms:modified>

...

Tệp tạo nhóm càng ổn định càng tốt khi mà nó được tạo sẵn cho các URC hoặc các dịch vụ tài nguyên. Tệp tạo nhóm mà được triển khai rồi thì chỉ có thể được thay đổi nếu định danh của nó (thuộc tính ‘about’) hoặc ngày tháng sửa đổi của nó được thay đổi.

9.4 Thẻ <dcterms:conformsTo>

Thẻ <GrpSheet> phải có một hoặc nhiều thẻ con <dcterms:conformsTo>, mỗi thẻ con quy định tham chiếu cho một chuẩn được thiết lập mà tệp tạo nhóm và nội dung của nó (các tài nguyên tạo nhóm) phù hợp. Giá trị của mỗi thẻ <dcterms:conformsTo> phải là URI (như đã quy định trong IETF RFC 3986) và phải được cung cấp như nội dung thẻ. Giá trị http://openurc.org/ns/gsheet- 2/isoiec24752-5-2013 cho biết rằng tệp tạo nhóm đã mô tả phù hợp với bộ tiêu chuẩn này.

VÍ DỤ <dcterms:conformsTo>h ttp://openurc.org/ns/rsheet-2/isoiec24752-5-2013<dcterms:conformsTo/>

CHÚ THÍCH 1 Nhiều lần xuất hiện được phép để cho biết sự tương thích với phiên bản tương lai của bộ tiêu chuẩn này hoặc với các hướng dẫn cài đặt khác.

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

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

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

Thẻ <GrpSheet> có thể có một số thẻ và bộ lọc phần tử từ Thuật ngữ siêu dữ liệu Dublin Core (xem TCVN 7980 (ISO 15836)) như các thẻ con, nếu thích hợp để mô tả tệp tạo nhóm. Mỗi thẻ con có thể xuất hiện nhiều lần.

...

- <dc:creator>

- <dc:publisher>

- <dc:contributor>

- <dc:rights>

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

CHÚ THÍCH Các thẻ này mô tả tầng tài tạo nhóm nói chung. Ngược lại, các thẻ scent của tệp tạo nhóm (xem điều 9.6) mô tả các tài nguyên tạo nhóm riêng lẻ trong tệp tạo nhóm và các đặc tính của chúng.

9.6 Thẻ <scents>

9.6.1 Khái quát

Thẻ <GrpSheet> có thể có thẻ con <scents>.

...

CHÚ THÍCH Các thẻ scent gắn với các tài nguyên tạo nhóm. Ngược lại, các đặc tính của tệp tạo nhóm (xem các điều 9.3, 9.4 và 9.5) gắn với tệp tạo nhóm nói chung.

9.6.2 Thẻ <forDomain>

Thẻ <forDomain> có thể xuất hiện một số lần như thẻ con của <scents>. Nếu hiện diện thì mỗi thẻ <forDomain> phải quy định URI (như đã quy định trong IETF RFC 3986) như nội dung thẻ. Mỗi URI quy định một miền xuất hiện trên một nhánh của mọi nhóm chứa trong tệp tạo nhóm.

VÍ DỤ <forDomain>http://example.com/thermometer/socket</forDomain>

9.6.3 Thẻ <forLang>

Thẻ <forLang> có thể xuất hiện một số lần như thẻ con của <scents>. Nếu hiện diện thì nó sẽ quy định ngữ cảnh ngôn ngữ mà gắn với một hoặc nhiều tài nguyên tạo nhóm trong tệp tạo nhóm.

Khoảng trống giá trị cho <forLang> là giống với <forLang> của tài nguyên tạo nhóm.

9.6.4 Các thẻ scent khác của tệp tạo nhóm từ DCMI

Mọi thẻ và bộ lọc phần tử từ tài liệu thuật ngữ về sáng kiến siêu dữ liệu Dublin Core (DCMI) (TCVN 7980 (ISO 15836)) có thể xuất hiện một số lần như thẻ con của <scents>, cho biết rằng một thẻ scent gắn với một hoặc nhiều tài nguyên tạo nhóm trong tệp tạo nhóm.

...

9.7.1 Khái quát

Thẻ <grpItem> phải xuất hiện một lần như thẻ con của <GrpSheet>.

9.7.2 Các thẻ con của <grpItems>

Các thẻ <Grouping> phải xuất hiện một hoặc nhiều lần như thẻ con của <grpItem> (xem Điều 8).

9.8 Các xem xét an toàn

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

Phụ lục A

(Tham khảo)

...

Các tài nguyên trực tuyến sau đây có liên quan đến bộ tiêu chuẩn này:

- Mô tả socket giao diện người sử dụng mẫu cho bộ ổn nhiệt số: http:/www.openurc.org/TPL/basic-thermostat-1/basic-thermostat.uis

- Tệp tạo nhóm mẫu, các định nghĩa tài nguyên tạo nhóm cho mô tả socket của bộ ổn nhiệt số: http://www.openurc.org/TPL/basic-thermostat-1/basic-thermostat.gsheet

- Tệp tài nguyên mẫu, nhãn văn bản và văn bản trợ giúp ngắn cho mỗi thẻ của mô tả socket của bộ ổn nhiệt và các nhãn văn bản cho tất cả các nhóm trong tài nguyên tạo nhóm cung cấp trong tệp tạo nhóm ở trên: http://www.openurc.org/TPL/basic-thermostat-1/basic-thermostat.rsheet

- Lược đồ XML với các định nghĩa cú pháp cho các tệp tài nguyên: http://openurc.org/ns/rsheet-2

- Lược đồ XML với các định nghĩa cú pháp cho các tệp tạo nhóm: http://openurc.org/ns/gsheet-2

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

[1] Guidelines for implementing Dublin Core in XML. April 2003. Dublin Core Metadata Initiative. http://dublincore.org/documents/dc-xml-guidelines/

...

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

[4] IETF RFC 3066, Tags for the Identification of Languages - http://www.ietf.org/rfc/rfc3066

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

[6] DCMI Metadata Terms, http://dublincore.org/documents/dcmi-terms/

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

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

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

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

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

...

[13] W3C Recommendation: XPointer Framework, W3C Recommendation 25 March 2003, http://www.w3.org/TR/2003/REC-xptr-framework-20030325/

MỤC LỤC

Lời nói đầu

1 Phạm vi áp dụng

2 Sự phù hợp

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

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

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

...

5.2 Liên quan đến XML

6 Mô tả tài nguyên nguyên tử - <AResDesc>

6.1 Khái quát

6.2 Thuộc tính ‘about’

6.3 Thẻ <content>

6.4 Thẻ <contentAt>

6.5 Thẻ <dc:type>

6.6 Thẻ <dc:format>

6.7 Thẻ <useFor>

...

6.9 Thẻ <dc:publisher>

6.10 Thẻ <dc:contributor>

6.11 Thẻ <dc:rights>

6.12 Thẻ <dcterms:audience>

6.13 Thẻ <dcterms:hasVersion>

6.14 Thẻ <dcterms:isVersionOf>

6.15 Thẻ <dcterms:isReplacedBy>

6.16 Thẻ <dcterms: Replaces>

6.17 Các thẻ khác từ DCMI

...

7.2 Thuộc tính ‘about’

7.3 Thẻ <dcterms:modified>

7.4 Thẻ <dcterms:conformsTo>

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

7.6 Thẻ <scents>

7.7 Thẻ <resItems>

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

8 Tài nguyên tạo nhóm - <Grouping>

8.1 Khái quát

...

8.3 Thẻ <forDomain>

8.4 Thẻ <forLang>

8.5 Các thẻ từ DCMI

8.6 Thẻ <mainGroup>

8.7 Thẻ <modalGroup>

8.8 Thẻ <groups>

9 Tệp tạo nhóm - <GrpSheet>

9.1 Khái quát

9.2 Thuộc tính ‘about’

...

9.4 Thẻ <dcterms:conformsTo>

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

9.6 Thẻ <scents>

9.7 Thẻ <grpItem>

9.8 Các xem xét an toàn

Phụ lục A (Tham khảo) Các tài nguyên trực tuyến về tệp tài nguyên và tệp tạo nhóm

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