[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-calendar] WS-Calendar derivations
|
Bruce
Bartell Xtensible Solutions Mobile:
+1.321.258.6500 From: Edward Koch
[mailto:ed@akuacom.com] WS-Calendar TC, For some time I’ve been trying to
come up with a way to restrict/extend the WS-Calendar schemas in such a way to
get a tighter definition and validation on the schedule types that I desire to
use. The deeper I dig into this to try to find some creative solution the worse
it seems to get. In my opinion there are some serious issues with the way
the core WS-Calendar structures have been defined. Basically EVERYTHING
is a BaseComponentType which means that the ONLY actual structure in the schema
is a general purpose recursive collection of entities that really only have two
attributes: “ArrayOfProperties” and
“ArrayOfComponents”. To make matters worse because the
baseComponent and baseProperty elements of the BaseComponentType are just
abstract substitution group heads there is no way to restrict anything. I can
really only extend by adding more types to the substitution group which is not
adding to the structure or constraining my options. Furthermore since many of
the substitutions group elements are nothing more than a named wrapper around
yet another BaseComponentType, that amounts to nothing more than adding a
naming convention for how to chain together the BasComponentTypes without
really adding any additional structure. I’m still hoping that I’m
just not skilled enough to manipulate the schemas but I think someone went way
too far to try to make everything extensible. I’m confident that I can hand code a
reasonable XML for what I want to do by just referencing the top level
VAvailabiity, etc. but given that there are literally an infinite number (and
yes because of the recursive definitions it really is infinite!) valid XML
documents that can be validated against that schema I’m left with making
A LOT of very detailed conformance statements that will need to be implemented
in application code. In fact one could argue that I will be making so
many conformance statements that I might be better off skipping the schema
definitions altogether and just describing what the XML document is going to
look like since almost all the validation will be done at the application level
anyway. In my attempts to derive the WS-calendar
schemas I have some partial solutions that extend the schemas in different ways
that might be acceptable, but they will in essence bypass the interval stuff
and directly extend the BaseComponent with the fixed intervals that I
want. Of course you can always attempt to do a redefine as well. In order to frame the discussion better
let’s start at the top level with a simple description of an EIEvent
schedule. Let not worry about the sub intervals yet. Lets just
answer one simple question: Assume I have the following attributes of
an EIEvent schedule. For the time being let’s not get into some
esoteric discussion of whether people think these are the right attributes, but
concentrate instead on how we represent these in a derivation of a WS-Calendar
schema. Note I said schema NOT XML. I’m sure we could hand craft an
XML that would validate against the existing WS-Calendar schemas, but there would
be very little to constrain the xml to just the intervals I want. Here are the
intervals that all EIEvent Schedules have: Start date/time Duration of the event Notification period before the event
starts Ramp up time after the event starts Ramp down or recovery period after the
event ends Assuming we want to fix these so that
these same set of attributes always exist as part of the schedule, how do we
derive the existing WS-Calendar to create a schema that expresses that fact.
Maybe I’m reading too much into this and its as simple as creating an
extended type with all these attributes in it. That’s essentially
what I am exploring now in what I alluded to above. Thanks, -ed Koch |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]