JSR 170

Overview

Goals/Motivations

  1. The API should be data source-agnostic and protocol-agnostic
  2. The API should be easy to use as a programmer
  3. Should be relatively easy to implement
  4. The API should standardize common yet complex function required by content-base applications.
  • The levels of compliance address the tension between #3 and #4
  • Items are fetched both through the hierarchy and UUID direct access

Survey

  • Hierarchical storage
  • Three Levels of compliance
    • Level 1 = read-only repo (XPath 2.0 queries, full Item datamodel)
    • Level 2 = writable repo (importing,
    • Level 3 = advanced features (transactions, versioning, observation, locking, SQL)
  • Items : Nodes and Properties

Reading Plan

First Pass

Deep Read (skim):

  • 4 The Repository Model
    • 4.3 Same-Name Siblings
    • 4.4 Orderable Child Nodes
    • 4.5 Namespaces
  • 5 Example Implementations
  • 6.3 Namespaces
  • 6.4.1. System View XML Mapping
  • 6.4.2. Document View XMl Mapping
  • 6.6 Searching Repository Content
  • 6.7 Node Types
  • 6.8 System Node
  • 7.5 Thread-Safety Requirements

Questions

  • How standardized are the behavioral features? (e.g. transactions, locking, observation, …)
    • What's standard and what's implementation-specific?
  • What's the semantic difference between a "Name" and a "Path"?

Notes

  • Order of child nodes is not guaranteed. Think of node.getNodes() as an iterator over a Set.
    • The one exception to this is same-named nodes, of which order must be maintained (using array indexes; 1-based index)

*

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License