It is inappropriate to cite this document as other than work in progress.
This is a draft document and may be updated, replaced or obsoleted by other documents atĪny time. Publication as a Working Draft does not imply endorsement by the W3C Membership. The Last Call period ends 13 December 2012. If you wish to make comments regarding this document, please send them subscribe, This document is intended to become a W3C Recommendation. This document was published by the Technical Architecture Group as a Last Call Working Draft. Of this technical report can be found in the W3C technical reports A list of current W3C publications and the latest revision Otherĭocuments may supersede this document. This section describes the status of this document at the time of its publication. Authors referring to URIs with fragids should avoid using fragids that are specific to a particular document format (such as XPointer, which is specific to XML) unless they can ascertain that the base URI only serves one representation. They should also ensure that scripts handle fragids consistently with the fragid rules for the relevant media type. Publishers should ensure that any addressable structures within documents that are served through content negotiation are consistent across content-negotiated variants. The designers of fragid structures (such as XPointer) should avoid syntactic overlaps with existing fragid structures and ensure that fragids can be used across formats with similar semantics. Further, they should specify that any fragids that do not resolve according to these rules should be handled in the way specified by the specific media type adopting that +suffix.
FRAGMENT DEFINITION REGISTRATION
The +suffix registration should define the same fragid rules as are used in that media type registration. Structured syntax suffix registrations are based on a metaformat which usually will have its own media type registration. They should avoid defining new fragid structures within the registration document itself, and should avoid constraining how applications handle fragids that do not resolve. Media type registrations should also reserve the use of plain name fragids for local identifiers within content, and specify any restrictions on the interpretation of fragids by scripts. Where media type registrations reuse fragid structures that overlap, media type registrations should specify which take priority in resolving a given fragid. If the "inherited" fragid syntaxes overlap and may provide inconsistent meanings or processing for the same fragid, they should not adopt the +suffix. Media type registrations should ensure that fragids matching syntax "inherited" from top-level types such as image/* and +suffix registrations such as for +xml are always interpreted based on that generic processing. This document recommends best practices for the authors of media type definitions, for the authors of structured syntax suffix registrations (such as +xml), for the authors of specifications that define fragid structures, and for authors that publish documents that are intended to be used with fragids or who refer to fragments within documents using URIs with fragids. Media type definitions therefore have to provide details about how fragids are interpreted for that media type. Best Practices for Fragment Identifiers and Media Type Definitions W3C Working Draft 25 October 2012 This version: Latest published version: Latest editor's draft: Previous version: Editor: Jeni Tennison, Open Data Instituteįragment identifiers ( fragids) within URIs are specified as being interpreted based on the media type of a representation.
0 kommentar(er)
