1 / 9

Schema Working Session

This article discusses the design issues related to schema namespaces, proposed structure, default namespaces in schema docs, type definitions, dynamic content containers, extensibility, and the use of the mustUnderstand attribute in RFC3863.

joannbrown
Download Presentation

Schema Working Session

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Schema Working Session Jonathan Rosenberg Cisco Systems

  2. Schema Design Issues http://www.xfront.com/BestPracticesHomepage.html

  3. Namespaces • There are way too many • Namespace value is • Avoid collisions • Show user which namespace an element is in • Not needed as a policy input • We won’t have a single root presence schema and namespace • Need to select extensions independently

  4. Proposed Structure • Each spec has its own namespace, except for “abstract” specs (common policy, xcap-patch) • Within a spec, use chameleon namespace design for breaking it into pieces • Everything underneath pidf-status • data-model: urn:ietf:params:xml:ns:pidf:status:data-model • rpid: urn:ietf:params:xml:ns:pidf:status:rpid-status • prescaps: urn:ietf:params:xml:ns:pidf:status:servcaps • future-status: urn:ietf:params:xml:ns:pidf:status:timed-status • cipid: urn:ietf:params:xml:ns:pidf:status:cipid • pres-rules: urn:ietf:params:xml:ns:pres-rules • geopriv-rules: urn:ietf:params:xml:ns:geopriv-policy

  5. Default Namespace in Schema Docs • Target or Schema? • Proposal: target • Most are that way

  6. Type Definitions or Not? • Use a type definition if • The type is more complex than a renaming of an existing defined type • Type definitions global • Element definitions global • Use references to include when you need them • Allows elements to be reused elsewhere

  7. Dynamic Content Containers • For content that is to be defined in other specifications • Use <any> target-namespace other • For content defined in this specification • Substitution groups • Implication: common policy goes to <any>

  8. Extensibility • Each document needs to talk about how extensibility is handled • Make sure you leave hooks via <any> elements and attributes in the right places

  9. mustUnderstand • Defined in RFC3863 as a global attribute • Indicates whether an element in the presence document needs to be understood • We haven’t been using it at all! • Proposal: add it across pidf extensions

More Related