MHonArc v2.5.0b2 -->
ubl message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [ubl] Re: UBL and OAG Common Core Component schemas
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]