Re: [ubl] Re: UBL and OAG Common Core Component schemas

[Tim McGrath <tmcgrath@portcomm.com.au>]

apart from the embarrassment of asking GEFEG to do another round of 
modifications, I see no reason why we shouldn't try to achieve all the 
immediate  issues.

this will depend on how we stand by friday's call, but none of these 
changes are significant. (see my comments inline)

PS
one of the things we also need to consider is how we address the open 
work items.

>2. Use of XSD normalizedString for code, identifier and text
>   components
>
>   Our action would be: 
>
>      UBL consider the built-in XSD type,"normalizedString", for
>      all text components (where there is no specific built-in
>      type, such as "language").
>
will involve a minor model change (draft 13!)

>3. Use of XSD built-in dataypes requiring format Supplementary
>   Component (Date Time, Indicator and Numeric)
>
>   Our action would be:
>
>      UBL consider relaxing NDR rule STD1 to allow adoption of the
>      OAG approach.
>
>   Two questions here:
>
>    - Are we OK with changing our rule to accommodate convergence
>      with OAG on this item?
>
>    - Is this something that we can accomplish within our current
>      schedule?
>  
>
this means reverting to what we had in draft 9 (and again involves a 
minor model change)

>4. Restrictions on Binary Object for Graphic, Picture, Sound and
>   Video data type
>
>   Our action would be:
>
>      UBL consider adopting OAG restrictions for Graphic, Picture,
>      Sound and Video data type.
>
>   Is this something we can accomplish within our current
>   schedule?
>  
>
again a modeling change (our current one is incorrect anyway).

>5. Patterns for Indicator data type
>
>   Our action would be:
>
>      UBL consider adopting OAG pattern of "true" and "false" for
>      the Indicator data type.
>
>   Is this something we can accomplish within our current
>   schedule?
>
we don't currently deal with facets at all so we need to change the 
model and code this into the generator.

alternatively it could be manually edited after the fact to keep us on 
schedule (and we can do the right thing subsequently).  

i should confess that this pattern was in the original representation 
term/unspecialised data type schema :-[

>  
>
-- 
regards
tim mcgrath
phone: +618 93352228  
postal: po box 1289   fremantle    western australia 6160