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

[Jon Bosak <bosak@pinax.com>]

A set of conventions developed for UBL 2.0 and later adopted or
adapted by other organizations outside of OASIS can be found at

http://docs.oasis-open.org/ubl/cs01-UBL-2.0-NDR/cs01-UBL-2.0-NDR.pdf

The naming and design rules for UBL 2.1 are similar (though not
identical), but the document itself is scheduled for a complete
rewrite next year.  The new version should become available as a
Committee Specification sometime in 2011.

This has nothing to do with the question, but as long as I'm on
the subject of possibly useful work products, I should mention
that UBL has also created guidelines for customization that might
prove useful for other projects where users may need to modify
standard schemas for particular contexts:

http://docs.oasis-open.org/ubl/guidelines/UBL2-Customization1.0cs01.pdf

(Yes, we're aware of the page numbering problem.  We'll get around
to fixing that next time we revise the document.)

Jon

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 <mailto:Toby.Considine@fac.unc.edu>
> Phone: (919)962-9073
> 
> http://www.oasis-open.org
> 
> blog: www.NewDaedalus.com
> 
>  
> 
>  
>