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