should be part of common types so it would be available to
any standard using common types. However, it is still up to
any individual standard to allow extensions or not. If they
are not part of the schema for the standard, then they are
not part of the standard and any adopter trying to add them
to a given standard will break interoperability. This in
itself explicitly states whether or not Extensions are part
of a standard. If this change is implemented as being
suggested, this will not be a minor change to the schema,
satisfied by an Errata. This will remove the choice
elements and add a whole new element in possibly many places
in addition to adding potentially multiple sets of
enumerations. Someone that implements DE2 as it is today
will have to make significant changes to their code base to
implement DE X with extensions, or SitRep for that matter.
As both an implementer and a standards member, I think it is
in the best interest of our communities to wait, make the
changes, and help limit that pain/cost of implementation.
There is an old
saying that if it isn't forbidden, it's mandatory.
That is a deliberately extreme notion, but, to be honest, I
don't think we need to expicitly state that extension can
apply to SitRep and DE, or HAVE and RM for that matter. If
we make the change to the edxl-ct, edxl-gsf or edxl-ciq it
applies and all we really need to do is to provide some
I absolutely oppose pulling back on SitRep-v1.0 or DE-v2.0.
I could have been equivocal, but where's the fun in that?
On 4/10/2013 11:18 AM, Elysa Jones wrote:
We have worked
hard getting SitRep1 and DE2 ready for an organizational
vote and we currently have a ballot open for the purpose of
approving these works as a Committee Specification. If this
passes, the next steps are obtaining statements of use then
agreeing (again by special majority) to begin the 60-day
review prior to organizational wide balloting.
the past several months regarding a “standard” extension
method for all of our specifications has been ongoing.
These discussion are best documented in the RIM-SC. TC
members have been made aware of this discussion and invited
to participate and stay in touch as it could affect all of
our work. I’ll not repeat any of that discussion here but
ask you to keep it in mind as you make your decision about
SitRep1 and DE2.
You may recall
there were two versions of the DE2 being worked – one with
the layer-extension concept and one without. We decided to
go forward without at this time but all agreed we should
keep it in mind and find some way to incorporate later -
perhaps through common types. Some of our members are
concerned with releasing DE (as well as SitRep) without this
extension concept and then trying to make a change later
would be problematic. We all know how long changes can take
and we are anxious to get this work out. We learned in the
last couple of weeks that this extension method would solve
some issues with TEP as well. So, after considering putting
this in TEP, it has re-opened the discussion about DE and
SitRep in some circles.
The bottom line
here is that we have members that are re-thinking whether we
need to put either of these standards out without this
extension concept. We have sufficient votes today to move
the as they are to Committee Specification. The ballot
closes tomorrow. If we wish to add “extensions” to DE2 and
SitRep, we will have to make not only changes to the
document and back through public review again.
having a “standardized” extension method across all our
standards is very appealing to me. However, delaying SitRep
and DE2 concerns me if it is going to take another year. If
it can be completed in 6 months, it concerns me a little
less - but only if sufficient resources are available to
turn this around quickly. Basically DE2 has already been
done and there is a WD version with it included. I’m not
sure about how much time it would take to add it to SitRep.
to this note with your thoughts.
Berkeley, CA 94702