[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-ndrsc] Agenda - telecon 4 Feb 2004
Regrets - I have an ongoing meeting conflict now at 9am PT,
but will try to make it on later if my other meeting ends early.
Regarding the agenda, item
C. Question from Anne Hendry: In a recent Libarary Content meeting ...
it was addressed already through email and today's lcsc discussion.
Thanks,
Anne
Lisa-Aeon wrote:
>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
>
>
>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.
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]