OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-calendar message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: FW: [xml-dev] Namespaces and overrides


 

 


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


Toby Considine
TC9, Inc

TC Chair: oBIX & WS-Calendar

TC Editor: EMIX, EnergyInterop

U.S. National Inst. of Standards and Tech. Smart Grid Architecture Committee

  

Email: Toby.Considine@gmail.com
Phone: (919)619-2104

http://www.tcnine.com/
blog: www.NewDaedalus.com

 

 

From: Michael Kay [mailto:mike@saxonica.com]
Sent: Tuesday, December 21, 2010 10:01 AM
To: xml-dev@lists.xml.org
Subject: Re: [xml-dev] Namespaces and overrides

 



iCalendar is a very loose standard in which nearly every component, and every element of those components, is optional. As we revise, extend, “inherit” those components, we often need to make certain of their elements mandatory for some of these service interactions. What are the language / descriptive formats, preferably machine readable, that you would use to tighten specifications in this way as you adopt them for specific re-use scenarios?

 

XSD tries to do this with complex type restrictions, but I would avoid that route if possible, partly because it involves restating all the things that don't change, partly because you have to define complex type resctrictions at every level of the XML hierarchy. I would rely on XPath assertions to define additional constraints from those in the base schema - expressed either using XSD 1.1, or Schematron, or simply an XSLT stylesheet.

Michael Kay
Saxonica



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]