Re: [chairs] Normative XML Schemas and Conventions in OASIS

[Robin Cover <robin@oasis-open.org>]

Toby,

I have no personal superstitions or insight into an imagined
"OASIS Way", but you might find this document useful, WRT
case conventions for different kinds of components.  Of course,
it's not up-to-date.

"Use of Camel Case for Naming XML and XML-Related Components"
http://xml.coverpages.org/camelCase.html

Cheers,


- Robin

Robin Cover
OASIS, Director of Information Services
Editor, Cover Pages and XML Daily Newslink
Email: robin@oasis-open.org
Staff bio: http://www.oasis-open.org/who/staff.php#cover
Cover Pages: http://xml.coverpages.org/
Newsletter: http://xml.coverpages.org/newsletterArchive.html
Tel: +1 972-296-1783


On Tue, 21 Dec 2010, Considine, Toby (Campus Services IT) wrote:

> 
> 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.
> 
>  
> 
> tc
> 
>  
> 
> 
> ____________________________________________________________________________________________________________________________________
> 
> 
> "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
> 
>  
> 
>  
> 
> 
>