Upload
liliana-townsend
View
222
Download
6
Tags:
Embed Size (px)
Citation preview
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 1
Semi-Structured Data Access API2000-01-17 Presentation
Frank Farance, +1 212 486 4700, [email protected]
Edutool.Com, a division of Farance Inc.Slides and Document: http://edutool.com/sda
Developed in LTSC Semantics and Exchange Bindings (SXB) WG(IEEE 1484.14) http://ltsc.ieee.org/wg14
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 2
IEEE 1484.14 Semantics andExchange Bindings
• Common features across IEEE Learning Technology Standards Committee (LTSC) 1484.x Working Groups:– Common APIs for data access, e.g., get
value, put value– Common XML methods
• Re-use, adapt, adopt — don’t reinvent• Only SDA discussed in this presentation
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 3
Metadata, What Is It? [1/7]
• Literally, “data about data”– Literal definition applies to most data
• In practice:– many definitions ... some conflicting– many systems overlap usage, e.g., “metadata”
describes both attributes and search/retrieval info
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 4
Metadata, What Is It? [2/7]
• Definition #1: “Metadata is a description of elements that comprise an aggregate type”
• Example:An address label contains: name, address, city, state, zip.
The metadata is: five elements, the first is a string of maximal length 20, …, the fourth is a two character string from a limited set of values, the fifth is string of exactly five numeric characters.
• Metadata is the type, not the values or instances
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 5
Metadata, What Is It? [3/7]
• Definition #2: “Metadata is the elements that comprise an aggregate”
• Example:An address label contains: name, address, city, state, zip.
The metadata is: name: “John Doe”, address: “123 Main Street”, city: “Anytown”, state: “DC”, zip: “20000”.
• Metadata is the data elements
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 6
Metadata, What Is It? [4/7]
• Definition #3: “Metadata is information that helps or facilitates search and retrieval”
• Example:An address label contains: name, address, city, state, zip.
The metadata might feature a “personal” or “business” attribute (many address labels might share); or “home” or “office” (only one address label associated with each).
• Metadata is info that facilitates search/retrieval
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 7
Metadata, What Is It? [5/7]
• Definition #4: “Metadata is information that is associated with an object”
• Example:An address label contains: name, address, city, state, zip.
The metadata might be features such as access permissions, last modified date, internal references.
• Metadata is set of associated attributes/properties
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 8
Metadata, What Is It? [6/7]
• Definition #5: “Metadata is a higher level of data”• Implies some hierarchy (can be good/bad)• Example:
An address label contains: name, address, city, state, zip.
A higher level piece of information such as “contact information”, might have information that describes (identifies) its components (e.g., address label, phone number, E-mail address). The metadata would be the description (but not the typing) of these components: “address label”, “phone number”, “E-mail address”
• Metadata is of a higher level of data in a hierarchy
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 9
Metadata, What Is It? [7/7]
• Summary of definitions:– The elements of an aggregate– Typing information– Information to support search/retrieval– Attributes/properties– Higher-level identifiers, hierarchy implied
• In terms of current usage, no single definition implied• Multiple definitions may be implied simultaneously• Multiple definitions are cause for confusion, e.g.,
what does “metadata registry” mean?
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 10
Structured DataWhat Is It? [1/2]
• Known typing
• Known navigation• Example:record x{
integer p;string q;real r;
} y;
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 11
Structured DataWhat Is It? [2/2]
• Typing is known:y ==> record xp ==> integerq ==> stringr ==> real
• Navigation known:y.p y.q y.r
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 12
Unstructured DataWhat Is It? [1/3]
• Typing might not be known
• Navigation might not be known• Example:{ 17, “SMITH”, 0x80000000, 0x00000016,6, 85, 77, 73, 86, 72, 0};
• Bytes, characters, strings, reals, integers?
• Internal structure?
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 13
Unstructured DataWhat Is It? [2/3]
• How do we know structure (type) is really:record r{integer a;character b[6];real c;string pointer d; // pointer to stringinteger e; // length of string} s;
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 14
Unstructured DataWhat Is It? [3/3]
• How do we know we can navigate data as:s.d[0],s.d[1],s.d[2],...,s.d[s.e-1]
• Unstructured data is very difficult to interpret in the general case
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 15
Semi-Structured DataWhat Is It? [1/4]
• Typing is known, OR
• Navigation is known
• Sometimes, but not always both• Example 1:
<record><phone label=“home”>12125551212</phone><phone label=“work”>12125551000</phone></record>
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 16
Semi-Structured DataWhat Is It? [2/4]
• Type is known (phone)
• Navigation is unknown:– Will “home” always be first– How do I reference “home”?
record.homerecord[0]
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 17
Semi-Structured DataWhat Is It? [3/4]
• Example 2:<record><homephone>12125551212</homephone><workphone>12125551000</workphone><emergencyphone>12125559999</emergencyphone></record>
• Assume “emergencyphone” is an extension
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 18
Semi-Structured DataWhat Is It? [4/4]
• Navigation is known: homephone, workphone, emergencyphone
• Typing is unknown: what is the type of “emergencyphone”?
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 19
Semi-Structured Data Summary
• Data interoperability issues:– Need to define conceptual model of
navigation and typing– XML conventions to support automated
processing– May be able to interpret pieces of semi-
structured data– Need to define conceptual model of
interpretation
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 20
Data Access Summary
• Primary needs for data interoperability:– Required, optional, extensions– Subsets– Supersets– Revisions, multiple versions - compatibility– Typing– Navigation
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 21
“Friction” Issues• Good programming paradigm• Supports many “codings” bindings, e.g:
– XML, databases, programming languages– Good conceptual model– Structured, semi-structured, unstructured data
• Supports “quirks” in bindings, e.g.:– XML records vs. doc model– Access to symbol table (introspection)– Fixed data records
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 22
“Friction” Solutions [1/2]
• Data model: atomic and list objects
• Typing separate from data organization
• Hierarchical naming/navigation, not necessarily hierarchical structure
• Types as data
• Generic support for properties
• Merge value/property namespaces
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 23
“Friction” Solutions [2/2]
• Types and values as properties
• Separate “client” and “server” naming conventions
• Hard/soft links
• Views on demand, view-based security
• “Pluggable Authentication Modules” (PAM) approach towards security
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 24
Overview Of: IEEE LTSC (P1484)Learning Technology Standards Committee
• Formed in 1996-09; currently 20 working groups
• Chair: Jim Schoening, US Army (CECOM)• Vice-Chair: Frank Farance, Edutool.Com• IEEE: accredited standards development org.• LTSC is part of IEEE Computer Society:
>100,000 members• Sponsor Executive Committee (SEC) is
comprised of all WG chairs, makes decisions for LTSC
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 25
IEEE is an AccreditedStandards Development Organization
The Standards Process
• Accreditation affords consistent process
• Committees don’t reinvent wheel
• Choosing a “process” can take years itself
• Accredited process is well-tested and “off the shelf”
DevelopmentConsensusBuilding
MaintenanceReview
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 26
Standards vs. Specifications [1/2]
• Standards:– developed by accredited standards bodies
• Features:– Open forum– Due process, fairness– Specification development and maintenance– Membership for:
• individuals• non-profit• small/medium enterprises (SMEs)• large companies
– Voluntary standards vs. involuntary standards– Treaty organization vs. non-treaty organization
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 27
Standards vs. Specifications [2/2]
• Specifications:– developed by non-accredited organizations
• Features:– Membership: open or closed?– Due process: fair conflict resolution methods?– Specifications, reference models, conformance
tests, branding, products, etc.– May/may not operate like standards body
• Both specifications and standards are useful• Collectively: standards and specification
development organizations (SSDOs)
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 28
Goals of Standards Process• Standards that are well-defined:
– Consistent implementations, high interoperability– Coherent functionality
• Commercial viability:– Standards allow range of implementations– Commercial products are possible:
• All conforming products interoperate, yet ...• Different “bells and whistles”• Consumer can choose from range of conforming systems
• Wide acceptance and adoption• Few bugs:
– Consistent requests for interpretation (RFIs)– Low number of defect reports (DRs)
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 29
Standards are Developed In Working Groups
Developing Standards
• Source: “from scratch” or “base documents”
• Create “standards wording” (normative and informative), rationale for decisions
• Technical committee: in-person or electronic collaboration
Development
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 30
The Working/Study Groups of IEEE LTSC
General Activities1484.1 Architecture and Reference Model1484.3 GlossaryLearner-Related Activities1484.2 Learner Model1484.4 Task Model1484.13 Student Identifiers1484.5 User Interfaces1484.19 Quality System for Life-Long
Learning1484.20 Competency DefinitionsContent-Related Activities1484.10 CBT Data Interchange1484.6 Course Sequencing1484.17 Content Packaging
Data and Metadata1484.12 Learning Objects Metadata1484.9 Localization1484.14 Semantics and Exchange
Bindings1484.15 Data Interchange Protocols1484.16 HTTP BindingsMgmt. Systems & Applications1484.11 Computer Managed
Instruction1484.18 Platform and Media Profiles1484.7 Tool/Agent Comm.1484.8 Enterprise Interfaces
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 31
Formal and Informal Consensus-Building Among Standards and Specification Development Orgs
Consensus-Building Steps
• Collaboration, harmonization with other organizations
• Public reviews as soon as possible
• Public comments• Resolution of comments• Approval stages (refinement):
– Working Draft– Committee Draft– Draft Standard– Approved Standard
DevelopmentConsensusBuilding
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 32
NEW: Related Standards/Specification Development Orgs In Education & Learning Technology
LTSC(P1484)
LTSC & JTC1/SC36: Close Collaboration
ISO/IECJTC1/SC36
GEMPROMETEUS
GESTALT
Current, existingFuture possibilities
Sampling ofOrganizations
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 33
JTC1 (Joint Technical Committee 1)— Information Technology
TC1Screw Threads
TC2Fasteners
SC02Coded Character Sets
SC35User Interfaces
SC22Programming Languages & Environments
SC22/WG20Internationalization
SC31Automatic Identification and Data Capture
SC17Cards and Personal Identification
SC32Data Management and Interchange
SC34Document Description/Processing Languages
SC11Flexible Magnetic Media for Digital Data
SC23Optical Disk Cartridges
SC29Coding of Audio/Picture/Multimedia/Hypermedia
SC24Computer Graphics and Image Processing
SC28Office Equipment
SC27IT Security Techniques
SC07Software Engineering
SC36Learning Technology
CAI-RGConformity Assessment and Interoperability
IIT-RGImplementing Information Technology
JTC1 (Joint Technical Committee 1)Information Technology
TCnnn...
ISOInternational Organization for Standardization
IECInternational Electrotechnical Commission
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 34
Collaboration Within JTC1• Direct collaboration/liaison with ISO stds:
– SC2: character sets– SC22: programming languages– SC24: computer graphics and image processing– SC27: security– SC29: coding of audio, picture, multimedia and
hypermedia– SC32: database and metadata– SC34: document description and processing languages– SC35: cultural adaptation
• Widespread international participation
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 35
Liaisons To/From JTC1
• Direct liaison with:– Object Management Group (OMG)– Internet Engineering Task Force (IETF)– World Wide Web Consortium (W3C)– Digital Audio Video Council (DAVIC)– VRML Consortium– VESA Consortium– The Open Group
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 36
Life Cycle:Maintenance Phase
Maintenance of Standards
• Requests for Interpretation (RFIs)• Defect Reports (DRs) and
Record of Responses (RRs)• Amendments (AMs) and
Technical Corrigenda (TCs)
DevelopmentConsensusBuilding
Maintenance
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 37
Conformance Testing: Insures Interoperability
LTSC(P1484)
DITT: Conformance Testing forapproved standards
Note: Conformance testing involves: (1) interpretation of standards (2) development of test suites (3) testing vendor products/services
ISO/IECJTC1/SC36
GEMPROMETEUS
GESTALT
ADL: Conformance Testing for AICCCMI Learning Management Systems
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 38
Assertion, Inquiry, Negotiation, and Testing (AINT):Documents that transform Standards words to specific tests
Users
Vendors
Other
LTSC(Public) AINT
Document
TestDeveloper
Test Suite
3
2
1
4
“AINT documents are critical for uniform and thorough testing”
Development
Consensus
Interpretation
TestCreation
Standards(specifications)
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 39
(Proposed) LTSC Testing Process:Advice, Certification, Testing, and Branding
LTSC
Test Suite
NIST IEEE/ISTO Vendor
AdvisoryBoard
Test Lab(DITT)
DITT: TestDeveloper
LicensedTest Suite
BrandingLTSC Branding
Authorization
NIST LabCertification
IEEE Proc.Admin.
Test Suite
Test Suite Licensed To Vendors
DisputeResolution
VendorProducts
Results
1
2
3
4
5
6
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 40
End Of Standards Life CycleReview Cycle: Revise, Reaffirm, Withdraw
Review Cycle:
• Revise: new work item, incorporate new technology
• Reaffirm: no changes, stable technology
• Withdraw: little use, obsolete technology
• Typically: 5 year cycle
DevelopmentConsensusBuilding
MaintenanceReview
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 41
Typical Timeline Of Standards
Summary of Standards Process
• Development Phase: 12-48 months
• Consensus Phase: 9-24 months
• Maintenance Phase: 3-6 years
• Review Cycle: revise, reaffirm, or withdraw — every 5 years
• Typical time: from committee formed to approved standard: 18-48 months
• Realistic schedule ==>Good results
DevelopmentConsensusBuilding
MaintenanceReview
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 42
Approximate Timeline/Schedule of LTSC
• 1996, new projects (LTSC formed): .1 .2• 1997, new projects: .3 .4 .6 .7 .10 .11 .12• 1998, new projects: .9 .13 .14• 1999, new projects: .5 .8 .15 .16 .17 .18 .19 .20• 2000, draft standards approved:
– .1 (LTSA), .2 (PAPI), .3 (Glossary), .11 (CMI),.12 (LOM), .13 (SID)
• 2001, draft standards approved:– .6 (SEQ), .8 (EI), .10 (TCL), .14 (SDA), .15 (DCTP),
.16 (HTTP), .17 (Packaging), .18 (PMP)
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 43
Codings, APIs, Protocols
• Codings:– Data exchange via external specification
• APIs:– Control transfer affects data exchange
• Protocols:– Data and control transfer mechanisms
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 44
IEEE 1484.14: API and XML BindingsIEEE 1484.X is: .2, .4, .6, .7, .8, .10., 11., 12., .17
Functionality
Conceptual Model
Semantics
Bindings: APIs Bindings: Codings Bindings: Protocols
Encodings:Data Formats
Encodings:Calling Conventions
Encodings: VariousCommunication Layers
IEEE 1484.XInformative Wording
IEEE 1484.XNormative Wording
IEEE 1484.X,IEEE 1484.14 XML
IEEE 1484.14 SDAInformative Wording
IEEE 1484.X,IEEE 1484.14 SDANormative Wording
IEEE 1484.X, 1484.14,And Other Standards
IEEE 1484.15 DCTP, IEEE 1484.16 HTTP
Various Standards
Requirements
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 45
IEEE 1484.14: API and XML BindingsIEEE 1484.X is: .2, .4, .6, .7, .8, .10., 11., 12., .17
Functionality
Conceptual Model
Semantics
Bindings: APIs Bindings: Codings Bindings: Protocols
Encodings:Data Formats
Encodings:Calling Conventions
Encodings: VariousCommunication Layers
IEEE 1484.XInformative Wording
IEEE 1484.XNormative Wording
IEEE 1484.X,IEEE 1484.14 XML
IEEE 1484.14 SDAInformative Wording
IEEE 1484.X,IEEE 1484.14 SDANormative Wording
IEEE 1484.X, 1484.14,And Other Standards
IEEE 1484.15 DCTP, IEEE 1484.16 HTTP
Various Standards
Requirements
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 46
API Bindings
• Programming Languages:– C, C++, Java, Javascript, Perl, Tcl, VB
• Each programming language is different• Don’t design towards a single language,
e.g., compare strings, exceptions, datatypes
• Expect, but not require: networking, multi-user, nomadicity, security
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 47
Session Features
• Conceptual model: maps to session service
• Startup and shutdown -- can be minimal
• Adaptation between “requests” (client) and “response” (server)
• Design for simple programming paradigm
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 48
Session APIs
• NewSession(): Opens a new session to repository
• DestroySession(): Closes repository• OpenView(): Starts data access to a portion of
the repository• CloseView(): Ends data access• SetParam(), QueryParam(): Changes or
retrieves session parameters
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 49
NewSession
• Creates a connection to a “repository”
• Does not open repository for data access
• SDASession SDANewSession(
string RepositoryName,string ConnectOptions
);
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 50
DestroySession
• Closes a session and all its views
• Knocks down the connection• SDAStatus SDADestroySession
(SDASession S
);
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 51
OpenView
• Data access to a portion/view of repository
• Data access requested for whole view, not just single element
• SDAView SDAOpenView(
SDASession S,string ViewName,string AccessMode
);
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 52
CloseView
• Disassociates/closes a view
• Flushes any pending data• SDAStatus SDACloseView
(SDAView V
);
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 53
SetParam
• Stores session parameters
• Feature set across all views• SDAStatus SDASetParam
(SDASession S,string Param,void *Value,size_t Length
);
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 54
QueryParam
• Retrieves session parameters• SDAStatus SDAQueryParam
(SDASession S,string Param,void *Value,size_t Length
);
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 55
Handlers
• Exception handling for events and errors
• Can be used for security, nomadicity, and protocol negotiation
• Can request or respond to events
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 56
Handler APIs
• SetHandler(), QueryHandler(): Set up and inquire about event handlers
• RequestSecurity(), RespondSecurity(): Allow “server-side” authentication requests
• RequestNomad(), RespondNomad(): Can setup nomadic (reconnectable) connections
• RequestEvent(), RespondEvent(): Used for handling most exceptions and errors
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 57
SetHandler
• Sets a handler to respond to events
• Functions similar to “signal” in C/C++• SDAStatus SDASetHandler
(SDAView V,string HandlerName,(void *) Handler()
);
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 58
QueryHandler
• Closes a session and all its views
• Knocks down the connection• (void *)() SDAQueryHandler
(SDAView V,string HandlerName
);
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 59
RequestSecurity
• Request security from “remote” side
• Allows client to authenticate server• SDAStatus SDARequestSecurity
(SDAView V,string SecurityType,void *Value,size_t Length
);
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 60
RespondSecurity
• Respond to security from “remote” side
• Response from client back to server• SDAStatus SDARespondSecurity
(SDAView V,string SecurityType,void *Value,size_t Length
);
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 61
RequestNomad
• Requests a nomadic session
• Does not disconnect, but may later reconnect
• SDAStatus SDARequestNomad(
SDAView V,string MyCookie,long Duration
);
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 62
RespondNomad
• Respond to nomadic request
• Negotiates nomadic request• SDAStatus SDARequestNomad
(SDAView V,string MyCookie,string TheirCookie,long Duration
);
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 63
RequestEvent
• Send an event to “remote” side• SDAStatus SDARequestEvent
(SDAView V,string EventName,int ParamLength,string ParamList,string ParamType
);
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 64
RespondEvent
• Respond to event from “remote” side• SDAStatus SDARespondEvent
(SDAView V,SDAEventID E,string EventName,int ParamLength,string ParamList,string ParamType
);
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 65
Data Perspectives
• Need to navigate within a “view”
• Naming conventions for data: mapping localized names to “logical” names, e.g., UNIX, Windows, Internet, C, X11
• Coding conventions: how data is exchanged, e.g., XML, Tcl, MIME
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 66
Data Perspective APIs
• SetNaming(), QueryNaming(): Set or inquire naming convention
• SetCoding(), QueryCoding(): Sets data coding, i.e., organization of information
• SetView(), QueryView(): Set or inquire view
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 67
SetNaming
• Sets the naming conventions
• Typical values:– “c-struct”: abc.def.ghi– “url”: abc/def/ghi
• SDAStatus SDASetNaming(
SDAView V,string Coding
);
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 68
QueryNaming
• Retrieves the naming conventions• string SDAQueryNaming
(SDAView V
);
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 69
SetCoding
• Sets the data encoding method
• Typical values: “xml”, “tcl”, “asn.1”• SDAStatus SDASetCoding
(SDAView V,string Coding
);
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 70
QueryCoding
• Retrieves the data coding method• string SDAQueryCoding
(SDAView V
);
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 71
SetView
• Sets the data encoding method
• Typical values: “xml”, “tcl”, “asn.1”• SDAStatus SDASetCoding
(SDAView V,string Coding
);
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 72
QueryView
• Retrieves the data coding method• string SDAQueryCoding
(SDAView V
);
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 73
Data Transfers
• Getting and putting values
• Getting and putting properties
• Deep vs. shallow data transfers
• Create and remove data
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 74
Data Transfer APIs
• GetValue(): Retrieves values using wildcard names
• PutValue(): Stores values• GetDeepValue(): Retrieves values, including
crossing “symbolic links” (data links)• PutDeepValue(): Stores values via “scatter
gather” addressing
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 75
GetValue
• Retrieves a value• SDAStatus SDAGetValue
(SDASession S,string Param,void *Value,size_t Length
);
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 76
PutValue
• Stores a value• SDAStatus SDAPutValue
(SDAView V,string Param,void *Value,size_t Length
);
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 77
Data Transfer APIs
• Copy(): Copies one object to another• DeepCopy(): Copies objects crossing links• Move(): Renames or moves objects• DeepMove(): Moves objects crossing links
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 78
Copy
• Recursive copy• SDAStatus SDACopy
(SDAView V,string SourceName,string DestinationName
);
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 79
DeepCopy
• Recursive copy, including crossing links• SDAStatus SDADeepCopy
(SDAView V,string SourceName,string DestinationName
);
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 80
Move
• Recursive move• SDAStatus SDAMove
(SDAView V,string SourceName,string DestinationName
);
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 81
DeepMove
• Recursive move, including crossing links
• SDAStatus SDADeepMove(
SDAView V,string SourceName,string DestinationName
);
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 82
New/Delete Object APIs
• NewObject(): Creates a new object, such as “list”, “atomic”, “array”, or user-defined type
• DeleteObject(): Destroys and object
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 83
NewObject
• Creates a new object• SDAStatus SDANewObject
(SDAView V,string Name,void *Value,size_t Length
);
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 84
DeleteObject
• Deletes an object• SDAStatus SDADeleteObject
(SDAView V,string Name
);
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 85
Data Walk
• Need to walk “objects”
• Allows complete navigation of object
• Hierarchical naming, but non-hierarchical structures are supported
• Useful for walking structured data, semi-structured data, unstructured data, and XML
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 86
Data Walk APIs
• WalkGetObject(): Walks an object and does successive GetValue() at each point in the object and calls user-specified function
• WalkPutObject(): Walks an object and does successive PutValue() at each point in the object and calls user-specified function
• List(): List elements of the object• DeepList(): Recursive list of elements of the
object
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 87
Data Types
• Integers (8,16,32,64)
• Real (32,64,80,128)
• Characters (8,16,32) and strings
• Boolean, binary, MIME
• Based on ISO 11404
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 88
Bindings
• APIs bound to:– C, C++, Java, ECMAScript (JavaScript),
Perl, Tcl, VB– Maybe: LISP, CORBA
• API design for optimum programming paradigms
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 89
Example: Get Personal Info
S = SDANewSession(“server”)H = SDAOpenView(S,
“personal.edu.john.smith”, “read-only”);SDASetNaming(H, “url”);SDASetCoding(H, “xml”);SDAGetValue(H, “name/given-name”,
first_name, sizeof(first_name));SDAGetValue(H, “name/family-name”,
last_name, sizeof(last_name));printf(“name %s, %s\n”, last_name, first_name);
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 90
Example: Get Personal Info
Output:name Smith, John
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 91
Example: Get Performance Info
S = SDANewSession(“server”)H = SDAOpenView(H,
“performance.edu.john.smith”, “read-write”);SetNaming(H, “url”);SetCoding(H, “xml”);SetView(H,“math-02”);SetView(H, “19980102030405”);GetValue(H, “coding-scheme”,
scheme, sizeof(scheme));GetValue(H, “metric”,
grade, sizeof(grade));printf(“grade %s, scheme %s\n”,grade,scheme);
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 92
Example: Get Performance Info
Output:grade A, scheme US-NY-K12-LETTER-GRADE
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 93
Example: Get/Walk XML
S = SDANewSession(“server”)H = SDAOpenView(S, “metadata”, “read-only”);SDASetNaming(H, “url”);SDASetCoding(H, “xml”);SDASetView(H, “course-1234”);SDAWalkGetObject(H, DEPTH_FIRST, myprint, “.”);// ...
myprint(H, view, value){
printf(“element: %s, value\“%s\”\n”,view,value);}
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 94
Example: Get/Walk XML
Input:<A> <B C=“D”> <E><F>G</F></E> </B></A>
Output:element A, “<B C=“D”><E><F>G</F></E></B></A>”element A/B, “<E><F>G</F></E>”element A/B/E, “<F>G</F>”element A/B/E/F, “G”
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 95
Effective Use ofSemi-Structured Data
• Query
• Wildcards– Client-side wildcards– Server-side wildcards
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 96
What Happens When I Want Information, But There Is Too Much?• Example: “I want person’s phone number”,
but there are three numbers (home, work, emergency)– Which do I choose?– Who makes the choice? Repository, user, both,
other?– How is the choice made automatically with no
human interaction?– Is it possible to pass back (return) several phone
numbers, but to appear as a single number?– Given chosen phone number, what info is
associated with that choice? I.e., user knows something about what what chosen
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 97
IEEE 1484.14 SDA APITyping/Reference Keywords
• _type: The type of the object.• _size: The size of the object in octets.• _length: The length of the object.• _shape: The shape of the object.• _label: The label of the object.• _refer: Generate a reference to the object.• _link: Access the link to the object.
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 98
IEEE 1484.14 SDA APISearch/Query Keywords
• _sqlquery: Embed an SQL query.
• _orderby/C: Sort by criteria C.
• _bytype/T: Search by type T.
• _bylabel/L: Search by label L.
• _byprop/P: Search by property P.
• _head: The head item of a list.
• _tail: The tail item of a list.
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 99
IEEE 1484.14 SDA APIType Conversion Keywords
• _totype/T: Convert to type T.
• _octet: Access object as array of octets.
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 100
IEEE 1484.14 SDA APIMiscellaneous Keywords
• _literal/L: The literal string L.
• _acl: The access control list.
• _ptime: The last "put" time attribute.
• _gtime: The last "get" time attribute.
• _otime: Other time attribute.
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 101
Example
• A person’s record has:home phone: 111work phone: 222 <-- the person/admin has determined this as "primary”emergency phone: 333
• However, the records only store a "type" called "phone" with arbitrary labels ... solution?
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 102
Example
Real Implementation Example:
- real implementation data structure name
- type of data object
- label associated with data object
- Note: “work phone” marked as primary
Real Implementation Type Label _
home phone phone home
work phone phone work|primary
emergency phone phone emergency
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 103
Example
• Getting a phone number?
GetValue("._bytype/phone/._bylabel/primary||._head");// use of IEEE 1484.14 SDA (Semi-Structured
// Data Access) API
• Searches record for all objects of type "phone" and selects either the one labeled "primary" or, if none exist, the first
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 104
Example
• Thus, the following data organizations, as represented in XML, all produce the same result when searching for the person’s "primary" phone number (222):
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 105
Example: Data Set #1
// “222” is selected because of “primary” in LABEL
<phone LABEL="home">111</phone>
<phone LABEL="work|primary">222</phone>
<phone LABEL="emergency">333</phone>
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 106
Example: Data Set #2
// “222” is selected because TYPE is “phone” and
// LABEL is “primary”
// NOTE: This XML organization is substantially
// different than Data Set #1.
<homephone TYPE="phone">111</homephone>
<workphone TYPE="phone" LABEL="primary">222</workphone>
<emergencyphone TYPE="phone">333</emergencyphone>
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 107
Example: Data Set #3
// There is no “primary” LABEL found, so “._head”
// chooses the first record if none found.
// Thus, “222” is chosen.
<phone LABEL="work">222</phone>
<phone LABEL="home">111</phone>
<phone LABEL="emergency">333</phone>
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 108
Example: Data Set #4
// One LABEL has the value “primary”. In this case,
// the implementation might have generate the
// “primary” record on-demand, i.e., it doesn’t
// actually exist, but is generated by the
// repository when searched.
<phone LABEL="primary">222</phone>
<phone LABEL="home">111</phone>
<phone LABEL="work">222</phone>
<phone LABEL="emergency">333</phone>
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 109
Reduced “Friction” Supports ...• Better application paradigms
– Large scaling
• Specification-based, rather than implementation-based– Data longevity/migration– User/vendor/institutional extensions
• Client and server simplicity– Map to a variety of clients/servers– Simple implementation– Can interface to many proprietary systems
• Multiple API and codings bindings
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 110
Important Distinctions• Specification language:
– A language used for a standard
• Data modeling language:– A design tool
• Data implementation language:– Used for programming/imp. languages
• Data coding language:– Used for data transfer
• Confusing these causes significant portability/longevity problems
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 111
Relationship To ISO 11404
• Language Independent Datatypes• A specification language• The “pseudo-code” of data typing• Proposal for amendment:
– “unordered”, “extendable”, “optional”, “extension”, “alias”, “obsolete”, “//” cmts
• Extensibility is not a data modeling issue, but a conformance/longevity issue
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 112
Relationship to UML
• Most useful as a design tool– Potentially useful for data modeling
• Not useful as an interoperability tool
• Having UML or XMI doesn’t imply interoperability
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 113
Relationship to DTDs
• DTDs are primitive tool for specifying syntax
• Main problems:– can’t define extendable types– poor for vendor/user/institution extensions– not enough functionality to describe E-mail
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 114
Relationship to ISO 11179
• Useful for developing automated data type repositories
• Not the same as “specifying” data (i.e., the purpose of a standard)
• Can develop reasonable “computation model” of data access
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 115
Relationship to XML
• XML is useful for coding
• Key problems: “tag style”
• Namespace is broken because scoping is not defined
• Easy to create XML, hard to interpret
• Focus should be on interpretation
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 116
Relationship to XML Schema
• Useful as a data implementation language
• Not useful as a specification language
• Understanding this distinction is important for data longevity/portability