OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-ndrsc message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: [ubl-ndrsc] [Fwd: Re: UNeDocs XML code lists]


Here are my comments on the UN/ECE code list schemas.

-------- Original Message --------
Subject: Re: UNeDocs XML code lists
Date: Tue, 20 Aug 2002 10:57:33 -0400
From: "Eve L. Maler" <eve.maler@sun.com>
To: Balaji.Duraiswamy.Loganathan@unece.org
CC: Markus.Pikart@unece.org, Jean.Kubler@unece.org
References: <004F667B.C21305@unece.org>

Thanks for the files.  I think Mozilla got confused somehow; clicking on
the links in the normal way led to the error, but opening in a new
window worked.  Strange...

It looks like your code list schemas are for the purpose of formally
recording the characteristics of a whole list.  Even though this is a
slightly different purpose than UBL's (where the goal is to use a single
code in a semantically clear way in a message), your schema style is
indeed very close to the one we're recommending!  Here's a quick
analysis, looking at the country code schema module:

- Your CountryCodedType is analogous to what we're calling our "code
    content type" -- the simple datatype that manages the actual
    representation of the code string.  We also have a "code type", which
    is the complex datatype that manages the code-holding element as a
    whole.

- The attributes (the supplementary components) on <CountryCodeList> are
    basically the same as the attributes we're putting on the element that
    contains a single code (analogous to your <CountryCoded>).  These
    attributes are the sort of thing that we put on the "code type".

- I believe that the <CountryName> element is meant to hold the
    supplementary component Code.Name, which we do as an attribute
    instead.

If you wanted the country code schema to be usable as a module that can
be pulled in to various libraries (including UBL), you might want to
create a parallel module that does a few things differently, or you
might want to serve all the purposes with a unified module.  Here are
the kinds of changes/additions we'd need for our purposes:

- Because we would never be in a position to use the <CountryCodedList>
    element, we would need its attributes to be available on the
    CountryCodedType datatype in addition (or instead).  If you wanted
    them in both places, you could use an attribute group for
    convenience.)  This allows us to supply a country code and identify,
    in absolutely clear terms, the list it came from.

- We have (so far) decided to use only UBL-native local elements inside
    the basic UBL Library, and as a result, we would bind your
    CountryCodedType to the simple content of a UBL-native element, and
    would not import <CountryCoded> directly.  To get the
    supplementary-component attributes onto that element, we would ideally
    want to bind to a named complex type from your schema.  Currently you
    have <CountryCoded> going directly to a simple type.  If you created a
    named complex type that set up the attributes, and then gave it simple
    content bound to the CountryCodedType, you'd give us all the "fodder"
    we need.

- In order for us to be able to refer to your types and elements, your
    schema module would need to be given a namespace name.  Then we (and
    others!) would have a "handle" for referring to, say,
    <unece:CountryCoded> and unece:CountryCodedType.

I fear that the analysis and comments above may be way too dense to
follow.  Stay tuned for a document that describes what we're looking for
in a more friendly way.  In the meantime, a slightly old version of our
Naming and Design Rules document contains an early draft of our code
list recommendations (see Chapter 6):

http://www.oasis-open.org/committees/ubl/ndrsc/archive/wd-ublndrsc-ndrdoc-12.pdf

(We have since gone farther in developing recommendations on how to
embed documentation, but this isn't quite written up yet.)

I will show these schema modules to the NDR group and see if there's any
additional feedback, and I'd also be happy to set up phone conversations
about this subject.  Just let me know.

Regards,

	Eve

Balaji.Duraiswamy.Loganathan@unece.org wrote:
 > Dear Eve,
 >  We just checked the
 > URL(http://www.unece.org/etrades/unedocs/repository/codelist.htm) and we
 > couldn't identify any problem from our side,for your convenience I 
have attached
 > the schemas and instance document with this email.(4 files)
 > We look forward for your valuable comments.
 > Thanks and have a nice day.
 > Regards
 > Balaji
 >
 >
 >
 > ____________________Reply Separator____________________
 > Subject:    Re: UNeDocs XML code lists
 > Author: "Eve L. Maler" <eve.maler@sun.com>
 > Date:       19/08/2002 15:17
 >
 > Hello Markus,
 >
 > Thanks for copying me on this thread.  Unfortunately, I'm getting 404
 > errors when I try to access the XSD files at the web site you
 > referenced.  That aside, however, I'm sure the UBL Naming and Design
 > Rules group would be very interested in comparing notes and seeing if we
 > can recommend a solution that's consonant with your preferred practice.
 >   We've made some additional progress since our initial analysis, and
 > have come up with conventional documentation fields (linked back to Core
 > Component semantics) that we think are necessary for semantic clarity in
 > code list schema modules.  I'm hoping to get this propertly 
documented soon.
 >
 > If you can point me to (or merely send me?) working copies of your
 > schema modules, I'd like to show them to my NDR group.  Thank you!
 >
 > Regards,
 >
 >         Eve
 >
 > Markus.Pikart@unece.org wrote:
 >
 >>Sue, Jon,
 >>
 >>as you know one of the tasks of UNECE is the maintenance and 
publication of
 >
 > code
 >
 >> lists for international trade data. The UN promotes the use of these 
code
 >
 > lists
 >
 >>as  they reduce risks in trade and simplify procedures.
 >>
 >>We provide now two important code lists for trade (country codes and 
currency
 >>codes) in XML/XSD format on the Internet. They are rather short code 
lists we
 >>provide and thus simpler to handle for trail use. At this moment I am 
not that
 >>convinced that there is actually that much demand for code lists in XML
 >
 > syntax.
 >
 >>I would assume most users access our HTML or database publications.
 >>However, our target is to make the UN  Recommendations 3 and 9 
(Recommendation
 >>to use ISO country and currency codes for trade data)  accessible for XML
 >>environments. We are now preparing a document that demonstrates the added
 >
 > value
 >
 >>of XML documents and code lists for trade. In the scenario a trader can
 >
 > validate
 >
 >>a XML document against a standard schema and code lists maintained on 
a UN Web
 >>Server.
 >>
 >>I had a look again at the UBL document  "Position Paper: Code Lists" 
from Eve
 >>Maler and Fabrice Desre. I believe that the format we choose for the code
 >
 > lists
 >
 >>is somewhere similar to the identified preferred method in the document
 >>(Multiple namespaced types).
 >>
 >>We would be interested to receive comments on the value/difficulties 
  of a
 >>integration of these code lists in UBL Schemas/messages. It would 
help us to
 >>develop a better service for our user community.
 >>
 >>The code lists are accessible on the UNeDocs web site under
 >>
 >>http://www.unece.org/etrades/unedocs/repository/codelist.htm
 >>
 >>Regards, Markus
 >
 >
 >
 >


-- 
Eve Maler                                        +1 781 442 3190
Sun Microsystems                            cell +1 781 883 5917
XML Web Services / Industry Initiatives      eve.maler @ sun.com



-- 
Eve Maler                                        +1 781 442 3190
Sun Microsystems                            cell +1 781 883 5917
XML Web Services / Industry Initiatives      eve.maler @ sun.com



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC