[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: AW: Missing data model rules for ATG2 XSD compliance
I think, that this may have an impact on UBL's use of the unqualified data
types.
Michael
-----Ursprungliche Nachricht-----
Von: Michael Dill [mailto:dill@gefeg.com]
Gesendet: Mittwoch, 31. August 2005 14:04
An: UN/CEFACT Applied Technologies Group
Cc: Ubl
Betreff: Missing data model rules for ATG2 XSD compliance
Hi All,
this is a comment on some really important issues only, and the comment
is on a conceptual level.
If users reuse in their data models all the supplementary components of the
unqualified data types as of CCT 2.01, then ATG2 (and UBL!) compliant XML
schemas CANNOT be produced without a loss of data. E.g. if they are building
a
qualified data type based on the uDT date time with a pattern for the
supplementary component 'Format', then this information will be lost on
schema generation, because the ATG2 XSD rules eliminate the supplementary
component 'Format'.
As a result I maintain that ATG2 should inform the TBG and the world, that
users, who wish to produce ATG2 compliant schemas, must apply some
restrictions to the CCTS 2.01 unqualified data types.
If TBGs will get this message, then they will ask, what are these
restrictions. If ATG2 tells them, that they have to figure this out
themselves by analyzing the ATG2 unqualified XML schema module, then the
users will probably not be very happy. If ATG tells them to ask their
solution provider or their consultants, then ATG2 can be sure that 10 people
will have at least 4 different implementations. And some vendors may even
tell their users, that their software can only provide approved and
published standard tables and that they cannot add unofficial vendor
interpretations! Therefore ATG2 has to tell the world officially, and in
detail, how a CCTS data model should be built to include the ATG2 specific
unqualified data type module.
In particular, ATG2 will be asked to explain whether the ATG2 specific CCTS
model of unqualified data types should a) replace the CCTS 2.01 unqualified
data types or b) just clarify them or c) in reality be held in the data
model as qualified Data types or d) are just to be used for the final
generation of ATG2 schemas.
If a), then users will ask whether the big promises of CCTS -
interoperability - still can be guaranteed and how.
If b), then users will ask whether these clarifications have been or will be
submitted by ATG2 for the CCTS 2.01 update and will consequently be
published in the next version of CCTS.
If c), then users will ask why the ATG2 XML NDRs confuse users by calling
their XSD stuff unqualified XML data types and having other names than those
which CCTS 2.01 defines for names of qualified data types.
If d) then users will ask ATG2 whether users have to use another CCTS model
package of unqualified data types to map from CCTS models to generate other
syntax specific solutions such as X12, EDIFACT and XBRL etc.
Assuming that the ATG2 model restrictions are syntax specific restrictions -
just for ATG2/UBL XML auto generation schemas, then another question needs
to be answered: a) can or b) must or c) cannot they be used in a syntax
neutral TBG Library of Core Components? There are other XML schema
languages, e.g. XBRL, OAGi possible. And there are other syntaxes such as
EDIFACT, X12, RelaxNG etc.
This raises the key question 'do we know whether these other syntax
specifique solutions can live with the ATG2 W3C XML schema specific CCTS
model restrictions as the only one to be used by CEFACT?' Maybe, it will be
the view of TBG and others that they feel that the needed "ATG2 W3C XML
schema specific CCTS packages for unqualified data types" is just an ATG2
one and not a general CEFACT one. Can TBG17 ask users to adopt the ATG2
syntax solution specific requirements as the only ones for their
submissions?
Certainly users will raise the issue, that they do not like to have
different CCTS packages for unqualified data types, one for ATG2 schema auto
generation, one for mapping to edifact, one for XBRL auto generation, one
for OAGi etc. But what is the right solution?
The above is about concepts and content. Now the question, what should be
the format:
Many users and all of UBL use spreadsheets for CCTS data modeling. All of
the UBL work of the new transport subcommittee, the procurement committee
and the contributions of the Danish Government uses spreadsheets. If the
majority of users likes spreadsheets, yah, then it is probably the best way
that it should been shown how the ATG2 CCTS Model specifique restrictions
look in a spreadsheet for uDT's.
As stated earlier, I do not even ask whether the ATG2 NDR are good, correct
or bad. What I am seeking is to look for the definition of a consistent and
seamless data flow from a syntax-independent TBG Library to - amongst
others - ATG2 compliant schema. A silo concept is not, what we need. If ATG2
declared, that the ATG2 NDR describe a W3C compliant XML schema language
only and not the way from a CCTS data model, who else should do it?
best regards,
Michael
p.s. For those who might want to see the original email from Sylvia, which
disappeard in Mark's reply, I have added her email and the very original
statement below.
-----Ursprungliche Nachricht-----
Von: UN/CEFACT Applied Technologies Group
[mailto:UNCEFACT-ATG@LISTS.UNECE.ORG]Im Auftrag von CRAWFORD, Mark
Gesendet: Freitag, 26. August 2005 13:01
An: UNCEFACT-ATG@LISTS.UNECE.ORG
Betreff: Re: [UNCEFACT-ATG] Schema error
Sylvia,
ATG2 is not responsible for determining which code must be developed by tool
vendors. We specifically state as one of our guiding principles that we
make no assumptions about tools. We have carefully thought out our position
on what is the best approach for syntax specific instantiations of CCTS.
The few restrictions that appear in the UDT are either fully supported by
CCTS, or are necessary to leverage the advantage of XML.
1) As a user, if I create data models using any tool that is
> compliant with CCTS, and that same tool generates schema using ATG2
> NDR, I expect the resulting schema to be correct.
> It is not acceptable that I, as a user, have to know when my
> requirements are syntax specific where ATG2 doesn't apply and errors
> will be created.
The only errors I have seen are those caused by the tool that was being
used. I am able to autogenerate ATG conformant schema from CCTS models
without difficulty.
>
> 2) It is also unacceptable that my tool vendor should arbitrarily
> decide what unwritten ATG2 rules should be invoked to prevent these
> errors and create ATG2 compliant schema.
The rules are quite clear. The UDT is a part of the release. It is the
responsibility of the tool vendor to be able to create conformant schema.
>
> 3) How can ATG2 compliance be achieved if the rules do not exist?
See answer to 2.
Mark
--------------------------------
Mark,
I must take exception to you answer to no. 2 below: "There is no reason to
submit to CCTS, as this is a syntax specific implementation decision."
I did not see any remarks disagreeing with your answer, therefore I must
consider that ATG2 accepts this answer.
With my user hat on, from many years as one, I have a serious problem with
this position.
1) As a user, if I create data models using any tool that is compliant with
CCTS, and that same tool generates schema using ATG2 NDR, I expect the
resulting schema to be correct. It is not acceptable that I, as a user, have
to know when my requirements are syntax specific where ATG2 doesn't apply
and errors will be created.
2) It is also unacceptable that my tool vendor should arbitrarily decide
what unwritten ATG2 rules should be invoked to prevent these errors and
create ATG2 compliant schema.
3) How can ATG2 compliance be achieved if the rules do not exist?
I urge ATG2 to reconsider this position and focus on providing users with a
solution to this problem.
Regards,
Sylvia
------------------
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
-----Ursprungliche 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]