Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


RE: [xml-dev] Should Subject Matter Experts Determine XML DataImplementations?

From: B Tommie Usdin <btusdin@------------.--->
To: "Costello, Roger L." <costello@-----.--->, <xml-dev@-----.---.--->
Date: 10/4/2008 5:14:00 PM
At 8:24 AM -0400 10/4/08, Costello, Roger L. wrote:

>  > Many organizations have found that an iterative
>>  process, in which technology experts consult with SMEs and
>>  revise the specification, and the design, many times during
>>  development.
>
>Good points. I did not mean to imply that the development of a Data
>Specification is a one-time thing. As you point out, a Data
>Specification may be revised iteratively as deeper insights are
>obtained.
>
>Nonetheless, my question remains: what is the connection between a Data
>Specification and a derived XML Schema design?

You didn't get my point, or at least my whole point. I suggest that
your SMEs be involved in BOTH development of specification documents
AND development, or at least testing and adjustment, of the data
design. Given their involvement throughout the process, your
question is simply a question of whether the original specification
is continually updated as the requirements are CLARIFIED and ADJUSTED
or if the resultant data design is documented in some other way.

* Clarified, because as the SMEs see how they are interpreted by the
techies and see what structures result from implementing the original
specifications, they will clarify the requirements. (At least, I have
never seen a Data Specification that was so perfect that as the SMEs
saw it implemented they didn't think of things that should have been
there from the beginning and realize that it was ambiguous in some
aspects that cause techies to do something surprising).

* Adjusted, because the techies will discover that some of the things
the SMEs specified require magic, others will be very costly, and
others don't seem reasonable. However, instead of simply making changes
to "fix" these "errors" in the spec, they will consult with the SMEs.
It is likely that SOME of these things don't matter, and some are
critical. If the techies just guess the data design will be broken.
If they follow the original data specification slavishly it will be
inelegant, inefficient, and probably broken.

So, if you continue to revise the Data Specification as requirements
are discovered and accommodated, then at the end there will be a
1:1 relationship. And if you abandon that document as a "starting
place" and document your schema elsewhere, then there won't be.
Your question is not, or at least in my opinion should not be, a
question about data design, it is a question about documentation
practice.

-- Tommie
-- 

======================================================================
B. Tommie Usdin                        mailto:btusdin@m...
Mulberry Technologies, Inc.                http://www.mulberrytech.com
17 West Jefferson Street                           Phone: 301/315-9631
Suite 207                                    Direct Line: 301/315-9634
Rockville, MD  20850                                 Fax: 301/315-8285
----------------------------------------------------------------------
   Mulberry Technologies: A Consultancy Specializing in XML and SGML
======================================================================


transparent
Print
Mail
Like It
Disclaimer
.

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.

.
.

transparent

transparent