[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: WG: [UNCEFACT-ATG] AW: [UNCEFACT-ATG] [ATG2] Datatype restrictions
-----Ursprüngliche Nachricht----- Von: UN/CEFACT Applied Technologies Group [mailto:UNCEFACT-ATG@LISTS.UNECE.ORG]Im Auftrag von Michael Dill Gesendet: Mittwoch, 24. August 2005 12:15 An: UNCEFACT-ATG@LISTS.UNECE.ORG Betreff: [UNCEFACT-ATG] AW: [UNCEFACT-ATG] [ATG2] Datatype restrictions Mark, the expertise to do so belongs rather to those who defined the restricted ATG2 XSD:unqualified data types. And it seems to be an ATG2 issue to confirm that RESTRICTIONS from a CCTS:unqualified data type become ATG2 XSD:unqualified data types, and to define how the CCTS:unqualified data type should look like. IMO the user world will probably assume, that the content of something, which is named 'unqualified data types' (the ATG2 XSD:unqualified data type module) is as unrestricted as the CCTS:unqualified data types, where in general in CCTS a restriction requires a qualification. I learned from you that the ATG2 XSD:unqualified data types are just a CEFACT XML specifique implementation of CCTS and that's why we (CEFACT) cannot submit the list of CEFACT CCTS:??qualified data types [, which would be the CCTS model aquivalent, from which a schema generation process can derive the ATG2 XSD:unqualified data types] to an update of CCTS 2.xx. My vision is that other XML dialects, especially XBRL, can be derived from a CCTS data model, i.e. there they would build a NDR "CCTS data model to XBRL XSD". GEFEG did a test and it seems, this idea could work. After this answer, it is difficult for me to imagine how interoperability can be achieved without having a common approach on data model level. UNeDocsUK is doing the implementation verification and it is their decision to do any IV notification on the ATG site. But this is a conceptual problem and I see the ball in the basket of the ATG2 NDR project lead not that Ian Hogg should be asked to do the work as an IV. As you certainly know, UBL decided to use the ATG2 unqualified data types, which is good. However, this issue is now an UBL issue as well. Please do understand that I copy this email to those, who are touched by the issue. regards, Michael -----Ursprüngliche Nachricht----- Von: UN/CEFACT Applied Technologies Group [mailto:UNCEFACT-ATG@LISTS.UNECE.ORG]Im Auftrag von CRAWFORD, Mark Gesendet: Dienstag, 23. August 2005 14:44 An: UNCEFACT-ATG@LISTS.UNECE.ORG Betreff: [UNCEFACT-ATG] [ATG2] Datatype restrictions Michael, Since we seem to be talking past each other, please provide the specific restrictions you are concerned about in the form of comment sheet entries - one for each restriction - per the IV notification on the ATG site. My sense is they will be easily dealt with and if necessary will be added to the list of requirements for schema that ATG has given to TBG17. Thanks, Mark > -----Original Message----- > From: UN/CEFACT Applied Technologies Group > [mailto:UNCEFACT-ATG@LISTS.UNECE.ORG] On Behalf Of Michael Dill > Sent: Tuesday, August 23, 2005 7:39 AM > To: UNCEFACT-ATG@LISTS.UNECE.ORG > Subject: [UNCEFACT-ATG] AW: [UNCEFACT-ATG] WG: [ubl] RE: Schema Error > > Mark, > I asked a question and you gave an explanation of issues. > Please be aware, that I do not even discuss whether the > inbuilts are good or bad, useful or nonsense. Thus, most of > the explanations were good ones but missed the point. The > point is that any ATG2 XSD:Data Type, which eliminates or > restricts a CCTS:data type, has to have an equivalent in a > CCTS data model, from which it can be derived. Otherwise the > message of ATG to the world would be "build your schemas > manually and do not derive them from a CCTS data model". > > I'd rather welcome to see a proposal for a solution for the > problem I have raised. > And this is certainly not only an input - this is a problem. > There are users, which agree to use ATG2 schemas to be > generated from CCTS data models. And these users NEED to > know, how the CCTS:data types look in a CCTS data model, > which then became in-built ATG2:XSD stuff - at least if there > is a start with CCTS data models (and this is certainly what > we want, what the US Government wants, what OAGI wants etc). > It would be strange to tell them 'do whatever you want but > the ATG2 schema derivation process does what the NDRs define > and maybe it eliminates your data. But don't worry - the > resulting schemas are technically correct'. > > ATG2 wants users and TBGs to come up with data models in > order to produce schemas for the library/registry. How can > the TBG go into CCTS:data types in their submissions, if they > do not have the any CCTS:data types defintions and > structures, which are required by ATG2 NDR? > > BoostAero, EUDIN/TBG13 and UNeDocsUK - all will came with the > same problem in experiencing ATG2 schemas, I think. > I do not want to see ATG2 running into a self caused problem. > It is better that this problem is solved before it delays > CEFACT's success story. > > regards > Michael > > btw: I'm a member of ATG2 and reading "raise this issue to > us" excludes me verbally. This is neither nice nor helpful > and is not the wording, that I expect from my leading chair. > > > -----Ursprüngliche Nachricht----- > Von: UN/CEFACT Applied Technologies Group > [mailto:UNCEFACT-ATG@LISTS.UNECE.ORG]Im Auftrag von CRAWFORD, Mark > Gesendet: Montag, 22. August 2005 14:59 > An: UNCEFACT-ATG@LISTS.UNECE.ORG > Betreff: Re: [UNCEFACT-ATG] WG: [ubl] RE: Schema Error > > > Hello Michael, > > Thank you for your additional input. I don't believe it is a > matter of you not identifying the issue properly, as we have > discussed this issue before and I believe that we are all > aware of your concerns - it is just that currently the > consensus of the group differs from your perspective on this. > We have a desire to use XSD built in types where we can and > do not believe there is any violation of CCTS in doing so as > this is an XML syntax specific > implementation of CCTS. We believe that the restrictions we have > identified in the UDT schema module are appropriate uses of > XSD built in data types, or else reflect restrictions > specified in CCTS, and are not just > arbitrary restrictions. You may want to look at the > minutes from our June > 2004 and January 2005 F2F where we debated this issue and > affirmed our decision to use built-in datatypes in certain > cases and to not import the CCT schema module. Beyond that > however, we are always interested in specific errors or > restrictions that you believe are not consistent with our > naming and design rules. > > Thanks for taking the time to raise this issue to us, > > Mark > Mark R. Crawford > Senior Research Fellow - LMI XML Lead > W3C Advisory Committee, OASIS, Representative Vice Chair - > OASIS UBL TC, UN/CEFACT Applied Technologies Group Chair - > UN/CEFACT XML Syntax Working Group Editor - UN/CEFACT Core Components > > > LMI Government Consulting > 2000 Corporate Ridge > McLean, VA 22102-7805 > 703.917.7177 Phone > 703.655.4810 Wireless > The opportunity to make a difference has never been greater. > > www.lmi.org > > > > -----Original Message----- > > From: UN/CEFACT Applied Technologies Group > > [mailto:UNCEFACT-ATG@LISTS.UNECE.ORG] On Behalf Of Michael Dill > > Sent: Friday, August 19, 2005 6:43 AM > > To: UNCEFACT-ATG@LISTS.UNECE.ORG > > Subject: [UNCEFACT-ATG] WG: [ubl] RE: Schema Error > > > > RE: Schema ErrorProblem; mismatch between CCTS unqualified > data types > > and > > ATG2 unqualified data types > > > > Mark, > > > > I've explained several times, that the definition of > XML:unqualified > > data types needs an equivalent of CCTS:unqualified data types. > > Apparently, I was not able to communicate this properly. > Now we have > > the below mentioned result! > > > > It is the first implementation verification project > > (=UNeDocsUK) of the ATG2 schemas! > > > > IF we said, that the ATG2 XML:unqaulified Data types are a SPECIFIC > > CEFACT solution, THEN - as of CCTS - we shall NOT have ATG2 > > XML:unqaulified Data types but rather ATG2 XML:qualified > Data types, > > which are derivable from CEFACT CCTS:qualified data types. > > OR we propose that the ATG2 XML:unqaulified Data types are the > > derivable equivalent from the CCTS:unqualified data types. In this > > case these CCTS:unqualified data types have to have EXACTLY those > > restrictions that the > > ATG2 XML:unqaulified Data types can be derived from them. > > > > Michael Dill > > > > -----Ursprüngliche Nachricht----- > > Von: David Kruppke [mailto:kruppke@gefeg.com] > > Gesendet: Freitag, 19. August 2005 09:08 > > An: Hogg, Ian > > Cc: Michael Dill (E-mail); UNeDocs-UK > > Betreff: AW: [ubl] RE: Schema Error > > Hi Ian, > > > > > > > > the problem comes up because of the different unqualified > data types > > in the model and the schema. ATG2 has defined their own set of > > unqualified data types. They removed some SCs, changed some > SC-status > > form "optional" to "required" and retricted some SC by assigning a > > code list. > > > > > > > > The unqualified data type you used in the models don't have these > > restrictions, because there is no released set of unqualified data > > types at model level. > > > > > > > > > > > > Best Regards, > > > > > > > > > > > > David > > > > -----Ursprüngliche Nachricht----- > > Von: Hogg, Ian [mailto:ian.hogg@tnl.co.uk] > > Gesendet: Donnerstag, 18. August 2005 15:42 > > An: David Kruppke (E-mail) > > Cc: Michael Dill (E-mail); UNeDocs-UK > > Betreff: [ubl] RE: Schema Error > > > > Hi David, > > > > Just wondered if you'd a chance to look at this problem yet? > > > > Also, I see from the latest NDRs that Paula has just > sent through > > that the 'ccts' namespace problem has been fixed :-) > > > > Ian > > > > _____________________________________________ > > From: Hogg, Ian > > Sent: 01 August 2005 16:30 > > To: David Kruppke (E-mail) > > Cc: Michael Dill (E-mail); UNeDocsUK > > Subject: Schema Error > > > > Hi David/Michael, > > > > I've just been testing the schemas against my XML instance for > > UNeDocsUK and I've come across a problem. This is the error: > > > > Error at file > > E:\xerces\bin/master\user/common/QualifiedDataTypeSchemaModule > > -1.1.xsd, line 3514, char 46 > > > > Message: Attribute 'currencyID' has an inconsistent REQUIRED > > setting with that of the base > > > > The problem seems to be because Jean has created her own > > "AmountType" > > based on the core components. In the standard unqualified data type > > module, the "AmountType" is defined as follows: > > > > <xsd:complexType name="AmountType"> > > > > <xsd:simpleContent> > > > > <xsd:extension base="xsd:decimal"> > > > > <xsd:attribute name="currencyID" > > type="clm54217:CurrencyCodeContentType" use="required"/> > > > > </xsd:extension> > > > > </xsd:simpleContent> > > > > </xsd:complexType> > > > > But in the user qualified data type schema, the "AmountType" is > > defined as follows: > > > > <xsd:complexType name="_6345AmountType"> > > > > <xsd:simpleContent> > > > > <xsd:restriction base="udt:AmountType"> > > > > <xsd:attribute name="currencyID" > > type="userqdt:_6345AmountCurrencyIDContentType" use="optional"/> > > > > </xsd:restriction> > > > > </xsd:simpleContent> > > > > </xsd:complexType> > > > > Jean and I have been trying to find why the standard > udt is saying > > "required", when it doesn't appear to be in the core components. Do > > you know why this is happening? > > > > Thanks, > > > > Ian > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]