Normative XML Schemas and Conventions in OASIS

I have a few questions, stylistic and substantive, that I welcome comments both off-the-cuff and elaborate….

1)      Schemas and types and conventions. Upper and Lower Camels. Types. Are there preferences? Hated approaches?

what I am seeing is lowerCamel as the most prominent standard for properties and elements. I see some folks prefer lowerCamelType, and others typeLowerCamel and much IETF work which uses type-lowerCamel for the property lowerCamel. A few use UpperCamel for types, lowerCamel for elements.

Writing this out, then, this leaves:
                a) <xs:element name="someProperty" type="ns:somePropertyType"/>
                b) <xs:element name="someProperty" type="ns:typeSomeProperty"/>
                c) <xs:element name="someProperty" type="ns:type-someProperty"/>
                d) <xs:element name="someProperty" type="ns:SomeProperty"/>

Is one of these approaches “The OASIS Way”. If not, are there strong superstitions / tastes anyone would like to share? The computers don’t care, but I find that convention (d) is confusing to read.

2) Machine readable conformance and restrictions, particularly when a derived schema imposes additional restrictions not present in the parent. I have received advice that XPATH assertions tied to schemas is the way to go. Is there any existing OASIS TC that has gone this route? Is there something else that you would suggest? Should such assertions fall into one of the RELAX families instead?

3) When working in a derived schema, do you prefer extensions or substitutions within XSD?

Thanks in advice for any guidance. The IETF specification iCalendar, ad its derivative xCal, is about to get its normative XSD developed in OASIS which will be derived into WS-Calendar, which then will be used by EMIX and oBIX. With dominoes like that, I want to do this in a way that annoys as few future readers as possible.

"If something is not worth doing, it`s not worth doing well"
Peter Drucker

Toby Considine

Chair, OASIS oBIX Technical Committee
U.S. National Inst. of Standards and Tech. Smart Grid Architecture Committee

Facilities Technology Office
University of North Carolina
Chapel Hill, NC

Email: Toby.Considine@ unc.edu
Phone: (919)962-9073

http://www.oasis-open.org

blog: www.NewDaedalus.com

chairs message