Re: [ubl-lcsc] Packaging team call

[Anne Hendry <anne.hendry@sun.com>]

a) and b) were discussed in the coordination call and I'm sure Jon will 
send out a recap shortly.

Regarding (b) I agree that the sdt would then effectively become the set 
of cl schema files, and your naming does help to make this apparent.  I 
think the only question is whether not having a specific sdt separate 
schema module precludes having one in the future, and also a recent 
question from Stephen as to whether we do want to put some of the really 
set-in-stone ubl code lists enumerated into the sdt so they couldn't be 
swapped out so easily.  Most of those have less than 5 values, so it 
wouldn't be a huge long list.  Not sure about future ramifications, though.

c) I've sent mail to David asking what format he would like to see. 
 Whatever format I use should resemble what goes in the final files if 
at all possible, so I'll wait to hear from David on that.  These are 
data files for processing, so don't show up in the final schemas, so I 
don't think clsc cares, it's a straight tools issue.

On separate threads there has been some conversation about the extra 
components listed in your sdt spreadsheet model that are not part of the 
cct code list type and I think there's agreement that those don't belong 
there.,  Couldn't the 'description' and 'credits' go into documentation? 
 For  Beta we put this information in the header comment block.  Is 
there a need to put them elsewhere?  If not, then the tools just need to 
decide how to deal with it.  David's lastest email is asking about this. 
 The other is codelistnamespaceprefixid.  This is no longer needed, correct?

-Anne

Tim McGrath wrote:

> unfortunately, i cannot make this call but it would like to make sure 
> a few items get onto the agenda (i am sure they will anyway, but i 
> want to add my little bit).
>
> a. the pros and cons of  substitution/abstract (are these the same 
> thing?) is a side issue.  the time for debate is past - we should 
> adopt marty's architecture as is.  it is the only practical option we 
> have (and i personaly think it is an elegant one).  the fact there is 
> a NDR against this means the NDR needs re-examining not the code list 
> representation.  i thought that is what we had said since washington. 
> code list will drive NDRs.
>
> b. it now appears from the code list representation mechanism means we 
> have nothing to put in our 'specialised data types' schema.  i think 
> this is OK and in the spirit of the CCTS.  the question is whether we 
> should still have a placeholder/null SDT schema (a bit like we did in 
> 1.0-Beta) or just drop it.  this means we need to make adjustments to 
> the schema modularity diagram (which we have to anyway as we have 
> dropped the CLUDT schema).  again, i see no issue with doing this.  
> this modularity suggested in this diagram is an NDR in progress. as we 
> develop and implement the code list representation we should be able 
> to improve/simplify it. (see attached possibility)
> perhaps we can satisfy everyone by naming the Code Lists Schemas 
> something like 
> UBL-SpecialisedDatatype-CurrencyCode-Use-1.0-draft-8.xsd to indicate 
> their role as SDT definitions.
>
> c. can i ask if the CLSC made any decision on the source format for 
> Code.Content and Code.Name (anne's data capture task)? given the 
> syntax of the code list representation, it may be simpler just to hand 
> code these directly in the final syntax (ie as enumerations) rather 
> than mock up our own syntax (that i made up), then load this into 
> EDIFIX and have it generate the enumerations.  i am willing to do some 
> editing if necessary.
>
> d. we are very close, but still lacking an end-to-end example of code 
> list usage.  having made decision about the above and before we get 
> GEFEG cutting code it may be a good idea for Stephen to apply this to 
> his sample documents (or a fragment of them) and demonstrate from 
> model to instance using a standard code and a non-standard (as a 
> comparison).
>
> jon.bosak@sun.com wrote:
>
>> I suggest that we use some of the Packaging Team meeting (Friday
>> 12 March at 8 a.m. California time) to discuss schema coordination
>> as well.
>>
>> Jon
>>
>> 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. 
>>
>>
>>  
>>
>
>
> ------------------------------------------------------------------------
>
>------------------------------------------------------------------------
>
>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.
>