Re: [xml-dev] CCTS NDR tools for generation of schemas

["bryan rasmussen" <rasmussen.bryan@gmail.com>]

Hi Todd,

I was just wondering, I tried to access the documents found various
places under the framework - for example
http://www.xmllegal.org/Documents/Announcements/GlasserSchemaFrameworkReferenceDocuments_PFD_Ver0_3_2004_06_21.pdf
but it requires a password to access, I thought maybe that might be a
server error in that the text next to the referenced document says
Free in bold, giving me the impression I could just download it and
read it?

cheers,
Bryan Rasmussen

On 4/27/07, Winchel 'Todd' Vincent III <winchel@mindspring.com> wrote:
> Bryan, Others:
>
> We have had an NDR that we use internally and for our clients that we call the Schema Framework (http://www.xmllegal.org/SchemaFramework/), so the following comments are based on our experience.
>
> 1. Interoperability is certainly one benefit.  While the benefit is greatest among those who use the same NDR, interoperability is also made easier when dealing with "foreign" schemas (other NDRs or no NDR at all), since you can use your own NDR and tools you or others have developed around the NDR to develop part of your code.  You can then transform your easily-generated XML into XML based on a "foreign schema" if that is required.  This occurs with some of our clients who are required to use "industry standard" schemas -- they like to use our NDR and associated artifacts internally and then transform to the required "foreign schema" format.  The latter is not ideal, but it is better than no NDR (and no tools) at all.
>
> 2. Schema Generation - schema generation has several benefits.  Three or four years ago, a schema that might have taken us a few weeks to create, we can do now in several hours (not including the time to gather requirements).  I just learned of a colleague whose organization received a proposal to do a schema project that would require one person for 19 weeks.  With our schema generation tools, my colleague believes it could be done in a week.  Additionally, for junior developers or business analysts, it is better to give them a schema generation tool and requirements and let them churn out a schema that may not be perfect from a requirements point of view, but that is a high quality schema from a schema point of view.  The schema generation tool won't let them mess up the schema.  If the tool can do a round trip generate-and-edit (which ours can), then you can revise the schema with the tool until you get it right.  I am able to delegate far more schema projects to non-schema experts because of the NDR and associated tools.  After review of their work, usually by the second or third round, we have a high quality schema that can be used in pre-production or production.
>
> 3. Another aspect of interoperability is internal among your own applications.  We have code generators (xml data binding) as well as schema and code repositories that are far more powerful and higher quality because they  rely on schemas that are based on the NDR.  We are able to generate other artifacts, such as documentation, XSLT, web services, client and server applications in multiple languages, all of which can be done because of the underlying NDR.  Stated another way, an NDR is not just about schema generation.
>
> I took part in the Federal NDR discussions and based on those discussions (which did not seem to get very far at the time), I think it would be folly to try to standardize on a single NDR.  Indeed, different applications require different NDRs.  Just as an example, a database-to-database information exchange would probably never require mixed content and, in fact, people who focus on those types of exchanges would tell you that mixed content should be banned from an NDR -- that is their perspective (and they are right from a database-to-database information exchange perspective).  However, people who focus on document formats would tell you that you can't live without mixed content and that all NDRs ought to allow mixed content -- that is their perspective (and they are right from a document format perspective).
>
> NDR discussions devolve very quickly into 'rat holes,' because people who envision different applications for XML (there are a lot of them) will argue quite righteously (and reasonably) that certain rules are absolutely necessary, while others will argue equally righteously (and reasonably) that those same rules should be banned completely.
>
> While this veers slightly from the topic, another problem/barrier to good NDRs is that there has been a trend to combine data dictionary projects and standard schema implementations.  Data dictionaries and schema implementations should be separated.  When they are combined, they stand in the way of good NDRs that can work for specific types of applications and also limit the usefulness of the data dictionary.
>
> My $0.02 for what it is worth,
>
> Todd
> ===========================
> Winchel "Todd" Vincent III
> <xmlLegal> http://www.xmllegal.org/
> Phone : 404.822.4668
> Fax     : 770.216.1633
> Email   : Todd.Vincent@xmllegal.org
>
>
>
> -----Original Message-----
> >From: bryan rasmussen <rasmussen.bryan@gmail.com>
> >Sent: Apr 26, 2007 4:29 PM
> >To: XML Developers List <xml-dev@lists.xml.org>
> >Cc: d_a_carver@yahoo.com, Stephen Green <stephengreenubl@gmail.com>, "Crawford, Mark" <mark.crawford@sap.com>
> >Subject: Re: [xml-dev] CCTS NDR tools for generation of schemas
> >
> >hmm, thinking it over I would probably suppose the following:
> >
> >1. there may well be a benefit to having a CCTS NDR on the basis of
> >interoperability with all other organizations that have CCTS NDRs.
> >
> >2. there is probably not much benefit to be had generating schemas
> >from models (unless you assume your schema writers can't be trusted to
> >know XML schema well etc. I suppose that is a concern but I wonder if
> >the model is so much easier that problems won't show up)
> >
> >What do people observe as to the costs of mandating and analyzing CCTS
> >compliance? I have seen some hairy discussions in UBL, I suppose it
> >can get quite expensive in such projects as the Navy one.
> >
> >Cheers,
> >Bryan Rasmussen
> >
> >On 4/26/07, Crawford, Mark <mark.crawford@sap.com> wrote:
> >> > >
> >> > > To my understanding of CCTS, having just one possible NDR is against
> >> > > the spirit of CCTS - completely against it. CCTS should be
> >> > implementation
> >> > > technology agnostic - that's one of the main tenets behind
> >> > it's very
> >> > > concept.
> >>
> >> Agreed.  I think there is some confusion here about the CCTS standards
> >> stack in general, and the UN/CEFACT Standards Stack in particular. The
> >> CCTS standards stack consists of CCTS.  It requires the use of no other
> >> specification - UN/CEFACT or other - for implementation. The UN/CEFACT
> >> CCTS standards stack however does have a defined XML NDR as part of the
> >> stack - for use by UN/CEFACT. Further CCTS does not require any syntax
> >> specific set of rules.  In fact its power is in its syntax neutrality
> >> and its context mechanisms.
> >>
> >> > There are actually three XML NDRs for CCTS:
> >> >
> >> > 1. UBL 2.0 NDR
> >> > 2. ATG2 XML NDR 2.0, and 1.0
> >> > 3. OAGIs 9 v0.7 NDR
> >>
> >> Actually, there are many more and I am not sure I would include OAGi 9
> >> at this point.  The US Department of the Navy for example has their own
> >> CCTS NDR.  What is interesting is that many SDOs have realized - driven
> >> in large part by their membership - that it makes no sense to have
> >> different flavors of NDRs and that yes there is real value in being able
> >> to auto generate schema from the business models.  OAGi, GS1, CIDX,
> >> ACORD, UN/CEFACT, UBL,RosettaNet, AIAG and others have come together to
> >> work collaboratively on the next set of UN/CEFACT XML NDRs that will
> >> serve as a convergence point for all of these organizations.
> >>
> >> Kind Regards,
> >>
> >> Mark Crawford
> >> SAP Standards Architect
> >> Global Ecosystem and Partner Group
> >> Office: 703 670-0920
> >> Mobile: 703 485-5232
> >> ----------------------------------------------------------
> >> Chair UN/CEFACT Applied Technologies Group
> >> Lead, UN/CEFACT XML NDR Standard
> >> Lead Editor, UN/CEFACT Core Components
> >>
> >> _______________________________________________________________________
> >>
> >> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> >> to support XML implementation and development. To minimize
> >> spam in the archives, you must subscribe before posting.
> >>
> >> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> >> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
> >> subscribe: xml-dev-subscribe@lists.xml.org
> >> List archive: http://lists.xml.org/archives/xml-dev/
> >> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
> >>
> >>
> >
> >_______________________________________________________________________
> >
> >XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> >to support XML implementation and development. To minimize
> >spam in the archives, you must subscribe before posting.
> >
> >[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> >Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
> >subscribe: xml-dev-subscribe@lists.xml.org
> >List archive: http://lists.xml.org/archives/xml-dev/
> >List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
> >
>
>