2000-01-17IEEE 1484.14, SDA Specification, F. Farance, ©2000 Edutool.Com1 Semi-Structured Data Access API 2000-01-17 Presentation Frank Farance, +1 212

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


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


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



• 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



• Definition #2: “Metadata is the elements that comprise an aggregate”


The metadata is: name: “John Doe”, address: “123 Main Street”, city: “Anytown”, state: “DC”, zip: “20000”.

• Metadata is the data elements



• Definition #3: “Metadata is information that helps or facilitates search and retrieval”


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



• Definition #4: “Metadata is information that is associated with an object”


The metadata might be features such as access permissions, last modified date, internal references.

• Metadata is set of associated attributes/properties



• 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



• 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?


Structured DataWhat Is It? [1/2]

• Known typing

• Known navigation• Example:record x{

integer p;string q;real r;

} y;


Structured DataWhat Is It? [2/2]

• Typing is known:y ==> record xp ==> integerq ==> stringr ==> real

• Navigation known:y.p y.q y.r


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?



• 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;



• 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


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>



• Type is known (phone)

• Navigation is unknown:– Will “home” always be first– How do I reference “home”?

record.homerecord[0]



• Example 2:<record><homephone>12125551212</homephone><workphone>12125551000</workphone><emergencyphone>12125559999</emergencyphone></record>

• Assume “emergencyphone” is an extension



• Navigation is known: homephone, workphone, emergencyphone

• Typing is unknown: what is the type of “emergencyphone”?


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


Data Access Summary

• Primary needs for data interoperability:– Required, optional, extensions– Subsets– Supersets– Revisions, multiple versions - compatibility– Typing– Navigation


“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


“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


“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


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

mailto:[email protected]

mailto:[email protected]


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


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


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)


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)


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


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


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



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

http://ltsc.ieee.org/

http://grouper.ieee.org/groups/ltsc

http://www.iso.ch/

http://www.ieee.org/

http://ariadne.unil.ch/

http://www.adlnet.org/

http://www.aicc.org/

http://www.imsproject.org/


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


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


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


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)


Maintenance


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

http://ltsc.ieee.org/

http://grouper.ieee.org/groups/ltsc

http://www.iso.ch/

http://www.ieee.org/

http://ariadne.unil.ch/

http://www.adlnet.org/

http://www.aicc.org/

http://www.imsproject.org/


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)


(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


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


MaintenanceReview


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


MaintenanceReview


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)


Codings, APIs, Protocols

• Codings:– Data exchange via external specification

• APIs:– Control transfer affects data exchange

• Protocols:– Data and control transfer mechanisms


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


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


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


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


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


NewSession

• Creates a connection to a “repository”

• Does not open repository for data access

• SDASession SDANewSession(

string RepositoryName,string ConnectOptions

);


DestroySession

• Closes a session and all its views

• Knocks down the connection• SDAStatus SDADestroySession

(SDASession S

);


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

);


CloseView

• Disassociates/closes a view

• Flushes any pending data• SDAStatus SDACloseView

(SDAView V

);


SetParam

• Stores session parameters

• Feature set across all views• SDAStatus SDASetParam

(SDASession S,string Param,void *Value,size_t Length

);


QueryParam

• Retrieves session parameters• SDAStatus SDAQueryParam


);


Handlers

• Exception handling for events and errors

• Can be used for security, nomadicity, and protocol negotiation

• Can request or respond to events


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


SetHandler

• Sets a handler to respond to events

• Functions similar to “signal” in C/C++• SDAStatus SDASetHandler

(SDAView V,string HandlerName,(void *) Handler()

);


QueryHandler

• Closes a session and all its views

• Knocks down the connection• (void *)() SDAQueryHandler

(SDAView V,string HandlerName

);


RequestSecurity

• Request security from “remote” side

• Allows client to authenticate server• SDAStatus SDARequestSecurity

(SDAView V,string SecurityType,void *Value,size_t Length

);


RespondSecurity

• Respond to security from “remote” side

• Response from client back to server• SDAStatus SDARespondSecurity

(SDAView V,string SecurityType,void *Value,size_t Length

);


RequestNomad

• Requests a nomadic session

• Does not disconnect, but may later reconnect

• SDAStatus SDARequestNomad(

SDAView V,string MyCookie,long Duration

);


RespondNomad

• Respond to nomadic request

• Negotiates nomadic request• SDAStatus SDARequestNomad

(SDAView V,string MyCookie,string TheirCookie,long Duration

);


RequestEvent

• Send an event to “remote” side• SDAStatus SDARequestEvent

(SDAView V,string EventName,int ParamLength,string ParamList,string ParamType

);


RespondEvent

• Respond to event from “remote” side• SDAStatus SDARespondEvent

(SDAView V,SDAEventID E,string EventName,int ParamLength,string ParamList,string ParamType

);


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


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


SetNaming

• Sets the naming conventions

• Typical values:– “c-struct”: abc.def.ghi– “url”: abc/def/ghi

• SDAStatus SDASetNaming(

SDAView V,string Coding

);


QueryNaming

• Retrieves the naming conventions• string SDAQueryNaming

(SDAView V

);


SetCoding

• Sets the data encoding method

• Typical values: “xml”, “tcl”, “asn.1”• SDAStatus SDASetCoding

(SDAView V,string Coding

);


QueryCoding

• Retrieves the data coding method• string SDAQueryCoding

(SDAView V

);


SetView

• Sets the data encoding method

• Typical values: “xml”, “tcl”, “asn.1”• SDAStatus SDASetCoding

(SDAView V,string Coding

);


QueryView

• Retrieves the data coding method• string SDAQueryCoding

(SDAView V

);


Data Transfers

• Getting and putting values

• Getting and putting properties

• Deep vs. shallow data transfers

• Create and remove data


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


GetValue

• Retrieves a value• SDAStatus SDAGetValue


);


PutValue

• Stores a value• SDAStatus SDAPutValue

(SDAView V,string Param,void *Value,size_t Length

);


Data Transfer APIs

• Copy(): Copies one object to another• DeepCopy(): Copies objects crossing links• Move(): Renames or moves objects• DeepMove(): Moves objects crossing links


Copy

• Recursive copy• SDAStatus SDACopy

(SDAView V,string SourceName,string DestinationName

);


DeepCopy

• Recursive copy, including crossing links• SDAStatus SDADeepCopy


);


Move

• Recursive move• SDAStatus SDAMove


);


DeepMove

• Recursive move, including crossing links

• SDAStatus SDADeepMove(

SDAView V,string SourceName,string DestinationName

);


New/Delete Object APIs

• NewObject(): Creates a new object, such as “list”, “atomic”, “array”, or user-defined type

• DeleteObject(): Destroys and object


NewObject

• Creates a new object• SDAStatus SDANewObject

(SDAView V,string Name,void *Value,size_t Length

);


DeleteObject

• Deletes an object• SDAStatus SDADeleteObject

(SDAView V,string Name

);


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


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


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


Bindings

• APIs bound to:– C, C++, Java, ECMAScript (JavaScript),

Perl, Tcl, VB– Maybe: LISP, CORBA

• API design for optimum programming paradigms


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);


Example: Get Personal Info

Output:name Smith, John


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);


Example: Get Performance Info

Output:grade A, scheme US-NY-K12-LETTER-GRADE


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);}


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”


Effective Use ofSemi-Structured Data

• Query

• Wildcards– Client-side wildcards– Server-side wildcards


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


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.


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.


IEEE 1484.14 SDA APIType Conversion Keywords

• _totype/T: Convert to type T.

• _octet: Access object as array of octets.


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.


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?


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


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


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):


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>



// “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>



// There is no “primary” LABEL found, so “._head”

// chooses the first record if none found.

// Thus, “222” is chosen.

<phone LABEL="work">222</phone>





// 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="work">222</phone>



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


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


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


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


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


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


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


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


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