ACORDs Experiences using W3C Schemas - PowerPoint PPT Presentation

1 / 9
About This Presentation
Title:

ACORDs Experiences using W3C Schemas

Description:

ACORD 2005. ACORD's Experiences using W3C Schemas. Dan Vint. Senior Architect. dvint_at_acord.org ... Not-for-profit Insurance industries standards body, we have ... – PowerPoint PPT presentation

Number of Views:27
Avg rating:3.0/5.0
Slides: 10
Provided by: raim7
Category:

less

Transcript and Presenter's Notes

Title: ACORDs Experiences using W3C Schemas


1
ACORDs Experiences using W3C Schemas
  • Dan Vint
  • Senior Architect
  • dvint_at_acord.org

2
Background
  • ACORD
  • Not-for-profit Insurance industries standards
    body, we have standards for Life, PC and RLC
    lines. Used in US, Canada, England/London Market,
    and Europe. Growing interest in Japan/China
  • Three standards started in 3 different ways
  • PC based upon an earlier EDI standard.
    Originally designed for DTD use, but added schema
    support when it was available (currently using
    both)
  • Life started as a MS initiative then brought
    into ACORD. DTD based originally, now only using
    schema
  • RLC started in a European standards group, also
    based upon an EDI standard. Using DTDs currently
    trying to add schema support
  • Business Issue How to bring the 3 standards into
    one design
  • For ACORD the best thing would be a common model,
    design and naming conventions
  • Cant get there because we are on different
    cycles. Life and RLC cannot break backwards
    compatibility, PC is currently redesigning
  • Each as a level of adoption and entrenchment.

3
Things that we like
  • Having the schema format be an XML document has
    been very useful
  • We generate schemas and DTDs from a meta-format
    that is maintained in a database
  • We slice the schema into smaller subsets via XSLT
  • Support for basic data types was crucial for our
    needs.
  • Having a built-in documentation standard is very
    nice.
  • Support for namespaces and import/include/redefine
    is useful, but rough around the edges.
  • Can we get this sort of support reversed
    engineered into XML and DTDs?

4
Things we dont like about W3C Schema
  • Took a simple 30 page standard and blew it out of
    proportion.
  • XML took a simplifying approach, schema reversed
    that and put in experimental features and
    complexity
  • Fallout
  • You need tools to manage a schema
  • No two tools agree on their implementations
  • Incomplete implementations
  • Should have left out xsdall, DTDs did and Schema
    implementation is not generally usable anyway.
  • I can teach DTD syntax in an hour or less it
    takes a day for schema
  • Entities requiring the use of DTDs.
  • Yuch! DTDs, thats old technology and a kludge
    Surely if the schema guys had wanted entities to
    be used they would have defined a new method (or
    they wouled have at least documented this use.

5
Things we dont like about W3C Schema (cont)
  • No way to clearly specify the Schema
  • Hint attributes!
  • Confused world of support and no support for the
    hints, inconsistent on what should happen when
    they appear
  • No way to version schema that is supported by
    tools
  • xsdversion attribute has no use or support
  • Namespaces only way to force recognition of a
    change
  • Namespace designation of extension want a
    different namespace rather than the original
    ACORD. (namespace pollution)
  • Extensions, did content really have to be added
    outside the original choice or sequence?
  • Extensibility of enumerated lists
  • Probably 1/3 of the elements in ACORD are based
    upon code lists, and we cant extended them.
  • Need a way to identify the extended code values.
    We have our tpe based upon QName, but this
    doesnt work for external lists.

6
Things we dont like about W3C Schema (cont)
  • No easy way to both validate or ignore extensions
  • We need extensions, but not all trading partners
    will know what the extensions are, so they need
    to at least be able to validate the basic ACORD
    information and structure
  • We have two designs within our standard
  • One uses global elements and groups with
    restriction and extension
  • Another uses an element of ltExtensiongt that is of
    type xsdany and is added at the end of our
    aggregates
  • How about a processContents"strict or
    processContentslax"
  • We could use co-constraints and/or business
    rules
  • We publish a huge schema 700 messages, 29,000
    lines need help in modularizing to make the
    smallest schema possible
  • Business level validation just because a date
    is the wrong format, should I reject a 50
    million transaction?
  • Dont like substituionGroups because it is not
    easy to determine the final content model
  • I like the old SGML notion of no surprises

7
Where we need help
  • Need an integrated approach that supports all
    tools
  • Code generators my biggest headache currently
    dont support all features, dont expect to and
    have decided what subset of XML they think is
    appropriate
  • Groups
  • Redefine
  • Attributes on data level elements
  • Too many levels of inheritance in classes
    create complex code
  • abstract
  • Possible solution profiles
  • XML DTD level support plus data types (import,
    include, namespaces)
  • DTD with base types (abstracts, redefine)
  • Schema extreme (key, unique, substitution groups)
  • Should the W3C consider specifying a language
    that uses XML as a data type? Scripting or
    compiled
  • XML should become a native data type
  • Consider the adoption of a catalog approach to
    schema location, general processing, and
    versioning
  • One standard has a wide content model for
    messages and uses a type code to designate the
    type of message being sent
  • Everything is optional in the core design of
    elements
  • We need a very rich method for managing
    co-constraints based upon several hundred type
    codes
  • Would really like to somehow get auto-magic
    schema validation of these real message
    requirements
  • We want to standardize on the resulting data
    stream when it comes to extensions

8
Where we need help (cont)
  • Reuse of other schemas
  • Good intentions, but impossible to do unless
    designed at the same time
  • Design principals and modeling techniques
  • Based upon different datatypes with/without id
    attributes
  • I want to share part C of an outside schema,
    outside schema has a definition for Party and it
    is used in C, I also have a Party definition and
    I need to substitute it in part C to make it
    useful
  • No easy way to take a part of the other schema
    unless it is in a subset file
  • All I want is codelist A
  • All I want is the Party definition
  • Need to promote a standard way to define
    codelists and encourage standards producers to
    publish them in XML based upon that standard. See
    previous bullet.
  • Want extensions to be identified against the
    extender, not the originator
  • Propose a new attribute "hideBase" to manage
    namespace pollution

9
Why ask why?
  • Why do xml special attributes require definition
    in schema, but not DTD?
  • xmlspace requires and include file, but xmlns is
    automagically there!
  • How will the xmlid attribute be implemented?
  • Why is a simpleType not always simple?
  • Why does adding an attribute make a simpleType
    become complex with a simple content?
Write a Comment
User Comments (0)
About PowerShow.com