Re: [ubl] Codelists Re: [ubl] Minutes UBL Atlantic call April 26 2006

["Stephen Green" <stephengreenubl@gmail.com>]

Hi

I agree my definition was very convoluted.

I think we need to mention XSD's 'default' attribute and when to use
default and when
fixed.

  "The use of XSD's 'fixed' attribute MAY be used to restrict supplementary
    component attributes to use of particular values in a UBL qualified datatype
    schema but only when backward compatible value changes will never
be required"

  "The use of XSD's 'default' attribute MAY be used to restrict supplementary
    component attributes to suggest particular values in a UBL
qualified datatype
    schema when backward compatible value changes may be required "

Steve


On 27/04/06, Tim McGrath <tmcgrath@portcomm.com.au> wrote:
>  I can see what Stephen is trying to achieve here but it seems rather
> convoluted.  I am not sure that we cannot just say:
>
>  "The use of XSD's 'fixed' attribute MAY be used to restrict supplementary
> component attributes to use of particular values in a UBL qualified datatype
> schema "
>  and have done with it.
>
>  It seems to me if we are relying on post schema validation then anything in
> the schema is at best a recommendation for what values to use.  If an
> implementation changes that to suit their requirements then they manage the
> impact.  In other words, making the value 'fixed' still does not ensure
> compatible code values because we dont know how these will be validated.
>
>
>  Stephen Green wrote:
>
>  ACTION ITEM: a provisional NDRule for use of XSD's 'fixed' and
> 'default' attributes
> in qualified code types
>
> "The use of XSD's 'fixed' attribute MAY be used to restrict
> supplementary component
> attributes to use of particular values in a UBL qualified datatype
> schema but only where
> it is indisputably judged that future instances will never need to
> change the values of
> these supplementary component attributes. Where a change might be
> required, if there
> is a requirement to include a value for such supplementary components in the
> UBL
> qualified datatype schema, XSD's 'default' attribute MUST be used instead."
>
> This could be reworded depending on the decision to the next issue:
>
> To implement this, either:
> 1. we could add a column to the qualified datatype spreadsheet to
> state whether the
> attribute value of the particular supplementary component should be
> fixed or default
> or:
> 2. we could assume that all supplementary components of the same name use
> the
> same XSD device ('fixed' or 'default' attribute) for the same
> supplementary component
> (e.g. listVersion would always be 'default' and never 'fixed') and we
> could agree (as a
> modelling decision) which attributes are 'fixed' and which have a
> 'default' value.
>
> If the second we might reword the proposed NDR to:
>
> "The use of XSD's 'fixed' attribute MAY be used to restrict
> supplementary component
> attributes to use of particular values in a UBL qualified datatype
> schema but only where
> it is indisputably judged that future instances will never need to
> change the values of
> that particular supplementary component attribute. Where a change
> might be required, if there is a requirement to specify a value for
> some such supplementary components,
> XSD's 'default' attribute MUST be used instead."
>
> This matter should be resolved as soon as possible and agreed and
> stated in the next
> Atlantic TC call so that changes may be made to implement this in
> schema generation
> in good time for the Brussels plenary, as decided in today's Atlantic TC
> call.
>
> Thanks
>
> Stephen Green
>
>
>
> On 26/04/06, Stephen Green <stephengreenubl@gmail.com> wrote:
>
>
>  Just a few corrections for the codelist item:
>
> "7. Code lists:
>
>
> A. (- superceded)
>
> B. (- superceded)
>
> SG: Pacific TC Call discussed implementation of the methodology.
> URLs will be used for genericode
>  components within spreadsheets.
>
>  Current proposal is to use a relative location for the URLs until
> the absolute URLs are determined.
>
>  The following 3 things are needed.
>
>  1. Need a place for the genericode list.
>  2. Need to add further code for transport.
>  3. NDR need attributes but don't want the
>  attributes for codes in the schema to be
>  fixed (xsd:fixed) but xsd:default instead."
>
> Thanks
>
> Stephen Green
>
> On 26/04/06, Mavis Cournane <mavis.cournane@cognitran.com> wrote:
>
>
>  Dear all
> below are the minutes of the Atlantic Call.
>
> Regards
> Mavis
> --------------
> 0. Roll call
> Mike Grimley
> Tony Coates
> Sylvia Webb
> Zarella Rendon
> Betty Harvey
> Stephen Green
> Mavis Cournane
> Peter Borresen
>
>
>
> 1 STANDING ITEMS
>
>  Additions to the calendar:
>  http://ibiblio.org/bosak/ubl/calendar.htm
>
>  From Sylvia:
> 17th and 18th TaxXML F2F in Madrid. Sylvia will attend.
>
>  2. Review of Pacific call
>  Schedule review
> http://lists.oasis-open.org/archives/ubl/200602/msg00107.html
>
> Deferred
>
> 3. UN/UBL PROPOSAL
> The UN/UBL proposal has been discussed at length in the UBL TC calls.
> Our concerns regarding government adoption have been allayed by the
> statement issued by NES.
>
> Our conclusion is that we welcome and accept the proposal as put
> forward by Tim McGrath to the UBL List.
>
>
> 4. BRUSSELS UBL TC MEETING
> PB: NES would like to present to the UBL TC on the 25th May in Brussels
> about their work.
>
>  Action: Jon to send out strawman agenda and add this to it.
>
>
> 5. ACTION ITEM REVIEW
>
>  ACTION: Northern European, Asian, and other government
>  stakeholders need to tell us this week whether the level of
>  recognition seen in the draft agreement is enough to make them
>  feel comfortable moving ahead with UBL 2 adoption.
>
>  Status: Resolved
>
>  ACTION: MC to contact LSCs for reports.
> Status: Resolved
>
>  ACTION: PB to check out facilities for our May meeting in
>  Brussels on his visit to CEN/CENELEC 11 April.
>
>  Status: PB Awaiting confirmation. It will be either the Hilton or the
> Radisson
>
>  6. NDR WORK SESSION
>
>  Extension:
> MG: The priority is getting the rules right. We broke the rules out in
> to two separate rules. Rule 1 is the complex type definition.
> Two options were provided.Option 2 is the NDR editors preference. The
> xsd:Any element must not be used EXCEPT within the UBL extension type
> definition.
> Agreed
> Rule 2 - THe UBL extension element must only be declared following the
> UBL version element.
> Agreed
> Attributes are not allowed. What Brian proposed is Danish metadata and
> should be in their own customisation and should be in elements.
>
> 7. Code lists:
>
>
> A. Sylvia worried about qDT schema.
>
> B. Tim states that uDT is no longer needed.
>
> SG: PSC decided on a methodology. URLs will be used for genericode
>  components within spreadsheets.
>
>  Current proposal is to use a relative location for the URLs.
>
>  The following 3 things are needed.
>
>  1. Need a place for the genericode list.
>  2. Need to add further code for transport.
>  3. NDR need attributes but don't want the
>  attributes fixed in the schema to be
>  default.
>
> Actions:
> SG send list of attributes. Discussed
>  through email and for decision on
>  Wednesday's Atlantic call.
>  SW: does not understand why enumerations in
>  genericode list in the qDT unless they are
>  restrictions. A qDT is a restriction on
>  the base list on the uDT.
>
>
> 7. OTHER BUSINESS
>
> - Final Date for adding new content
> Sylvia wants a cut off date for adding new content. Coming out of the
> public review Sylvia suggests that this forms a future content release.
> Suggestions coming out of the public review are so extensive that they
> would radically change the current content.
>
> It is only the base UBL messages and Library that is the concern here.
>
> Proposed: Any content not on the public review content sheet will not
> be part of the UBL 2.0 content package without prior agreement of the
> entire UBL TC. The PSC will need to follow this process.
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. You may a link to this group and all your TCs in OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. You may a link to this group and all your TCs in OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>
>
>
>
>
> --
> regards
> tim mcgrath
> phone: +618 93352228
> postal: po box 1289 fremantle western australia 6160
> web: http://www.portcomm.com.au/tmcgrath
>