Schema Working Session

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