I will go along with whatever the group
wants and do what needs to be done.
Just one note: It is seldom our intentions that hold us up,
(though that does happen and I admit my share) but our schedules
and other things that are beyond our control.
So, let's rock and roll.
On 4/10/2013 6:23 PM, McGarry, Donald P. wrote:
Here are my thoughts:
- We can't go back and change the DE 2.0 or SitRep 1.0
- Even if we put whatever revised list data structure in
the 'common types', that won't change what is used in the
DE 2.0 / SitRep 1.0 specification. Just because we update
common types does not inherently update common types
across other standards.
- Any revision to the choice element that I used to create
'default' value-lists would require a major revision, an
errata wouldn't cover it.
- I don't think / want this to take a long time. I think
we just need to work out:
- What is the future of the value-list (and related
list structures) across EDXL
- How do we handle default list values
- How do we need to change the schemas for DE 2 /
SitRep 1 to support the above.
- After we have that discussion we can make the
changes and move on. From there we can provide
guidance on how to use these concepts going ahead.
I spoke with Elysa about this today and I'm willing to
put some folks behind making this happen in a timely way.
If we can pick a single time to meet weekly, I think we can
have this hashed out without too much hassle.
Lead Software Systems Engineer
The MITRE Corp.
Did you, perhaps mean TEP1.0 and HAVE2.0?
On 4/10/2013 2:04 PM, Joerg, Werner wrote:
maybe I can put some order into all this:
Let's move the new candidate standards with updated
schema and adjusted specification (DE 2.0, TEP 1.0)
proceed through the approval process;
Validate the "Extension" mechanisms and get approval
of the concepts by the TC.
Add the Extension mechanisms to Common Types and get
formal approval from the TC.
Publish "How To" / "Best Practices" documentation
From here on any standard can use Extensions:
5.1) For new standards, the work done for TEP or DE
can serve for guidance.
5.2) To allow for the use Extensions in the spirit of
"layers" ("Community Extensions") in existing
standards, a "small" addition to the schema is
required - an Errata could be sufficient to accomplish
5.3) To allow for the full set of extension
capabilities (i.e. "list augmentation", "list
replacement" and "list reassignment") in existing
standards, more substantial changes are needed in the
schemas. As our work with TEP has shown, migrating
from WD03 (without Extensions) to WD04 (with
extensions), such changes can lead to significant
simplifications with repercussions in the schema and
the specification. In most cases these will be
substantial changes that can not be accomplished with
a simple Errata.
Okay, I'll give it some
more thought, but I'm not happy about waiting.
On 4/10/2013 12:11 PM, Wilkins, Brian M wrote:
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.
is an old saying that if it isn't forbidden,
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:
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.
over 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
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.
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.
respond to this note with your thoughts.
Berkeley, CA 94702
Berkeley, CA 94702
Berkeley, CA 94702
Berkeley, CA 94702