Thẻ <target> có một định nghĩa vùng tên được gắn nhằm khai báo vùng tên cho mô tả đích, đó là http://openurc.org/ns/targetdesc-2 . Nó được khuyến cáo sử dụng định danh ‘td’ nếu nó không phải là vùng tên mặc định.

CHÚ THÍCH Không có nhãn hoặc thông tin về ngôn ngữ tự nhiên khác chứa trong <target>. <target> là một <anchor> nhằm gắn các mô tả phù thuộc ngôn ngữ mà được lưu trữ như các tài nguyên đích hoặc các tài nguyên bổ sung. Các tài nguyên (tham chiếu trong TD hoặc cung cấp bởi các dịch vụ tài nguyên bên ngoài) gắn liền với thẻ <target> có các vai trò cụ thể, bao gồm: nhãn, trợ giúp (các hạng mục trợ giúp tùy ý), khóa truy cập, từ khóa, vị trí. Tham khảo Phần 5 của bộ tiêu chuẩn này để biết thêm chi tiết về cách xác định các tài nguyên nguyên tử.

Phụ lục A trình bày một mô tả đích mẫu. Các điều sau đây mô tả các thuộc tính và các thẻ của <target>.

6.2  Thuộc tính ‘about’

Thẻ <target> phải có thuộc tính ‘about’ và giá trị của nó phải là Định danh tài nguyên thống nhất (URI), như đã quy định trong IETF RFC 3986.

Giá trị của thuộc tính ‘about’ phải là định danh duy nhất toàn cục (URI) của đích mà đang được mô tả trong mô tả đích. URI có thể hoặc không thể giải quyết được.

CHÚ THÍCH 1 Các nhà sản xuất đích được khuyến khích tạo các mô tả đích của các sản phẩm của họ một cách công khai, sẵn có bằng cách gửi mô tả đích tại tên URI của đích.

CHÚ THÍCH 2 URI của đích được cung cấp bởi nhà sản xuất đích. Điển hình, cùng một URI được sử dụng cho lớp các đích giống nhau (các sản phẩm), không chú ý đến đối tượng và vị trí cụ thể của chúng.

6.3  Thuộc tính ‘id’

...

...

...

CHÚ THÍCH 1 Các thuộc tính ‘about’ và ‘id’ được sử dụng để gắn các tài nguyên với thẻ <target>.

CHÚ THÍCH 2 Tài nguyên nguyên tử có thể được sử dụng để cung cấp mô tả vị trí cho đích (xem TCVN 11523-5 (ISO/IEC 24752-5))

6.4  Thuộc tính ‘hidden’

Thẻ <target> có thể có thuộc tính ‘hidden’ và giá trị của nó phải là Boolean (tức là “true’ hoặc “false’). Giá trị mặc định phải là “false”.

Giá trị “true” là một gợi ý cho URC rằng đích này không nên đưa ra cho người sử dụng. Tuy nhiên, nó sẵn có cho người sử dụng nếu được tham chiếu rõ ràng, ví dụ khi đích khác chuyển tiếp URC cho đích ẩn.

Người sử dụng có thể không cần biết về quá trình khám phá các đích và các socket. Các đích ẩn không được cho rằng hiện hữu với người sử dụng trừ khi người sử dụng yêu cầu được thấy chúng. Tuy nhiên, các đích ẩn có thể vẫn được truy cập bởi URC, ví dụ khi socket khác chuyển tiếp URC đến đích ẩn.

Ngoài ra, trong quá trình khám phá, trạng thái ‘hidden’ của đích có thể được cung cấp bởi mạng trực thuộc theo kiểu phụ thuộc cài đặt. Mục đích là làm giảm bớt gánh nặng cho các URC với việc lấy lại và phân tách TD của đích ‘hidden’ mà nó không quan tâm.

CHÚ THÍCH Thuộc tính ‘hidden’ có thể được quy định trên mức đích và socket. Socket kế thừa việc thiết lập từ đích. Nếu quy định trên cả hai mức thì thuộc tính ‘hidden’ của socket sẽ ghi đè lên một thuộc tính của đích.

6.5  Thẻ <dcterms:conformsTo>

...

...

...

VÍ DỤ <dcterms:conformsTo>http://openurc.org/ns/targetdesc-2/isoiec24752-4-2013 </dcterms:conformsTo>

CHÚ THÍCH 1 Giá trị của thẻ <dcterms:conformsTo> có thể được sử dụng khi kiểm tra sự phù hợp của mô tả đích.

CHÚ THÍCH 2 Thẻ <dcterms:conformsTo> được lấy từ tập các thuật ngữ siêu dữ liệu Dublin Core.

6.6  Thẻ <dcterms:modified>

Thẻ <target> có thể có thẻ con <dcterms:modified>, cho biết TD được sửa đổi từ phiên bản gốc của nó, trong khi vẫn mang cùng một URI đích (xem điều 6.2). Nội dung của nó phải là kiểu xsd:date hoặc xsd:dateTime.

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

CHÚ THÍCH 1 Thẻ <dcterms:modified> được lấy tập các thuật ngữ siêu dữ liệu Dublin Core.

Mô tả đích nên giữ ổn định hết mức có thể. TD bị thay đổi phải được gán một URI mới (xem điều 6.2) hoặc một giá trị mới cho thẻ <dcterms:modified>.

CHÚ THÍCH 2 Cơ chế này hỗ trợ vùng nhớ đệm và làm giảm độ bền lâu của mô tả đích và các tài nguyên bổ sung.

...

...

...

Mọi thẻ và việc lọc thẻ từ tập các thuật ngữ siêu dữ liệu về sáng kiến siêu dữ liệu Dublin Core (DCMI) có thể được sử dụng để mô tả đích, nếu thích hợp (như đã quy định trong TCVN 7980 (ISO 15836)). Mỗi thẻ có thể xuất hiện nhiều lần như thẻ con của thẻ <target>. Cụ thể, các thuật ngữ DCMI sau đây có thể được gắn với một đích:

- <dc:identifier> quy định mã sản phẩm (hoặc mã đối tượng) của đích;

- <dc:creator> quy định nhà sản xuất đích;

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

-<dc:contributor> quy định nhà cùng sản xuất đích;

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

VÍ DỤ Định danh theo lược đồ định danh cụ thể:

<dc:identifier xsi:type=“myComp:companyCode”>0123456</dc:identifier>

6.8  Thẻ <locator>

...

...

...

Thẻ <target> có thể có một hoặc nhiều thẻ con <locator>, mỗi thẻ con chứa thông tin định vị chức năng (trình diễn bởi URC). Mục đích là để người sử dụng kích hoạt chức năng trên đích nhằm giúp họ định vị đích.

VÍ DỤ Các ví dụ bao gồm các chức năng nghe như tiếng chuông hay tiếng bíp, các chức năng nhìn như đèn flash và các chức năng chỉ hướng như là chức năng “ping hồng ngoại”.

<locator type=“audio” id=“audio-locator”/>

<locator type=“visual” id=“visual-locator”/>

<locator type=“other” id=“irping-locator”/>

CHÚ THÍCH Không có ngôn ngữ tự nhiên nào chứa trong <locator>. Thẻ này là “anchor” cho việc gắn các mô tả độc lập ngôn ngữ mà được lưu trữ như các tài nguyên đích hoặc tài nguyên bổ sung.

6.8.2  Thuộc tính ‘type’

Thuộc tính ‘type’ phải có mặt trong mỗi thẻ <locator> và giá trị của nó phải là “audio”, “visual” hoặc “other”.

Ý nghĩa của giá trị kiểu phải như sau:

...

...

...

- “visual”: bộ định vị trực quan, tức là đích bỏ qua tín hiệu trực quan (như là đèn flash) khi được gọi ra từ URC;

- “other”: Phương tiện khác đối với việc định vị đích, ví dụ: mạch IR.

CHÚ THÍCH Đối với kiểu “other”, nhiều thông tin cụ thể hơn có thể được cung cấp thông qua thẻ con <extension> (xem điều 6.8.5).

6.8.3  Thuộc tính ‘id’

Thẻ <locator> phải có thuộc tính ‘id’ là duy nhất trong số tất các các thuộc tính ‘id’ trong mô tả đích. Nó được sử dụng để gắn các tài nguyên cho thẻ <locator> và để định danh chức năng của bộ định vị cụ thể khi được gọi ra trên đích bởi URC.

6.8.4  Thông tin ánh xạ về nền tảng

Thẻ <locator> có thể có một hoặc nhiều thẻ con <mapping> bao gồm thông tin ánh xạ về nền tảng.

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

Thẻ <mapping> có thể có nội dung thẻ và các thẻ con bất kỳ. Tuy nhiên, các thẻ con từ các vùng tên khác với vùng tên “http://openurc.org/ns/targetdesc-2”.

...

...

...

CHÚ THÍCH 2 Nhà cung cấp và nhà vận tải nền tảng bị ngăn sử dụng thẻ <mapping> để gắn nội dung hoạt động hoặc có thể thực thi được trong mô tả đích. Điều này đưa ra một rủi ro an toàn cho các thành phần phân tích mô tả đích và thực hiện nội dung.

6.8.5  Thẻ <extension>

Thẻ <locator> có thể có một hoặc nhiều thẻ con <extension> với mỗi thẻ con là một bộ chứa cho các thẻ mở rộng về nhà cung cấp từ mọi vùng tên khác với vùng tên “http://openurc.org/ns/targetdesc-2”. Tiêu chuẩn này không xác định việc xử lý các thẻ này.

CHÚ THÍCH 1 Bằng cách giới hạn các phần mở rộng về nhà cung cấp cho các thẻ đã quy định, các mô tả đích có thể được kiểm tra tính hợp lệ dựa vào định nghĩa lược đồ XML (xem Phụ lục A).

CHÚ THÍCH 2 Nhà cung cấp và nhà vận tải nền tảng bị ngăn sử dụng thẻ <extension> để gắn nội dung hoạt động hoặc có thể thực thi được trong mô tả đích. Điều này đưa ra một rủi ro an toàn cho các thành phần phân tích mô tả đích và thực hiện nội dung.

6.9  Thẻ <resSheet>

6.9.1  Khái quát

Thẻ <target> có thể có một số thẻ con <resSheet>, mỗi thẻ con đưa ra một tham chiếu tới tệp tài nguyên cung cấp bởi nhà sản xuất đích và luôn sẵn có trong mạng cục bộ.

CHÚ THÍCH 1 Các tệp tài nguyên là tập hợp các tài nguyên nguyên tử, như đã xác định trong Phần 5 của bộ tiêu chuẩn này.

...

...

...

VÍ DỤ

CHÚ THÍCH 2 Thẻ <resSheet> đưa ra khả năng cho nhà sản xuất đích nhằm cung cấp các tệp tài nguyên “default” trong mạng cục bộ. Các tệp tài nguyên khác - mà phù hợp cho các ngữ cảnh sử dụng cụ thể hơn - có thể được lấy ra từ máy chủ tài nguyên (xem điều 6.12) được cung cấp bởi nhà sản xuất đích hoặc các bên thứ ba.

6.9.2  Thuộc tính ‘about’

Thẻ <resSheet> phải 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 Thuộc tính ‘about’ tương ứng với thuộc tính ‘about’ trên thẻ <resSheet> trong tệp tài nguyên (xem TCVN 11523-5 (ISO/IEC 24752-5)), bất chấp vùng tên khác nhau.

CHÚ THÍCH 2 URI cung cấp bởi thuộc tính ‘about’ có thể hoặc không thể giải quyết được. Trong mọi trường hợp, sử dụng URI được cung cấp bởi <retrieveFrom>(xem điều 6.9.6) về việc lấy lại tệp tài nguyên.

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 phần tử siêu dữ liệu Dublin Core, http://purl.org/dc/elements/1.1/identifier.

6.9.3  Thẻ <dcterms:conformsTo>

...

...

...

VÍ DỤ Mã sau đây quy định rằng tệp tài nguyên tuân theo Phần 5 của bộ tiêu chuẩn này:

<dcterms:conformsTo>http://openurc.org/isolec24752-5/2013<dcterms:conformsTo/>

CHÚ THÍCH 1 Thẻ <dcterms:conformsTo> tương ứng với thẻ <dcterms:conformsTo> như các 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 kiểm tra sự phù hợp của tệp tài nguyên.

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

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

Thẻ <resSheet> 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à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:contributor>

- <dc:rights>

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

6.9.5  Thẻ <scents>

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ự có mặt 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.

Các thẻ scent thích hợp là các thẻ con của thẻ <scents> thuộc <resSheet> trong tệp tài nguyên, với các giá trị phù hợp được đưa ra như nội dung thẻ (TCVN 11523-5 (ISO/IEC 24752-5)). Tuy nhiên, các thẻ con của vùng tên http://openurc.org/ns/rsheet-2 được nhập vào vùng tên “http://openurc.org/ns/targetdesc-2” . Các thẻ con của các vùng tên khác vẫn giữ vùng tên gốc của chúng.

Các thẻ scent thích hợp bao gồm:

- <dc:type>

...

...

...

- <forDomain> (namespace “http://openurc.org/ns/targetdesc-2”)

- <forLang> (namespace “http://openurc.org/ns/targetdesc-2”)

- <dcterms:audience>

- <role> (of namespace “http://openurc.org/ns/targetdesc-2”)

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

6.9.6  Thẻ <retrieveFrom>

Thẻ <resSheet> phải có một hoặc nhiều thẻ con <retrieveFrom>.

Mỗi thẻ <retrieveFrom> quy định URI (như đã quy định trong IETF RFC 3986) được đưa ra như nội dung thẻ mà có thể được sử dụng để lấy lại bản sao tệp tài nguyên tham chiếu từ máy chỉ trong môi trường mạng cục bộ hoặc toàn cục.

Nếu nhiều thẻ <retrieveFrom> được đưa ra thì thứ tự của các thẻ là quan trọng trong việc lấy lại tệp tài nguyên. Tại thời gian chạy, các URI sẽ được thử theo thứ tự của các thẻ <retrieveFrom> và sau khi URI lấy lại thành công một tài liệu thì các URI còn lại sẽ bị bỏ qua.

...

...

...

Mỗi URI là đơn vị tương đối, nếu vậy nó được dựa trên URI mà được cung cấp bởi đích theo cách đặc trưng cho nền tảng hoặc dựa trên URI của tài liệu bao hàm.

CHÚ THÍCH 2 Khi được sử dụng trong mô tả đích (TD), các URI tương đối giúp cho TD không bị phụ thuộc vào một nền tảng cụ thể và cơ chế giao vận nào trong việc lấy lại các tài liệu. Chỉ có phần mà phải đặc trưng cho nền tảng mới là cơ chế tìm nạp (URI) cho TD.

6.10  Thẻ <grpSheet>

6.10.1  Khái quát

Thẻ <target> có thể có một số thẻ con <grpSheet>, mỗi thẻ con đưa ra một tham chiếu cho tệp tạo nhóm cung cấp bởi nhà sản xuất đích và sẵn có trong mạng cục bộ.

CHÚ THÍCH 1 Tệp tạo nhóm là tập hợp của các tài nguyên tạo nhóm, như đã xác định trong phần 5 của bộ tiêu chuẩn này.

VÍ DỤ

CHÚ THÍCH 2 Thẻ <grpSheet> đưa ra khả năng cho nhà sản xuất đích nhằm cung cấp các tệp tạo nhóm “default” trong mạng cục bộ. Các tệp tạo nhóm khác - mà phù hợp cho các ngữ cảnh sử dụng cụ thể hơn - có thể được lấy ra từ máy chủ tài nguyên (xem điều 6.12) được cung cấp bởi nhà sản xuất đích hoặc các bên thứ ba.

...

...

...

Thẻ <grpSheet> phải 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 Thuộc tính ‘about’ tương ứng với thuộc tính ‘about’ trên thẻ <grpSheet> trong tệp tạo nhóm (xem TCVN 11523-5 (ISO/IEC 24752-5)), bất chấp vùng tên khác nhau.

CHÚ THÍCH 2 URI cung cấp bởi thuộc tính ‘about’ có thể hoặc không thể giải quyết được. Trong mọi trường hợp, sử dụng URI được cung cấp bởi <retrieveFrom>(xem điều 6.9.6) về việc lấy lại tệp tạo nhóm.

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 phần tử siêu dữ liệu Dublin Core, http://purl.org/dc/elements/1.1/identifier.

6.10.3  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 đến chuẩn đã thiết lập mà tệp tạo nhóm và nội dung của nó (các nhóm) phù hợp với. 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ẻ.

VI DỤ Mã sau đây quy định rằng tệp tạo nhóm tuân theo Phần 5 của bộ tiêu chuẩn này: <dcterms:conformsTo>http://openurc.org/ns/gsheet-2/isoiec24752-5/2013<dcterms:conformsTo/>

CHÚ THÍCH 1 Thẻ <dcterms:conformsTo> tương ứng với thẻ <dcterms:conformsTo> như các thẻ con của <ResSheet> trong tệp tạo nhóm (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 kiểm tra sự phù hợp của tệp tạo nhóm.

...

...

...

6.10.4  Các đặc tính tệp tạo nhóm khác 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.

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>

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

6.10.5  Thẻ <scents>

...

...

...

Nếu hiện diện, thẻ <scents> có thể có một số thẻ con, cung cấp các gợi ý mà tệp tạo nhóm chứa. Sự có mặt 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 nhóm nguyên tử trong tệp tạo nhóm. 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.

Các thẻ scent thích hợp là các thẻ con của thẻ <scents> thuộc <resSheet> trong tệp tạo nhóm, với các giá trị phù hợp được đưa ra như nội dung thẻ (TCVN 11523-5 (ISO/IEC 24752-5)). Tuy nhiên, các thẻ con của vùng tên http://openurc.org/ns/gsheet-2 được nhập vào vùng tên “http://openurc.org/ns/targetdesc-2”. Các thẻ con của các vùng tên khác vẫn giữ vùng tên gốc của chúng.

Các thẻ scent thích hợp bao gồm:

- <forDomain> (namespace “http://openurc.org/ns/targetdesc-2”)

- <forLang> (namespace “http://openurc.org/ns/targetdesc-2”)

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

6.10.6  Thẻ <retrieveFrom>

Thẻ <grpSheet> phải có một hoặc nhiều thẻ con <retrieveFrom>.

Mỗi thẻ <retrieveFrom> quy định URI (như đã quy định trong IETF RFC 3986) được đưa ra như nội dung thẻ mà có thể được sử dụng để lấy lại bản sao tệp tài nguyên tham chiếu từ máy chỉ trong môi trường mạng cục bộ hoặc toàn cục.

...

...

...

CHÚ THÍCH 1 Nhà cung cấp/phân tích đích có thể chọn xem liệu họ muốn đáp ứng các tệp tạo nhóm từ máy chủ cục bộ hoặc toàn cục hay không. Đáp ứng cục bộ có lợi thế độc lập với kết nối internet. Đáp ứng toàn cục thường liên quan đến máy chủ Web dành riêng cho các sản phẩm của nhà cung cấp mà có thể được cập nhật dễ dàng. Nó được khuyến cáo nhằm cung cấp cả URI toàn cục (cho các cập nhật mới nhất) lẫn URI cục bộ (như một dự trữ cho các tình huống ngoại tuyến).

Mỗi URI là đơn vị tương đối, nếu vậy nó được dựa trên URI mà được cung cấp một cách rõ ràng bởi đích theo nền tảng cụ thể hoặc dựa trên URI của tài liệu bao hàm.

CHÚ THÍCH 2 Khi được sử dụng trong mô tả đích (TD), các URI tương đối giúp cho TD không bị phụ thuộc vào một nền tảng cụ thể và cơ chế giao vận nào trong việc việc lấy lại các tài liệu. Chỉ có cơ chế tìm nạp (URI) cho TD là phải có một nền tảng cụ thể

6.11  Thẻ <uiid>

6.11.1  Khái quát

Thẻ <target> có thể có một số thẻ con <uiid>, mỗi thẻ con đưa ra một tham chiếu cho mô tả cài đặt giao diện người sử dụng (UIID) cung cấp bởi nhà sản xuất đích và sẵn có trong mạng cục bộ.

CHÚ THÍCH 1 UIIDs là các đối tượng của dải rộng các định dạng tệp, một số trong chúng có thể là độc quyền.

UIID tham chiếu theo cách này có thể gắn với một hoặc nhiều socket của đích.

VÍ DỤ

...

...

...

CHÚ THÍCH 2 Thẻ <uiid> đưa ra khả năng cho nhà sản xuất đích nhằm cung cấp các UIID “default” trong mạng cục bộ. Các UIID khác - mà phù hợp cho các ngữ cảnh sử dụng cụ thể hơn - có thể được lấy ra tử máy chủ tài nguyên (xem điều 6.12) được cung cấp bởi nhà sản xuất đích hoặc các bên thứ ba.

6.11.2  Thuộc tính ‘about’

Thẻ <uiid> phải 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.

CHÚ THÍCH 1 Thuộc tính ‘about’ tương ứng với định danh toàn cục duy nhất, được sử dụng bởi UIID. URI này có thể hoặc không thể giải quyết được. Trong mọi trường hợp, sử dụng URI được cung cấp bởi <retrieveFrom> (xem điều 6.11.6) để lấy lại UIID.

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

6.11.3  Thẻ <dcterms:conformsTo>

Thẻ <uiid> phải có một hoặc nhiều thẻ con <dcterms:conformsTo>, mỗi thẻ con quy chiếu đến chuẩn đã thiết lập mà tệp tạo nhóm và nội dung của nó (các nhóm) phù hợp. mỗi thẻ <dcterms:conformsTo> phải là URI (như đã quy định trong IETF RFC 3986) và 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 kiểm tra sự phù hợp của UIID.

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

...

...

...

Thẻ <uiid> có thể có một số thẻ con <forLang>.

Thẻ <forLang> quy định (như nội dung thẻ) ngữ cảnh ngôn ngữ mà UIID có thể gắn với. Các ngữ cảnh ngôn ngữ phải là các mã 3 chữ cái đối với thẻ <xml:lang> của XML 1.0. Thẻ <forLang> trống cho biết rằng UIID không phải là đặc trưng về ngôn ngữ.

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

CHÚ THÍCH Nếu các UIID được xác định theo cách độc lập với ngôn ngữ thì <forLang>en</forLang> sẽ được khuyến cáo.

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

Thẻ <uiid> 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à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:rights>

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

- <dcterms:audience>

6.11.6  Thẻ <retrieveFrom>

Thẻ <uiid> phải có một hoặc nhiều thẻ con <retrieveFrom>.

Mỗi thẻ <retrieveFrom> quy định URI (như đã quy định trong IETF RFC 3986) được đưa ra như nội dung thẻ mà có thể được sử dụng để lấy lại bản sao của UIID tham chiếu từ máy chủ trong môi trường mạng cục bộ hoặc toàn cục.

Nếu nhiều thẻ <retrieveFrom> được đưa ra thì thứ tự của chúng là quan trọng cho việc lấy lại UIID. Tại thời gian chạy, các URI sẽ được thử theo thứ tự của các thẻ <retrieve From> và sau khi URI lấy lại thành công một tài liệu và các URI còn lại sẽ bị bỏ qua.

CHÚ THÍCH 1 Nhà cung cấp/phân tích đích có thể chọn xem liệu họ muốn đáp ứng các UIID từ máy chủ cục bộ hoặc toàn cục hay không. Đáp ứng cục bộ có lợi thế độc lập với kết nối internet. Đáp ứng toàn cục thường liên quan đến máy chủ Web dành riêng cho các sản phẩm của nhà cung cấp mà có thể được cập nhật dễ dàng. Nó được khuyến cáo nhằm cung cấp cả URI toàn cục (cho các cập nhật mới nhất) lẫn URI cục bộ (như một dự trữ cho các tình huống ngoại tuyến).

Mỗi URI là đơn vị tương đối, nếu vậy nó được dựa trên URI mà được cung cấp bởi đích theo cách đặc trưng cho nền tảng hoặc dựa trên URI của tài liệu bao hàm.

...

...

...

6.12  Thẻ <resSvc>

6.12.1  Khái quát

Thẻ <target> có thể có một số thẻ con <resSvc>, mỗi thẻ con đưa ra một tham chiếu đến dịch vụ tài nguyên mà có thể được truy vấn cho mọi kiểu tài nguyên, bao gồm:

- các tài nguyên nguyên tử như là: các nhãn, các văn bản trợ giúp, các từ khóa và các khóa truy cập (như đã xác định bởi phần 5 của bộ tiêu chuẩn này);

- các tài nguyên tạo nhóm (như đã xác định bởi phần 5 của bộ tiêu chuẩn này);

- các UIID (định dạng không được quy định bởi tiêu chuẩn này).

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

VÍ DỤ Đoạn mã sau đây là một 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ả giao diện HTTP máy chủ tài nguyên 1.0 của OpenURC (như đã quy định tại http://openurc.org/TR/res-servhttp1.0) và mô tả giao diện của nó tại http://res.openurc.org

...

...

...

6.12.2  Thuộc tính ‘about’

Thẻ <resSvc> phải có 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.

URI này có thể giải quyết được một cách toàn cục và phải phân phối tập mô tả cho dịch vụ tài nguyên.

Định dạng của tệp mô tả bên ngoài cho dịch vụ tài nguyên không thuộc phạm vi của tiêu chuẩn này. Nếu tồn tại, các định dạng mô tả giao diện có thể được sử dụng như đã xác định ở các tiêu chuẩn khác. Nếu được chuẩn hóa, thẻ <dcterms:conformTo> và/hoặc kiểu MINME và/hoặc phần mở rộng tệp của tệp mô tả dịch vụ tài nguyên có thể tạo ra định dạng của nó

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

6.12.3  Thẻ <dcterms:conformsTo>

Thẻ <resSvc> có thể có một thẻ con <dcterms:conformsTo>, quy định tham chiếu (URI. như đã quy định trong IETF RFC 3986) đến chuẩn đã thiết lập mà dịch vụ tại nguyên phù hợp. URI phải được cung cấp như nội dung thẻ.

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

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

...

...

...

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

- <dc:publisher>

- <dc:rights>

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

- <dcterms:audience>

6.13  Thẻ <socket>

6.13.1  Khái quát

Thẻ <target> phải có một hoặc nhiều thẻ con <socket>. Thẻ <socket> quy định socket của đích. Socket cung cấp truy cập đến đơn vị chức năng của đích mà khác biệt với các socket khác của cùng đích, liên quan đến chức năng của nó. Các ví dụ bao gồm một kết hợp máy điện thoại máy fax là đích, bao gồm một máy điện thoại và một máy fax là các socket riêng biệt. Tham khảo phần 2 của bộ tiêu chuẩn này về đặc tả của socket.

Nhìn chung, socket kế thừa các đặc tính của đích. Nếu quy định trên các mức đích và socket thì đặc tính của socket sẽ ghi đè lên đặc tính của đích.

...

...

...

VÍ DỤ Socket đơn cho một ATM.

CHÚ THÍCH Không có thông tin về ngôn ngữ tự nhiên nào chứa trong <socket>. Thẻ này chỉ là “anchor” nhằm gắn các mô tả phụ thuộc vào ngôn ngữ được lưu trữ như các tài nguyên đích hoặc các tài nguyên bổ sung.

6.13.2  Thuộc tính ‘id’

Thẻ <socket> phải có thuộc tính ‘id’ và giá trị của nó phải một chuỗi duy nhất trong số tất cả các thuộc tính ‘id’ trong mô tả đích.

CHÚ THÍCH Điều này là cần thiết để quy định các tài nguyên cho thẻ <socket>.

6.13.3  Thuộc tính ‘name’

Thẻ <socket> phải có thuộc tính ‘name’, quy định URI (xem IETF RFC 3986) mà định danh socket một cách toàn cục. URI không được chứa một định danh đoạn.

URI có thể hoặc không thể giải quyết được. Nó được khuyến cáo dẫn xuất URI này từ URI của đích bằng cách ghép nối với nhau, ví dụ http://example.com/target/socket nếu URI của đích là http://example.com/target.

...

...

...

6.13.4  Thuộc tính ‘type’

Thẻ <socket> có thể có thuộc tính ‘type’. Các giá trị cho phép là “location-dependent’’(mặc định), “location-informative” và “location-free”.

Ý nghĩa của giá trị kiểu như sau :

- “location-dependent”: các socket của vị trí phụ thuộc có vị trí xác định và yêu cầu người sử xem xét kỹ lưỡng đích và socket của nó;

- “location-informative” các socket của vị trí có thông tin 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” : các socket của vị trí tự do không có vị trí quan trọng, tức là chúng tồn tại trong không gian ảo.

VÍ DỤ 1 ATM là vị trí location-dependent.

VÍ DỤ 2 Hệ thống an toàn trong nhà là location-informative.

VÍ DỤ 3 Socket của thông tin tỷ giá tiền tệ là location-free.

...

...

...

Thẻ <socket> có thể có thuộc tính ‘hidden’, quy định liệu socket có được đưa ra cho người sử dụng của URC khi được khám phá bởi URC hay không. Giá trị mặc định phải là “false”.

Giá trị “true” là một gợi ý cho URC rằng đích này không nên được đưa ra cho người sử dụng. Tuy nhiên, nó sẵn có cho người sử dụng nếu được tham chiếu rõ ràng, ví dụ khi đích khác chuyển tiếp URC cho đích ẩn.

Cú pháp và ý nghĩa của thuộc tính ‘hidden’ cho socket là giống với thẻ <target> (xem điều 6.4).

Thuộc tính ‘hidden’ có thể được quy định trên mức đích và socket. Socket kế thừa việc thiết lập từ đích. Nếu quy định trên cả hai mức thì thuộc tính ‘hidden’ của socket sẽ ghi đè lên một thuộc tính của đích.

6.13.6  Thuộc tính ‘maxSessions’

Thẻ <socket> có thể có thuộc tính ‘maxSessions’, cung cấp một gợi ý để biết được có bao nhiêu phiên mà socket của đích có thể duy trì cùng một lúc. Con số này chỉ là một gợi ý bởi đích theo sự hiểu biết đáng tin cậy nhất của nó trước thời gian chạy và cách vận hành thực tế có thể thay đổi.

Giá trị của ‘maxSessions’ phải là số nguyên lớn hơn hoặc bằng “1”. Không có giá trị mặc định cho ‘maxSessions’. Giá trị “unbounded” cho biết đích đề cấp đến nhiều hơn một phiên đồng thời nhưng không thể cung cấp giới hạn cực đại chính xác. Nếu thuộc tính ‘maxSessions’ không có mặt thì không sẵn có có thông tin về số phiên tối đa.

CHÚ THÍCH Thuộc tính ‘maxSessions’ có thể cho phép URC đưa ra các dự đoán trước thời gian có thể giúp tăng tính khả dụng và tránh lưu lượng mạng không cần thiết. Ví dụ, nếu maxSessions =“1” và URC có một phiên mở với đích thì yêu cầu phiên mở thêm vào có thể sẽ thất bại.

6.13.7  Thuộc tính ‘sharedSessions’

...

...

...

Giá trị của ‘sharedSessions’ phải là Boolean, tức là “true” hoặc “false”, “true” có nghĩa là các phiên được chia sẻ. Giá trị mặc định của nó là “true”.

CHÚ THÍCH 1 Thuộc tính ‘sharedSessions’ ‘maxSessions’ có thể cho phép URC đưa ra các dự đoán trước thời gian có thể giúp tăng tính khả dụng và giảm lưu lượng mạng.

CHÚ THÍCH 2 Đôi khi, các đích và socket được gọi là “session-full (yêu cầu phiên)” hoặc “session-less (không yêu cầu phiên)”. Nếu một socket có sharedSessions = “true” thì nó là session-less. Nếu một socket có sharedSessions = “false” và maxSessions = “1” thì nó là session-less (nhưng cho phép cho một khách kết nối tại một thời điểm). Với các trường hợp khác thì socket là session-full.

6.13.8  Thuộc tính ‘requestable’

Thẻ <socket> có thể có thuộc tính ‘requestable’, cung cấp một gợi ý cho URC để biết được liệu nó có thể yêu cầu mở một phiên trực tiếp với socket của đích hoặc sau khi một phiên chuyển tiếp yêu cầu được khởi tạo bởi đích hay không (xem TCVN 11523-1 (ISO/IEC 24752-1)).

Giá trị của ‘requestable’ phải là Boolean, tức là “true” hoặc “false”. Giá trị “true” có nghĩa là URC có thể yêu cầu mở một phiên trực tiếp, “false” có nghĩa là URC chỉ có thể mở một phiên nếu đích khởi tạo yêu cầu chuyển tiếp phiên cho socket này. Giá trị mặc định là “true”.

CHÚ THÍCH 1 Các socket có thể được mở và chuyển tiếp trực tiếp nên được gán một giá trị ‘requestable’ là “true”.

CHÚ THÍCH 2 Thuộc tính ‘requestable’ có thể giúp tạo các URC khả dụng hơn bằng cách giấu kín người sử dụng các socket có thể được yêu cầu trực tiếp.

6.13.9  Thẻ <retrieveFrom>

...

...

...

Mỗi thẻ <retrieveFrom> quy định URI (xem IETF RFC 3986) như nội dung thẻ mà có thể được sử dụng để lấy lại tài liệu mô tả socket cho socket, từ máy chủ trong môi trường mạng cục bộ hoặc toàn cục.

VÍ DỤ <retrieveFrom>socket/socketdescription.xml</retrieveFrom>

Nếu nhiều thẻ <retrieveFrom> được đưa ra thì thứ tự của chúng là quan trọng cho việc lấy lại tệp tài nguyên. Tại thời gian chạy, các URI sẽ được thử theo thứ tự của các thẻ <retrieveFrom> và sau khi URI lấy lại thành công một tài liệu còn các URI còn lại sẽ bị bỏ qua.

CHÚ THÍCH 1 Nhà cung cấp/phân tích đích có thể chọn xem liệu họ muốn đáp ứng các mô tả socket từ máy chủ cục bộ hoặc toàn cục hay không. Đáp ứng cục bộ có lợi thế độc lập với kết nối internet. Đáp ứng toàn cục thưởng liên quan đến máy chủ Web dành riêng cho các sản phẩm của nhà cung cấp mà có thể được cập nhật dễ dàng. Nó được khuyến cáo nhằm cung cấp cả URI toàn cục (cho các cập nhật mới nhất) lẫn URI cục bộ (như một dự trữ cho các tình huống ngoại tuyến).

Mỗi URI là đơn vị tương đối, nếu vậy nó được dựa trên URI của mô tả đích (hoặc dựa trên URI cơ sở cung cấp bởi đích theo một số cách đặc trưng cho nền tảng).

CHÚ THÍCH 2 Khi được sử dụng trong mô tả đích (TD), các URI tương đối giúp cho TD không bị phụ thuộc vào một nền tảng cụ thể và cơ chế chế giao vận nào trong việc lấy lại các tài liệu. Chỉ có phần mà phải đặc trưng cho nền tảng mới là cơ chế tìm nạp (URI) cho TD.

CHÚ THÍCH 3 URC có thể yêu cầu mô tả socket trước khi nó mở một phiên với socket thích hợp, ví dụ để kiểm tra liệu socket có thể cầu chức năng mong muốn hay không. Tham khảo Phần 1 của bộ tiêu chuẩn này để biết thêm chi tiết về quản lý phiên.

6.13.10  Các đặc tính của socket từ DCMI

Mọi thẻ và việc lọc thẻ từ tập các thuật ngữ siêu dữ liệu về sáng kiến siêu dữ liệu Dublin Core (DCMI) có thể được sử dụng để mô tả đích, nếu thích hợp (xem TCVN 7980 (ISO 15836)). Mỗi thẻ có thẻ xuất hiện nhiều lần như thẻ con của thẻ <socket>. Cụ thể, các thuật ngữ DCMI sau đây có thể được gắn với một socket:

...

...

...

- <dc:publisher> quy định nhà cung cấp socket;

-<dc:contributor> quy định nhà cùng sản xuất socket;

- <dcterms:hasVersion> quy định tên của socket thay thế cho việc truy cập chức năng giống nhau hoặc tương tự nhau;

- <dcterms:isVersionOf> quy định tên của socket chính trong số tập các socket thay thế cho việc truy cập chức năng giống nhau hoặc tương tự nhau.

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

Nhìn chung, socket kế thừa các đặc tính của đích. Nếu quy định trên mức socket và đích thì đặc tính của socket sẽ ghi đè lên đặc tính của đích.

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

Thẻ <socket> có thể có một hoặc nhiều thẻ con <mapping> bao gồm thông tin ánh xạ về nền tảng cho socket.

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

...

...

...

CHÚ THÍCH 1 Các mô tả đích mà chứa thông tin ánh xạ về nền tảng sẽ mất tính trung lập của chúng. Mặc dù nhiều ánh xạ có thể được quy định trong mô tả đích (một ánh xạ cho mỗi nền tảng) nhưng nó được khuyến cáo xem xet các cơ chế khác về việc quy định sự liên kết với các công nghệ đặc trưng cho nền tảng. Ví dụ, thông tin ánh xạ có thể được cung cấp trong tệp bên ngoài với các tham chiếu tới các thẻ của mô tả đích.

CHÚ THÍCH 2 Nhà cung cấp và nhà vận tải nền tảng bị ngăn sử dụng thẻ <mapping> để gắn nội dung hoạt động hoặc có thể thực thi được trong mô tả đích. Điều này đưa ra một rủi ro an toàn cho các thành phần phân tích mô tả đích và thực hiện nội dung.

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

Thẻ <target> có thể có một hoặc nhiều thẻ con <mapping> bao gồm thông tin ánh xạ về nền tảng cho đích.

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

Thẻ <mapping> có thể có nội dung thẻ và các thẻ con bất kỳ. Tuy nhiên, các thẻ con từ các vùng tên khác với vùng tên “http://openurc.org/ns/targetdesc-2’’ .

CHÚ THÍCH 1 Các mô tả đích mà chứa thông tin ánh xạ về nền tảng sẽ mất tính trung lập của chúng. Mặc dù nhiều ánh xạ có thể được quy định trong mô tả đích (một ánh xạ cho mỗi nền tảng) nhưng nó được khuyến cáo xem xét các cơ chế khác về việc quy định sự liên kết với các công nghệ đặc trưng cho nền tảng. Ví dụ, thông tin ánh xạ có thể được cung cấp trong tệp bên ngoài với các tham chiếu tới các thẻ của mô tả đích.

CHÚ THÍCH 2 Nhà cung cấp và nhà vận tải nền tảng bị ngăn sử dụng thẻ <mapping> để gắn nội dung hoạt động hoặc có thể thực thi được trong mô tả đích. Điều này đưa ra một rủi ro an toàn cho các thành phần phân tích mô tả đích và thực hiện nội dung.

6.15  Các xem xét về an toàn và quyền riêng tư

...

...

...

Đối với các ứng dụng và các môi trường nơi mà các cơ chế an toàn và quyền riêng tư được cài đặt ở trên thì mức an toàn vận tải, các thẻ thêm vào trong mô tả đích có thể được đưa vào cho các nền tảng và các môi trường mạng cụ thể. Ví dụ, các thẻ con mới của <target> hoặc <socket> có thể được quy định trong các hướng dẫn về nối mạng. Tuy nhiên, các phần mở rộng này nên được giữ càng nhỏ càng tốt nhằm giảm thiểu phần phụ thuộc nền tảng của mô tả đích

CHÚ THÍCH Nhà cung cấp và nhà vận tải nền tảng bị ngăn sử dụng thẻ con mới để gắn nội dung hoạt động hoặc có thể thực hiện được trong mô tả đích. Điều này đưa ra một rủi ro an toàn cho các thành phần phân tích mô tả đích và thực thi nội dung.

Phụ lục A

(Tham khảo)

Các tài nguyên trực tuyến về mô tả đích

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

- Định nghĩa lược đồ XML cho các mô tả đích http://openurc.org/ns/targetdesc-2:

- Mô tả đích mẫu cho bộ ổn nhiệt số: http://openurc.org/TPL/basicthermostat-1/basic- thermostat.td

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

...

...

...

[2] TCVN 11523-6 (ISO/IEC 24752-6), Công nghệ thông tin - Giao diện người sử dụng - Bộ điều khiển từ xa phổ dụng - Phần 6: Tích hợp dịch vụ web

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

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

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

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

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

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

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

...

...

...

Lời nói đầu

Lời giới thiệu

1  Phạm vi áp dụng

2  Sự phù hợp

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

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

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

5.1  Liên quan đến XML

5.2  Kiểu MIME

...

...

...

6.1  Khái quát

6.2  Thuộc tính ‘about’

6.3  Thuộc tính ‘id’

6.4  Thuộc tính ‘hidden’

6.5  Thẻ <dcterms:conformsTo>

6.6  Thẻ <dcterms:modified>

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

6.8  Thẻ <locator>    

6.9  Thẻ <resSheet>

...

...

...

6.11  Thẻ <uiid>

6.12  Thẻ <resSvc>

6.13  Thẻ <socket>

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

6.15  Các xem xét về an toàn và quyền riêng tư

Phụ lục A (Tham khảo) Các tài nguyên trực tuyến về mô tả đích

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