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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-lcsc message

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


Subject: Minutes 9 March 2004-TeleCon Mtg.


1. Welcome from Chair (Tim) and appointment of Secretary (Lisa) to take
minutes.

Attended:  Lisa Seaburg, Tim McGrath, Michael Dill, Stephen Green, Anne
Hendry, David Kruppke, Peter Yim.


Open Discussions:

Lisa: The NDR document Codelist section 6 is not up dated to what the
Codelist paper says.  The NDRSC is waiting for further development.  Michael
and David are wondering which rules to follow, and Tim is saying go with the
Codelist paper rules.

David is finding some problems in trying to make the autogenerated schema
generator work, Tim's feelings are that we need to move forward with
creating something we can implement, and if necessary, go back and change
the rules to match that.  The Code List Representation paper does not take
into account the moving representation types.  In other words it is based on
a broken historical model.

We are hoping that the Codelist group will be updating their structures to
be the same as the ones Michael and David are working on.  The schema they
are building right now is not necessarily the final ones, but will be
working toward making those final schema.

Having a clear definition of what the codelist representation.

**Action Item:  Lisa: Get the document of Tim's issues from Mavis or Mike.


2. Action Items

Michael - extract terms for controlled vocabulary from the UBL
spreadsheets - Open.
 Still open, low priority.

Tim - CHECK OUT CREDIT CARD ISSUER/OWNER. - Open. we have to make a decision
on this.  We put out a request to Polly Jan.  We have not heard back.  Tim
will go back into notes to summarize options.

Sue and Anne prepare draft vocabulary - Open, this won't happen until
release is out the door.  This is the controlled vocabulary.  Sue sent a
version of the TBG 17's version.

Anne - send the TTSC response to Tim. - Open. TO DO....

Tim - The Supplementary Components (SCs) would be remodeled in CCT, UDT and
SDT spreadsheets by Tim using the same sort of format as he had sent to the
list. These would include the use of naming rules to provide names (and with
DEN's as specified in the CCTS). Some incorrectly included SCs would be
dropped to comply with the CCTS. These models would be sent to Michael -
DONE, see discussion below.

Michael - generate Schemas, on Draft 7, there will be Draft 8 after the
discussion tomorrow after the CSC.

Sue - After LCSC populates the remaining SDT-based codelists, Sue would QA
them. - Open, Anne will be doing this.

Tim - review the CLSC Codelist Spec and send an update, particularly of
section 3 to CLSC. - DONE

Tim - copy an e-mail to Michael based on these decisions to CLSC. - DONE,
spoke on the phone.


3. 1.0 Release Package
- schedule
- issues:
Modeling CCT, UDT and SDT - One of Tim's action items was to prepare the
model for these modules.  This involved application of naming rules for
elements and attributes.  He also applied the XSD datatype for each
Supplementary Component.  This had been discussed on the call and also
through email.  We had reverted back to token, this was an oversight and it
is being fixed.  The understanding of the discussion (SF-Plenary) the point
was we believe identifiers and codes could contain embedded spaces, where
the spaces were significant.  It was recommended that we use
"normalizedstring", that is the preferred datatype for ids and codes.

The spreadsheets Tim has prepared used these new XSD datatypes.  Anne also
helped figure out which datatype is used for each component.  The theory is
that the schema generation will use those structures to create the CCT
schema, the Unspecialized and Specialized.

The version sent out yesterday (7.1) contains the new structures and the
correct datatypes.

Versioning on the drafts coming out.  Draft 7 relates to the models, the
deltas are the different generation of the schemas.  If the spreadsheet
changes then the draft number changes.

Following on from that the models should be checked in everytime there is a
new version, through Bill Meadows and uploaded onto the LCSC website.  The
schemas will be checked in through the TTSC webpage.
We back this up by sending several notices.  Anne and Bill feel that they
belong together on the one site.

Michael: David is not on the UBL list and therefore has to send under
Michaels account.  Sending data back and forth directly.  David needs to be
treated independently and also CC him on this stuff.

The subschema's are now pretty clear, but we need clarification about

There was some discussion at the Plenary that this whole architecture could
be simplified by not having a CCT module.  People implementing UBL never
really see it.  But, we are already so committed to go back and do this now.
It may be an

Definitions of Schema Modules:

SpecializedDatatypes, these are the ones that can be customized by the user.

UnSpecializedDatatypes, these are the ones that don't change.

**Action Item:  Lisa to pull together the definitions of the schema modules
and try to pull together the information and put it out through email for
everybody's help.


Modeling Code List values,
The Specialized Datatypes model and schema is the mechanism we are using to
do codelists.  Specifically it is being used for the 9 or 12 standardized
codelists that are in the 1.0 model.  Tim went through and reformatted the
spreadsheets, he added the 12 codes as additional columns.  They are not
really columns in the model.  We are trying to populate instances of the
specialized datatypes.

Each is like a separate datatype.  It seems like we are populated one
datatype 12 times.  But we want to see them as separate datatypes.  It is
proposed to rearrange the model to be vertical instead of horizontal, so
there are 12 different datatypes.

The model says we are allowed to restrict, but we are not allowed to extend.
We don't need to show every single Supplementary Component.

There is some confusion about what the namespace prefix was decided on.  It
seems to be optional at this point.  The decision as to whether or not it
appears in schema is that it is in the namespace.  It can be based upon what
is said in the Section 4.4 in the Codelist paper.

We are a problem with codes that began with a numeric character.  The values
in the Supplementary Components

Channel codes - if you have a BBIE called Channel Code, you can associate it
with different datatypes depending on how you use it.  If someone wants to
create a new element with their own code, then they would create it.  When
there are two elements say Channel Code, they belong to two different ABIEs.
There shouldn't be a name clash, they have different namespace prefix, we
also want to associate different codesets to those.

**Action Item:  If there are changes to the schema output for David to try
to make, please send a schema sample to David of what it is supposed to look
like.  This will help us from any misunderstandings.

**Action Items:  Anne: putting together the values for the codelists.  Send
them to Michael and Sue when done.

If we populate the current used codelists in the 1.0, there shouldn't be any
changes.

There are currently no schema with the codelists yet.  We need to produce
them and plug them into the correct place.  For the GEFEG group this will
become 7.2, generate schema again including the codelists this time.

There is not restriction on how many versions of the schema is produced.
Just keep track.  Anne says there is a set of code list schemas in 7.1.

When we create a specialized datatypes, we give it a name.  Example the ISO
4217-alpha, we named it 4217, we can't have numbers beginning the names.  We
have to change these names, so we need to change it in the schema.  We need
to figure out what is the legitimate way of doing this.

Is it possible to replace one datatype with another datatype?

Since we include an enumeration in the schema, should be have the
representation term of the BBIE to include the enumeration?  We have not
allowed any plug and play at this point.

Two choices:  First:  We are using the specialized datatype, to become a
representation term qualifier, and therefore the name works and everything
works.  We would be creating a totally different BBIE, every instance has to
use the same alpha code.  Call it Alpha 4217 code.  Specify the physical
code list right up front.
OR
Second: we can create everything abstract.  It would only be in the
specialized, the point we decide which codelist we would use would be when
you define the specialized datatype we decide which code list it would
adopt.

This does seem to be the appropriate place.  It means is that instead of
having code list schemas called ISO 4219.xsd, we would have
currencycode.xsd.  This is not implied by the Codelist Representation paper.
There is that same argument on both sides.  We seems to be losing this in
between binding.  Is this second option really loose enough?

The SPDT schema can be replaced, it is a change in the namespace.
Technically what happens is when we have a new version, it becomes a new
namespaces.  The thing that needs to be updated is the SDT.xsd.  This makes
it slightly more convenient for us, but does it make it easier to customize.

If we leave it loose then the version can be updated.  If we hard wire it we
change have to have a new version of the whole UBL.  There is no way except
by customization.  Leave it up to the supplementary components to say what
version you are using.

We accept there is a problem here.  We don't have to maintain this forever,
this needs to be customizable.

Stephen explain what this model should look like:  Either one is okay for
UBL's own enumerations, it is not good for codelist, it binds people to
codelists.  We need to be able to change this out, especially with codelists
since they are changing all of the time.

The problem here seems to be (worst case) if someone chooses not to use the
standard code, then they have to create their own BBIEs.  Instead of the
standard code sets we are using, for those, option two method would make it
easier for users to make specialized datatypes for the codes that are
currently placebos.  They don't go change the UBL document models to add
their own codesets.

We need to make sure the model is the more abstract definition and the
schema has the more concrete definition of the codelists.  This would make
the use easier.  The documents and the reusable schemas.

**Action Item: Stephen will create a example that he can give to Michael and
David (will be vetted through the Coordination Call).  Remove the CLUDT.xsd
module, put all of the enumerations into the codelists schemas, and base the
codelist schemas on the CCT.xsd.  There will be multiple codelist schema
modules, based on the CCT instead of the USDT and SDT.  The theory also is
to get rid of the codelist schema modules.  Stephen will then send
information about this to the whole UBL TC.

There appears to be a need to rationalizing on why we have so many different
schema modules.  The whole thing could be for a more forward looking
reasons.  We don't want to have to make our work not as nice to just to give
them something they can use.  We need to have a 1.0 that works.

Simplifying could help us make this a better product in all.

The schema fragments that Marty was sending out are out of date.  He based
the paper on the broken way we were doing the codelists before the 1.0 beta.
He used things in the old schemas that are not CCTs and created new ones.

It is not for us to change the model to make this work.

The foundation upon which Section 4 is incorrect, Tim sent replacement for
Section 3, and he should be looking at the models.  The important one is the
Specialized Datatypes.  Section 4 needs to be redesigned to match the
architecture that is proposed still works.  It relied on properties that
don't exist.

It is based upon the representation term schema.  The contents of the USDT
schema module is different, the purpose hasn't changed.  The names of the
element have changed.

**Action Item:  Lisa will be on the CLSC call and bring forward the
discussions from today, along with the minutes from this meetings.

**Action Item:  Anne has agreed to populate the codelists that we are using.
She will hand them to Michael, David and Sue.


4. Other SC reports
- NDR - Lisa - no quorum, only discussed trying to keep the document more
up-to-date on the webpage.

- CLSC - ken/sue, no one on call.

- ISC - Anne, Open Office has created templates for UBL.  Lars did send to
the ISC.  Stephen Parker from Impaq is about to make an announcement.  Does
anyone know of an implementation of UBL that was done before Jan 5th.  We do
know that the Danish government implemented some of the .70 and so did
Hagemeyer NA.

- Tools and Techniques - Anne, feverishly working to try to reconcile all of
the of gray areas that exist.

- Localization - Tim, we have a new SC for Spanish in South America.  They
met a day ago, Chinese, Japanese were there.  The Japanese SC sent a
question about Allowance Charge and would like an answer on what this is
used for.  No one sees a benefit of having translated versions of schemas.
Consensus was not necessary.  Will be the same everywhere.  What they do
want to translate is the models.  They also discussed the control
vocabulary.  The other area of interest is customization.  They all have the
geopolitical context.  The objective of the upcoming Plenary in Hong Kong
will be customization.

- Context Methodology SC - Fabio is the new secretary.

5. Other Business

Stephen, are you (Tim) okay with the new worksheet in the spreadsheets, its
a TBG17 worksheet, if you add a line, you have to synchronize the two
together.


6. Adjourn: 11:28am CST - Next meeting:  Tuesday 16 March 2004


NEW ACTION ITEMS:

**Action Item:  Lisa: Get the document of Tim's issues from Mavis or Mike.

**Action Item:  If there are changes to the schema output for David to try
to make, please send a schema sample to David of what it is supposed to look
like.  This will help us from any misunderstandings.

**Action Item:  Lisa to pull together the definitions of the schema modules
and try to pull together the information and put it out through email for
everybody's help.

**Action Items:  Anne: putting together the values for the codelists.  Send
them to Michael and Sue when done.

**Action Item: Stephen will create a example that he can give to Michael and
David (will be vetted through the Coordination Call).  Remove the CLUDT.xsd
module, put all of the enumerations into the codelists schemas, and base the
codelist schemas on the CCT.xsd.  There will be multiple codelist schema
modules, based on the CCT instead of the USDT and SDT.  The theory also is
to get rid of the codelist schema modules.  Stephen will then send
information about this to the whole UBL TC.



Submitted by Lisa Seaburg, 9 March 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-lcsc/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
++++++++++++++++++++++++++++++++++++++++++++++++++++
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:20040309T173422Z
END:VCARD


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