Agenda - telecon 4 Feb 2004

["Lisa-Aeon" <lseaburg@aeon-llc.com>]

Dear all
our regular Weekly NDR calls will start at 12:00 EST -
http://www.timeanddate.com/worldclock/fixedtime.html?
day=7&month=1&year=2004&hour=11&min=30&sec=0&p1=263.

------------------------
#############################################
STANDING INFORMATION FOR UBL CONFERENCE CALLS
U.S. domestic toll-free number: (866)839-8145
Int. access/caller paid number: (865)524-6352
Access code: 5705229
#############################################

1.  Roll Call and Welcome from the chair (Mavis? - or Lisa)

2.  Sub-Committee Reports
        LCSC
        TTSC
        CLSC
        Any others?  Who ever is available we will hear reports.



3.  Review any outstanding issues raised on the list, the following are from
emails from LCSC members.

A.  Stephen Green requests:

Would it be feasible to use xsd:gYearMonth as the base for a new DataType
(in the CCTS sense) to cater for MM/YY (albeit YYYY-MM in ISO short date
format) as used with Credit Card expiry dates?


<xsd:simpleType name="expiryDate">
   <xsd:restriction base="xsd:string">
      <xsd:pattern value="([0-3][0-9]/\)?[0-1][0-2]/\[0-9]{2}"/>
   </xsd:restriction base="xsd:string">
</xsd:simpleType name="expiryDate">

where ([0-3][0-9]/\)?[0-1][0-2]/\[0-9]{2} is
either    DD/MM/YY    (the DD/ is optional depending on the card)
or         MM/YY

Is this exactly how it would appear in the UBL DataType Schema?



B.  Where is the cct:CodeType reference for the bits for the

<!-- ===== RT: CodeType ===== -->
<xsd:element name="CodeContent" type="rt:CodeContentType"/>
<xsd:simpleType name="CodeContentType">
 <xsd:restriction base="xsd:token"/>
</xsd:simpleType>
<xsd:element name="CodeType" type="rt:CodeType"/>
<xsd:complexType name="CodeType">
 <xsd:annotation>
  <xsd:documentation>
   <ccts:Component>
    <ccts:CategoryCode>RT</ccts:CategoryCode>
    <ccts:DictionaryEntryName>Code. Type</ccts:DictionaryEntryName>
    <ccts:Definition>A character string (letters, figures, or symbols) that
for brevity and/or languange independence may be used to represent or
replace a definitive value or text of an attribute together with relevant
supplementary information.</ccts:Definition>
    <ccts:ObjectClass>Code</ccts:ObjectClass>
    <ccts:PropertyTerm>Type</ccts:PropertyTerm>
   </ccts:Component>
  </xsd:documentation>
 </xsd:annotation>
 <xsd:simpleContent>
  <xsd:extension base="rt:CodeContentType"/>
 </xsd:simpleContent>
</xsd:complexType>

I'm going through the CCT Datatype (Representation Term) Schema and I have a
few issues still outstanding really from the last instance sample generation
/ review cycle

1.  In Measure and in Quantity we still have
unitCodeListID
unitCodeListAgencyID
unitCodeListAgencyName
as supplementary components

but in Code we have this restricted to *none*

and in Amount we have it defined in the CCT Schema as
currencyID
codeListVersionID

My question/issue is:

with Code:
the codelist mechanism might have to be very good to avoid need for any meta
data at all - can we guarantee this?  Shouldn't we still have
listID
listAgencyID
listAgencyName
?

with Amount a CCT issue really:
we seem to have a version ID   but is it decided and clear to all that there
is just the one codelist that can be used so that we don't even have to
specify what it is but only which version?


2.  Just a request for feedback from the last NDRSC
call (unavoidable that I couldn't make it) regarding
my issue of
type="xsd:token"
missing from some of the elements in the Schema

3. Who will be editing the DT (CCT DT) and RT (UBL DT) Schemas?
Will it still be Gunther and Garrett?
Will it still be in collaboration / synchronisation with OAG and/or ATG?
How will it fit with the schedule? and tools work?
We'll presumably need any changes introduced prior to instance
generation. There may be some impact on this and on FPSC work
if the listID and listAgencyID are put back into the CCT DT Schema.
I don't see what can be done, if anything at this stage, about the
Amount supplementary components and how to specify the
codeListID
codeListAgencyID
and
codeListAgencyName
but if it were possible and agreed we'd need a suitable schedule for this
-
Otherwise perhaps something should be put into the Documentation








C.  Question from Anne Hendry:  In a recent Libarary Content meeting there
was a question as to whether negative values could be valid values for some
entities, as in the case of an adjustment amount.

Since all the base types used by cct noted above are xs primitive types that
allow negative values, and I can't see anywhere in either of the above files
where there are any restrictions in terms of positive/negative value ranges
(eg. no use of derived types such as PositiveInteger, nonNegativeInteger,
unsgined*, etc), is it safe to assume the range of valid values for UBL
entities based on these CC types includes the full range of values as
allowed by the w3c schema primitive types on which they're based?

Stephen also wants to add:  Would there be any need to specify *how*
(leading sign, trailing sign, etc) a negative amount is specified as a
separate BIE to ensure correct interpretation of the negative aspect? Is the
expression of negativity controlled enough so as to be clear and
unambiguous?







4.  Review and Editorial work on latest version of the NDR document

Anne has an AI to find out the version number of the ndr document that Tim
says was agreed to at the SF plenary.  Would this be the Checklist, or does
NDR generate something else at the F2F?  If not, did the Checklist have a
version number?


5.  AOB



To unsubscribe from this mailing list (and be removed from the roster of the
OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/ubl-ndrsc/members/leave_workgroup.php.











++++++++++++++++++++++++++++++++++++++++++++++++++++
Lisa Seaburg
AEON LLC, co-chair to OASIS UBL NDRSC
Website: http://www.aeon-llc.com
Email:  lseaburg@aeon-llc.com
Alternative Email: xcblgeek@yahoo.com
Phone: 662-562-7676
Cellphone: 662-501-7676

"If you obey all the rules, you miss all the fun."
                       -Katharine Hepburn
++++++++++++++++++++++++++++++++++++++++++++++++++++



---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.576 / Virus Database: 365 - Release Date: 1/30/2004
BEGIN:VCARD
VERSION:2.1
N:Seaburg;Lisa
FN:Lisa Seaburg (E-mail)
ORG:Aeon LLC
TEL;WORK;VOICE:(662) 562-7676
ADR;WORK:;;;Senatobia;MS;38668;USA
LABEL;WORK;ENCODING=QUOTED-PRINTABLE:Senatobia, MS 38668=0D=0AUSA
URL;WORK:http://www.aeon-llc.com
EMAIL;PREF;INTERNET:lseaburg@aeon-llc.com
REV:20040203T221111Z
END:VCARD