idnits 2.17.1 draft-amundsen-richardson-foster-alps-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 11 characters in excess of 72. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Since a state transition 'descriptor' may define a relation type value, it is important to avoid creating conflicts with existing IANA-registered values. If the resulting link relation type is the same as a registered relation type, the descriptor MUST not change the meaning of the IANA relation type. -- The document date (August 24, 2015) is 3168 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 26 == Missing Reference: 'TK' is mentioned on line 1224, but not defined ** Obsolete normative reference: RFC 1738 (Obsoleted by RFC 4248, RFC 4266) ** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303) ** Obsolete normative reference: RFC 4627 (Obsoleted by RFC 7158, RFC 7159) ** Obsolete normative reference: RFC 5988 (Obsoleted by RFC 8288) ** Downref: Normative reference to an Informational RFC: RFC 6906 ** Obsolete normative reference: RFC 7320 (Obsoleted by RFC 8820) == Outdated reference: A later version (-12) exists of draft-ietf-appsawg-text-markdown-05 Summary: 8 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Amundsen 3 Internet-Draft CA Technologies, Inc. 4 Expires: February 25, 2016 L. Richardson 6 M. Foster 8 August 24, 2015 10 Application-Level Profile Semantics (ALPS) 11 draft-amundsen-richardson-foster-alps-02 13 Abstract 15 This document describes ALPS, a data format for defining simple 16 descriptions of application-level semantics, similar in complexity to 17 HTML microformats. An ALPS document can be used as a profile to 18 explain the application semantics of a document with an application- 19 agnostic media type (such as HTML, HAL, Collection+JSON, Siren, 20 etc.). This increases the reusability of profile documents across 21 media types. 23 Editorial Note (To be removed by RFC Editor) 25 Distribution of this document is unlimited. Comments should be sent 26 to the IETF Media-Types mailing list (see [1]). 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on February 25, 2016. 45 Copyright Notice 47 Copyright (c) 2015 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 64 1.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4 65 1.2.1. Describing Domain-Specific Semantics . . . . . . . . 4 66 1.2.2. ALPS-based Server Implementations . . . . . . . . . . 4 67 1.2.3. ALPS-based Client Implementations . . . . . . . . . . 4 68 1.3. A Short Hike in the ALPS . . . . . . . . . . . . . . . . 5 69 1.4. A Simple ALPS Example . . . . . . . . . . . . . . . . . . 6 70 1.5. Identifying an ALPS Document . . . . . . . . . . . . . . 11 71 2. ALPS Documents . . . . . . . . . . . . . . . . . . . . . . . 11 72 2.1. Compliance . . . . . . . . . . . . . . . . . . . . . . . 12 73 2.2. ALPS Document Properties . . . . . . . . . . . . . . . . 12 74 2.2.1. 'alps' . . . . . . . . . . . . . . . . . . . . . . . 12 75 2.2.2. 'doc' . . . . . . . . . . . . . . . . . . . . . . . . 12 76 2.2.3. 'descriptor' . . . . . . . . . . . . . . . . . . . . 13 77 2.2.4. 'ext' . . . . . . . . . . . . . . . . . . . . . . . . 14 78 2.2.5. 'format' . . . . . . . . . . . . . . . . . . . . . . 15 79 2.2.6. 'href' . . . . . . . . . . . . . . . . . . . . . . . 16 80 2.2.7. 'id' . . . . . . . . . . . . . . . . . . . . . . . . 16 81 2.2.8. 'link' . . . . . . . . . . . . . . . . . . . . . . . 18 82 2.2.9. 'name' . . . . . . . . . . . . . . . . . . . . . . . 18 83 2.2.10. 'rel' . . . . . . . . . . . . . . . . . . . . . . . . 19 84 2.2.11. 'rt' . . . . . . . . . . . . . . . . . . . . . . . . 19 85 2.2.12. 'type' . . . . . . . . . . . . . . . . . . . . . . . 19 86 2.2.13. 'value' . . . . . . . . . . . . . . . . . . . . . . . 20 87 2.2.14. 'version' . . . . . . . . . . . . . . . . . . . . . . 20 88 2.3. ALPS Representations . . . . . . . . . . . . . . . . . . 20 89 2.3.1. Sample HTML . . . . . . . . . . . . . . . . . . . . . 20 90 2.3.2. XML Representation Example . . . . . . . . . . . . . 21 91 2.3.3. JSON Representation Example . . . . . . . . . . . . . 21 92 3. Applying ALPS documents to Existing Media Types . . . . . . . 23 93 3.1. Linking to ALPS Documents . . . . . . . . . . . . . . . . 24 94 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 95 4.1. application/alps+xml . . . . . . . . . . . . . . . . . . 24 96 4.2. application/alps+json . . . . . . . . . . . . . . . . . . 26 97 5. Internationalization Considerations . . . . . . . . . . . . . 27 98 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 99 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 100 7.1. Normative References . . . . . . . . . . . . . . . . . . 27 101 7.2. Informative References . . . . . . . . . . . . . . . . . 28 102 Appendix A. Frequently Asked Questions . . . . . . . . . . . . . 29 103 A.1. Why are there no URLs in ALPS? . . . . . . . . . . . . . 29 104 A.2. Why is there no workflow component in the ALPS 105 specification? . . . . . . . . . . . . . . . . . . . . . 29 106 A.3. Why is there no way to indicate ranges for semantic 107 descriptors? . . . . . . . . . . . . . . . . . . . . . . 29 109 1. Introduction 111 This document describes ALPS, a media type for defining simple 112 descriptions of application-level semantics, similar in complexity to 113 HTML microformats. These descriptions contain both human-readable 114 and machine-readable explanations of the semantics. An ALPS document 115 can be used as a profile to explain the application semantics of a 116 document with an application-agnostic media type (such as HTML, HAL, 117 Collection+JSON, Siren. etc.). 119 This document identifies a registry for ALPS documents, (The ALPS 120 Profile Registry or APR). The details of this registry, its goals, 121 and operations are covered in a separate document (TBD). 123 This document also identifies a process for authoring, publishing, 124 and sharing normative human-readable instructions on applying an ALPS 125 document as a profile to responses of a given media type. For 126 example, a document that describes how to apply the semantics of an 127 ALPS profile to an HTML document. 129 This document registers two media-type identifiers with the IANA: 130 'application/alps+xml' ('ALPS+XML') and 'application/alps+json' 131 ('ALPS+JSON'). 133 1.1. Notational Conventions 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in[RFC2119]. 139 1.2. Motivation 141 When implementing a hypermedia client/server application using a 142 general media type (HTML, Atom, Collection+JSON, etc.), client and 143 server instances need to share an understanding of domain-specific 144 information such as data element names, link relation values, and 145 state transfer parameters. This information is directly related to 146 the application being implemented (e.g. accounting, contact 147 management, etc.) rather than the media type used in the 148 representations. 150 1.2.1. Describing Domain-Specific Semantics 152 Instead of creating and registering an entirely new media type (i.e. 153 'application/accounting'), representation authors can create an ALPS 154 document that describes a 'profile' of the target domain; one that 155 explains the vital domain-specific semantic descriptors and state 156 transitions. This profile can then be consistently applied to a wide 157 range of media types by server implementors and successfully consumed 158 by client applications. The focus on defining application-level 159 semantics, independent of transfer protocol or media type, makes it 160 possible to serve application-specific representations using an 161 application-agnostic media type. 163 1.2.2. ALPS-based Server Implementations 165 Server implementors can use ALPS documents as a basis for building 166 domain-specific solutions without having to create their own custom 167 media type or re-invent the vocabulary and transition set for a 168 common domain (e.g. accounting, microblogging, etc.). Using a 169 preexisting ALPS profile as a guide, servers can map internal data to 170 commonly-understood semantic descriptors and state transitions, 171 increasing the likelihood that existing client applications (those 172 who share the same understanding of the ALPS document) will be able 173 to successfully interact with that server. 175 1.2.3. ALPS-based Client Implementations 177 Armed with a document's ALPS profile, client applications can 178 associate the ALPS descriptor 'id' and/or 'name' attribute values 179 with the appropriate elements within the document. Client 180 applications can 'code for the profile' and better adjust to detailed 181 changes to the response layout, or even the wholesale replacement of 182 one media type with another. 184 1.3. A Short Hike in the ALPS 186 ALPS documents allow you to express domain semantics independent of 187 message media type and/or protocol. ALPS documents specify 188 'descriptor' elements that define domain-specific semantic 189 information. Each 'descriptor' has an 'id' property that defines a 190 domain-specific name and a 'type' property that indicates whether the 191 information being described is a simple data element (type="semantic) 192 or a state transition element (type="safe", type="unsafe", 193 type="idempontent"). By combining multiple data and transition 194 descriptors in a single document, ALPS authors are able to 195 sufficently describe all the related data and action semantics in an 196 application domain. 198 Take the following example ALPS profile located at: 199 http://example.com/alps/works 201 202 203 The content of a work. 204 205 206 Release a work for distribution. 207 208 210 Sample Works Domain ALPS Document 212 For an 'application/json' message, this would map to: 214 GET /works/1 HTTP/1.1 215 Host: example.io 216 Links: profile="http://example.com/alps/works" 217 Content-Type: application/json 219 { 220 "content" : "The ships hung in the sky in much the same way that bricks don't." 221 } 223 Sample Works JSON Message 225 For an 'application/vnd.siren+json' message, this would map to: 227 GET /works/1 HTTP/1.1 228 Host: example.io 229 Links: profile="http://example.com/alps/works" 230 Content-Type: application/vnd.siren+json 232 { 233 "properties" { 234 "content" : "The ships hung in the sky in much the same way that bricks don't." 235 }, 236 "actions" : { 237 "name" : "publish", 238 "method" : "PUT", 239 "href" : "..." 240 } 241 } 243 Sample Works Siren Message 245 While an ALPS document defines an entire set of domain-specific 246 information, not all media types can completely represent this 247 information. For example, plain JSON (application/json) has no 248 standardized definition of hypermedia links or forms. Thus, in the 249 above example, the 'publish' descriptor has no corresponding element 250 in the JSON representation. However, the Siren media type has an 251 'action' hypermedia element that can be used to express the details 252 of the 'publish' state transition. 254 This illustrates a key principle of the ALPS format. ALPS documents 255 define the domain semantics in the abstract and the mapping of these 256 details to a message is defined separately through a standardized set 257 of ALPS-to-[media type] mapping documents (See 258 Applying ALPS documents to Existing Media Types). 260 1.4. A Simple ALPS Example 262 Below is an ALPS document that describes elements of a simple 263 request/response interaction in a contact management application. 264 The profile defines a semantic descriptor called 'contact', and three 265 subordinate descriptors ('fullName', 'email', and 'phone'). 267 The ALPS document also defines a single, safe state transition, to be 268 represented by a hypermedia control (e.g. HTML.GET form) with the 269 'id' value of 'collection.' This hypermedia control has one input 270 value ('nameSearch'). When executed, the response will contain one 271 or more 'contact' type items. 273 274 A contact list. 275 277 278 279 280 A simple link/form for getting a list of contacts. 281 282 283 Input for a search form. 284 285 287 288 289 290 A link to an individual contact. 291 292 293 294 295 296 298 ALPS Contact Profile document 300 Implementing the ALPS profile above requires implementing the 301 descriptors defined by the ALPS document. In this case, there are 302 two 'top level' descriptors: the safe state transition ('collection') 303 and the semantic descriptor 'contact'. Below is a single HTML 304 document that shows both these elements in a representation. 306 307 308 310 312 314 315 316
319 320 321 322
324 325 326 332 335 338 340 341 347 350 353 354
327 329 Ann Arbuckle 330 331 333 334 336 123.456.7890 337
342 344 Zelda Zackney 345 346 348 349 351 098.765.4321 352
355 356 358 HTML ALPS Contact Representation 360 HTML representations implement most ALPS elements using HTML's 361 'class' attribute. The 'collection' ID has become the CSS class of 362 an HTML form's submit button. The 'contact' ID has become the CSS 363 class of the TR elements in an HTML table. The subordinate 364 descriptors 'fullname','email', and 'phone' are rendered as the TD 365 elements of each TR. 367 This HAL document uses the same profile to express the same 368 application-level semantics as the HTML document. 370 371 373 375 378 379 381 Ann Arbuckle 382 aa@example.org 383 123.456.7890 384 385 386 388 Zelda Zackney 389 zz@example.org 390 987.664.3210 391 392 394 HAL XML Contacts Representation 396 In a HAL representation, all state transitions ('collection' and 397 'item', in this case) are represented as link relations. All data 398 descriptors ('fullName', 'email', and 'phone') are represented as XML 399 tags named after the descriptors. 401 This Collection+JSON document uses the ALPS profile to express the 402 same application-level semantics as the HTML and HAL documents. 404 { 405 "collection" : { 406 "version" : "1.0", 407 "href" : "http://example.org/contacts/", 409 "links" : [ 410 { 411 "rel" : "profile", 412 "href" : "http://alps.io/profiles/contacts" 413 }, 414 { 415 "rel" : "help", 416 "href" : "http://example.org/help/contacts.html" 417 }, 418 { 419 "rel" : "type", 420 "href" : "http://alps.io/profiles/contacts#contact" 421 } 422 ], 424 "queries" : [ 425 { 426 "rel" : "collection", 427 "rt" : "contact", 428 "href" : "http://example.org/contacts/", 429 "data" : [ 430 { 431 "name" : "nameSearch", 432 "value" : "", 433 "prompt" : "Search Name" 434 } 435 ] 436 } 437 ], 439 "items" : [ 440 { 441 "href" : "http://example.org/contacts/1", 442 "rel" : "item", 443 "rt" : "contact", 444 "data" : [ 445 {"name" : "fullName", "value" : "Ann Arbuckle"}, 446 {"name" : "email", "value" : "aa@example.org"}, 447 {"name" : "phone", "value" : "123.456.7890"} 448 ], 449 "links" : [ 450 { 451 "rel" : "type", 452 "href" : "http://alps.io/profiles/contacts#contact" 453 } 454 ] 455 }, 456 { 457 "href" : "http://example.org/contacts/100", 458 "rel" : "item", 459 "rt" : "contact", 460 "data" : [ 461 { 462 "name" : "fullName", 463 "value" : "Zelda Zackney" 464 }, 465 { 466 "name" : "email", 467 "value" : "zz@example.org" 468 }, 469 { 470 "name" : "phone", 471 "value" : "987.654.3210" 472 } 473 ], 474 "links" : [ 475 { 476 "rel" : "type", 477 "href" : "http://alps.io/profiles/contacts#contact" 478 } 479 ] 480 } 481 ] 482 } 483 } 485 Collection+JSON Contacts Representation 487 The descriptor 'collection' has become the link relation associated 488 with a Collection+JSON query. The descriptors 'fullName', 'email', 489 and 'phone' have become the names of key-value pairs in the items in 490 a Collection+JSON collection. 492 1.5. Identifying an ALPS Document 494 An ALPS vocabulary is identified by a unique URL. This URL SHOULD be 495 dereferencable. All ALPS URLs MUST be unique and all ALPS documents 496 intended for public consumption SHOULD be registered in an ALPS 497 Registry [TK: add text on where/how to find registries -mamund]. 499 In order to reduce load on servers responding to ALPS document 500 requests, it is RECOMMENDED that servers use cache control directives 501 that instruct client apps to locally cache the results. Clients 502 making these ALPS document requests SHOULD honor the server's caching 503 directives. 505 2. ALPS Documents 507 An ALPS document contains a machine-readable collection of 508 identifying strings and their human-readable explanations. An ALPS 509 document can be represented in either XML or JSON format. This 510 section identifies the general elements and properties of an ALPS 511 document, their meaning, and their use, independent of how the 512 document is represented. Section 2.3 provides specific details on 513 constructing a valid ALPS document in XML and in JSON format. 515 2.1. Compliance 517 An implementation is not compliant if it fails to satisfy one or more 518 of the MUST or REQUIRED level requirements. An implementation that 519 satisfies all the MUST or REQUIRED level and all the SHOULD level 520 requirements is said to be 'unconditionally compliant'; one that 521 satisfies all the MUST level requirements but not all the SHOULD 522 level requirements is said to be 'conditionally compliant.' 524 2.2. ALPS Document Properties 526 The ALPS media type defines a small set of properties. These 527 properties appear in both the XML and JSON formats. Below is a list 528 of the properties that can appear in an ALPS document. 530 2.2.1. 'alps' 532 Indicates the root of the ALPS document. This property is REQUIRED, 533 and it SHOULD have one or more 'descriptor' child properties. 535 Examples: 537 XML: ... 539 JSON: { "alps" : ... } 541 2.2.2. 'doc' 543 A text field that contains free-form, usually human-readable, text. 544 The 'doc' element MAY have two properties: 'href' and 'format'. If 545 the 'href' property appears it SHOULD contain a dereferencable URL 546 that points to human-readable text. If the 'format' property appears 547 it SHOULD contain one of the following values: 'text', 'html', 548 'asciidoc', or 'markdown'. Any program processing 'doc' elements 549 SHOULD honor the 'format' directive and parse/render the content 550 appropriately. If the value in the 'format' property is not 551 recognized and/or supported, the processing program MUST treat the 552 content as plain text. If no 'format' property is present, the 553 content SHOULD be treated as plain text. 555 XML:

Date of Birth

...

 557 JSON: { "doc" : { "format" : "text" : "value" : "Date of Birth ..." 558 } } 560 A 'doc' element SHOULD appear as a child of 'descriptor'. When 561 present, it describes the meaning and use of the related 562 'descriptor'. 564 XML: ... 566 JSON: { "descriptor" : { { "doc" : { "value" : "..." } ... } } 568 The 'doc' element MAY appear as a child of 'alps'. When present, it 569 describes the purpose of the ALPS document as a whole. 571 XML: ... ... 573 JSON: { "alps : { "doc" : { "value" : "..." }, ... } } 575 2.2.3. 'descriptor' 577 A 'descriptor' element defines the semantics of specific data 578 elements or state transitions that MAY exist in an associated 579 representation. 581 One or more 'descriptor' elements SHOULD appear as children of 582 'alps'. It may also appear as a child of itself; that is, the 583 'descriptor' property may be nested. 585 The 'descriptor' property SHOULD have either an 'id' or 'href' 586 attribute. It MAY have both. Additionally, the 'descriptor' MAY 587 have any of the following attributes: 589 1. 'doc' 591 2. 'ext' 593 3. 'name' 595 4. 'type' 597 If present, the 'href' property MUST be a dereferenceable URL, that 598 points to another 'descriptor' either within the current ALPS 599 document or in another ALPS document. 601 If 'descriptor' has an 'href' attribute, then 'descriptor' is 602 inheriting all the attributes and sub-properties of the descriptor 603 pointed to by 'href'. When 'descriptor' has a property defined 604 locally, that property value takes precedence over any inherited 605 property value. Since there is no limit to the nesting of elements 606 -- even ones linked remotely -- it is important to process 'all 607 descriptor' chains starting from the bottom to make sure you have 608 collected all the available properties and have established the 609 correct value for each of them. 611 If 'descriptor' is declared at the top level of an ALPS document, 612 then a client SHOULD assume that 'descriptor' can appear anywhere in 613 a runtime message. 615 If 'descriptor' is nested, i.e. declared as a child of another 616 descriptor, then: 618 1. A client SHOULD assume them to appear in any sibling 'descriptor' 619 element and recursively in their child descriptors. 621 2. A client SHOULD NOT assume that it can appear anywhere outside of 622 parent descriptor, unless it was explicitly referenced by another 623 descriptor in 'href' attribute. In that case the same rules are 624 applied to 'descriptor' containing 'href' attribute. 626 2.2.3.1. 'Descriptors and Link Relation Types' 628 When a representation is generated that includes state transitions, 629 valid values for link relation types are: 631 1. A registered IANA link relation type (e.g. rel="edit", a short 632 string). 634 2. An extension link relation type as defined by [RFC5988] whose 635 value is the fully-qualified URI of an associated document 636 describing the relation type. This includes URI fragment 637 identifiers of ALPS descriptors (e.g. 638 rel="http://alps.io/profiles/item#purchased-by", a URI) per the 639 conventions of Section 2.2.7.2. 641 3. The 'id' property of a state transition descriptor of an 642 associated ALPS document (e.g. rel="purchased-by", a short 643 string) per the conventions of section Section 2.2.7.1 and 644 Section 2.2.7.3 if the representation includes an ALPS profile. 646 2.2.4. 'ext' 648 The 'ext' element can be used to extend the ALPS document with 649 author-specific information. It provides a way to customize ALPS 650 documents with additional properties not covered in this 651 specification. This is an OPTIONAL element. 653 The 'ext' element has the following properties. 655 1. 'id' 656 2. 'href' 658 3. 'value' 660 The 'id' property is REQUIRED. The 'href' is RECOMMENDED and it 661 SHOULD point to documentation that explains the use and meaning of 662 this 'ext' element. The 'value' property is OPTIONAL. The content 663 is undetermined; its meaning and use SHOULD be explained by the 664 document found by de-referencing the 'href' property. 666 Examples: 668 XML: 671 JSON: { "ext" : { "id" : "directions", "href" : "http://alps.io/ext/ 672 directions", value="north south east west" } } 674 The 'ext' element MAY appear as a child of the following elements: 676 1. 'alps' 678 2. 'descriptor' 680 Since the 'ext' element has no specific meaning within this 681 specification, it MUST be ignored by any application that does not 682 understand its meaning. 684 2.2.5. 'format' 686 Indicates how the text content should be parsed and/or rendered. 687 This specification identifies a range of possible values for 688 'format': 690 o 'text', for plain text, MUST be supported. 692 o 'html', for HTML, SHOULD be supported. 694 o 'asciidoc', for AsciiDoc, MAY be supported. 696 o 'markdown', per The text/markdown Media Type 697 [I-D.ietf-appsawg-text-markdown], MAY be supported. 699 Any other values for this attribute are undefined and SHOULD be 700 treated as plain text. If the program does not recognize the value 701 of the 'format' property and/or the 'format' property is missing, the 702 content SHOULD be treated as plain text. 704 This property MAY appear as an attribute of the 'doc' element. 706 2.2.6. 'href' 708 Contains a resolvable URL. 710 When it appears as an attribute of a 'descriptor', 'href' points to 711 another 'descriptor' either within the existing ALPS document as a 712 fragment or in another ALPS document as an absolute URL. The URL 713 MUST contain a fragment per Section 2.2.7.2 referencing the related 714 'descriptor'. 716 When it appears as an attribute of 'ext', 'href' points to an 717 external document which provides the definition of the extension. 719 When it appears as an attribute of 'link', 'href' points to an 720 external document whose relationship to the current document or 721 'descriptor' is described by the associated 'rel' property. 723 When it appears as an attribute of 'doc', 'href' points to a document 724 that contains human-readable text that describes the associated 725 'descriptor' or ALPS document. 727 2.2.7. 'id' 729 A document-wide unique identifier for the related element. This 730 SHOULD appear as an attribute of a 'descriptor'. It SHOULD be an 731 opaque string that does not contain any URL unsafe characters per 732 [RFC1738]. 734 The value of this attribute MAY be used as an identifier in the 735 related runtime hypermedia representation. In the example below the 736 ALPS descriptor with an 'id' of 'q' is used to identify an HTML input 737 element: 739 'id' in ALPS... 741 ...becomes the 'class' in HTML 744 It should be noted that the exact mapping from ALPS elements (e.g. 745 'id') to elements within a particular media type (HTML, 746 Collection+JSON, etc.) is covered in separate documents (to be 747 specified). 749 2.2.7.1. ALPS 'id' and 'name' Properties 751 In some cases, media types support non-unique identifiers (e.g. 752 HTML's 'name' property) or will allow the same identifier value for 753 multiple elements in the same representation (e.g.