Thanks Werner,
Did you, perhaps mean TEP1.0 and HAVE2.0?
Cheers,
Rex
On 4/10/2013 2:04 PM, Joerg, Werner wrote:
Ok, maybe I can put some order into all
this:
1) Let's move
the new candidate standards with updated schema and adjusted
specification (DE 2.0, TEP 1.0) proceed through the approval
process;
2) Validate
the "Extension" mechanisms and get approval of the concepts by
the TC.
3) Add the
Extension mechanisms to Common Types and get formal approval
from the TC.
4) Publish
"How To" / "Best Practices" documentation
5) 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 this.
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.
Cheers,
Werner
Okay, I'll give it some more
thought, but I'm not happy about waiting.
Cheers,
Rex
On 4/10/2013 12:11 PM, Wilkins, Brian M wrote:
Extensions
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. IMHO.
V/R,
Brian
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 guidance.
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?
;-)
Cheers,
Rex
On 4/10/2013 11:18 AM, Elysa Jones wrote:
Friends,
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.
Discussion
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 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.
Personally,
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.
Please
respond to this note with your thoughts.
Regards,
Elysa
Jones, Chair
--
Rex Brooks
GeoAddress:
1361-A Addison
Berkeley, CA 94702
Phone: 510-898-0670
--
Rex Brooks
GeoAddress:
1361-A Addison
Berkeley, CA 94702
Phone: 510-898-0670
--
Rex Brooks
GeoAddress:
1361-A Addison
Berkeley, CA 94702
Phone: 510-898-0670
|