Page 1
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
Page 2
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
Page 3
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
Page 4
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
Page 5
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
Page 6
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
Page 7
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
Page 8
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
Page 9
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?
Page 10
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;
Page 11
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
Page 12
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?
Page 13
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;
Page 14
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
Page 15
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>
Page 16
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]
Page 17
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
Page 18
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”?
Page 19
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
Page 20
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
Page 21
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
Page 22
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
Page 23
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
Page 24
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
Page 25
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
Page 26
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
Page 27
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)
Page 28
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)
Page 29
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
Page 30
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
Page 31
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
Page 32
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
Page 33
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
Page 34
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
Page 35
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
Page 36
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
Page 37
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
Page 38
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)
Page 39
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
Page 40
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
Page 41
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
Page 42
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)
Page 43
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
Page 44
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
Page 45
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
Page 46
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
Page 47
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
Page 48
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
Page 49
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
);
Page 50
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
);
Page 51
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
);
Page 52
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
);
Page 53
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
);
Page 54
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
);
Page 55
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
Page 56
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
Page 57
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()
);
Page 58
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
);
Page 59
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
);
Page 60
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
);
Page 61
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
);
Page 62
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
);
Page 63
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
);
Page 64
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
);
Page 65
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
Page 66
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
Page 67
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
);
Page 68
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 68
QueryNaming
• Retrieves the naming conventions• string SDAQueryNaming
(SDAView V
);
Page 69
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
);
Page 70
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 70
QueryCoding
• Retrieves the data coding method• string SDAQueryCoding
(SDAView V
);
Page 71
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
);
Page 72
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 72
QueryView
• Retrieves the data coding method• string SDAQueryCoding
(SDAView V
);
Page 73
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
Page 74
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
Page 75
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
);
Page 76
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
);
Page 77
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
Page 78
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
);
Page 79
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
);
Page 80
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
);
Page 81
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
);
Page 82
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
Page 83
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
);
Page 84
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 84
DeleteObject
• Deletes an object• SDAStatus SDADeleteObject
(SDAView V,string Name
);
Page 85
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
Page 86
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
Page 87
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
Page 88
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
Page 89
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);
Page 90
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 90
Example: Get Personal Info
Output:name Smith, John
Page 91
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);
Page 92
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
Page 93
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);}
Page 94
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”
Page 95
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
Page 96
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
Page 97
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.
Page 98
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.
Page 99
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.
Page 100
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.
Page 101
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?
Page 102
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
Page 103
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
Page 104
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):
Page 105
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>
Page 106
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>
Page 107
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>
Page 108
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>
Page 109
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
Page 110
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
Page 111
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
Page 112
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
Page 113
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
Page 114
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
Page 115
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
Page 116
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
Page 117
2000-01-17 IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com 117
Future IEEE 1484.14 Work
• Spec review at 2000-03 LTSC meeting• Collaboration with:
– ISO-IEC/JTC1/SC32/WG2– ISO-IEC/JTC1/SC25/WG1– ISO-IEC/JTC1/SC22 WG14, WG21, JSG– NCITS/L8– NCITS/J11– NCITS/J22