Copyright © 1995-2005 Open Applications Group, Inc. All rights reserved 1 OAGi XML Schema User Report June 21, 2005 Michael

Copyright © 1995-2005 Open Applications Group, Inc. All rights reserved 1

OAGi XML Schema User ReportJune 21, 2005

http://www.openapplications.org

Michael RowellChief Architect

Open Applications Group, Inc.


Not-For-Profit Industry Consortium to:

Promote interoperability among Business Software Applications and

To create and/or endorse one or more standards for easier business software interoperability

Open Applications GroupWho we are


Open Applications Group

• OAGi is . . . The Open Applications Group, Incorporated

• OAGIS is . . . The Open Applications Group Integration Standard


OAGi and OAGIS

• OAGi uses XML Schema to define an instantiation of OAGIS

• XML Schema is used to validate runtime XML Instances.

• OAGIS is defined to address needs of common message communications.– For example there are only so many ways to do

a PurchaseOrder. – Why reinvent it each time?

• OAGIS 9.0 includes 434 Business Object Documents (BODs)


Extensions

• OAGi recognizes the need for extensions and change.– The one constant is change.

• OAGi has designed OAGIS to be extensible.


SolutionProviderspecificOverlay

VerticalContentOverlay



CompanySpecificOverlay

• OAGIS Supports Vertical “Plug-Ins”

OAGIS Canonical Business Language

CRMERP CustomerSupplier

• OAGIS is Horizontal Content


Discussion


Extensible Schema

• XML Schema includes three means to implement extension– Xsi:type– Any– Extend and Substitute

• Type derivation by extension• SubstitutionGroups


Elements

• The debate over global vs. local elements continues…– Each has their strengths and weaknesses


Substitution Groups

• Recommendation– Substitution groups for local elements

• Would allow local elements to be substituted for within the scope of their definitions.

• This would help to apply context specific meaning to a given element


complexType Derivation by Restriction

• As it currently is defined simply makes a copy of the base type and the author further restricts the definition.– There is no inheritance from the base type,

should it change – Is not allowed across namespaces

• This prohibits a user to embrace and add restrictions to a standard for their own needs.


schemaLocation Constancy

• When used in:– An instance the xsi:schemaLocation the

recommendation indicates that the location is a hint from the author as to where the xsd definition can be found, additionally the attribute is optional.

– An include the attribute is required and this time it must reference an xsd document.

– An import the attribute is optional, again if present it is a hint as to where to find the given xsd document.


schemaLocation

• Should be constantly defined• Using schemaLocation in our view should be

definitive. • When used the definition should be

resolvable at the given location.


Redefine

• Redefines do not work across namespaces, so only the schema author can redefine. – Our experience says that things defined should remain

consistently defined within their scope. – While local elements may be defined differently depending

upon their scope. – If redefines were allowed across namespaces it would be

possible for a schema to be further defined by users other that the author.

• We see derivation by restriction as more important to this. – Typically, certain types need to be restricted not generally

entire file modules.


Model Group All

• Treating a collection of elements within a parent as bag without any particular order is really makes sense.– However the implied sequence when inheriting

from base type make this difficult.• It is not possible to mix the bags of elements.

– Being able to set the inheritance model group would resolve this.

• By enabling a bag of bags.


simpleType Union

• This is more of an issue with implementation support.


AQ&Q U E S T I O N S

A N S W E R S


Michael RowellOpen Applications Group

Chief [email protected]

http://www.openapplications.org