[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [obix] Groups - oBIXfigure1UML.png uploaded
We did much the same in WS-Calendar.
WS-Calendar type pre-dated XML types.
Some had particular pattern expectations.
See the WS-Calendar artifacts linked from the namespace document at:
Go down to the CS01 Schemas.
All types are defined in the valtypes schema (which look exactly like what Craig is describing) then look at props to see how we use them.
WS-Calendar required extensive use of substitution groups to align with pre-existing work in the IETF; oBIX will not need to be so complex. Still. If we define low level elements as we did in the valtypes schema, then we can put restrictions, patterns, etc, and this becomes a normative description for all encodings, even if they do not use XML (if we so declare).
Note the namespace document named above (http://docs.oasis-open.org/ns/ws-calendar) which is in RDDL (Resource Directory Description Language) (http://www.rddl.org/) which provides both a machine and human readable guide to the XML artifacts.
"When one door closes, another opens; but we often look so long and so regretfully upon the closed door that we do not see the one which has opened for us."
-- Alexander Graham Bell
One thing I would rather see is these things defined in terms of their oBIX constructs, instead of the xsd types. Maybe this is what 1) is about, but it would seem more self consistent if, for example, the ‘name’ attribute were an obix:str, instead of an xs:string. Even though obix:str maps to an xs:string, the name is really an obix:str and the fact that the two are the same is sort of a coincidence of the way we defined obix:str. Is it somehow invalid UML to have it be an obix:str instead of xs:string? I’m not an expert at UML.
I can easily embed this into the doc once we agree on whether this is ok.