Re: [ubl] A discussion topic for Manhattan - modelling UBLExtensions

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

I see this as part of the customization package.  That is, using 
UBLExtension effectively to maximize the possibilites for 
interoperability.  The UBLExtension structure is a technical device to 
permit schema validation but it does not change the need for extensions 
to be customized consistently.

In my mind the process is:
a. extensions are designed (hopefully using the UBL approach - that we 
are still defining)
b. developers may choose to implement this as UBL extension or 
standalone schemas or do validation in other ways (schematron, etc)

the choice of (b.) should not affect (a.)  That is we design these 
extensions the same way regardless of implementation.

And so apart from saying the above, we cannot say much in the Update 
package without referring to the Customization paper.

Have I got your concerns right?

G. Ken Holman wrote:
> Hi folks!
>
> I just remembered one topic I would like to bring up for discussion in 
> Manhattan regarding UBL 2.0 Update is that the documentation of the 
> <UBLExtensions> element was treated in UBL 2.0 solely as a 
> document-model-expression modification/adaptation.
>
> In the process of re-issuing the spreadsheets in UBL 2.0 Update with 
> repairs for the descriptions and other spreadsheet columns, I would 
> like us to consider repairing the spreadsheets with the addition of a 
> row representing the <UBLExtensions> element in each of the maindoc/ 
> document spreadsheets, thus treating this element as a first-class 
> construct in the model.
>
> This begs, then, how we should document the descendants of 
> <UBLExtensions> also as first-class objects.  For example I'm not 
> convinced they should be included as part of the Common Library.  
> Rather they could be treated as a customized spreadsheet along the 
> lines of the separate spreadsheet for qDT that has a different 
> selection of columns that than for the elements.
>
> This is not a normative change, as the schemas are not impacted by 
> this one iota.  My higher-priority intent is to reflect the normative 
> <UBLExtensions> element found in the schemas in the 31 document model 
> spreadsheets where it is used.  Of lesser priority to me, documenting 
> all descendent elements in a similar fashion would help implementers.
>
> I acknowledge it may be far too late for considering this as part of 
> UBL 2.0 Update, but I didn't want the subject to be lost again to my 
> memory.
>
> Thanks!
>
> . . . . . . . . . . . . . . Ken
>
> -- 
> World-wide corporate, govt. & user group XML, XSL and UBL training
> RSS feeds:     publicly-available developer resources and training
> G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
> Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/o/
> Box 266, Kars, Ontario CANADA K0A-2E0    +1(613)489-0999 (F:-0995)
> Male Cancer Awareness Nov'07  http://www.CraneSoftwrights.com/o/bc
> Legal business disclaimers:  http://www.CraneSoftwrights.com/legal
>
>
> ---------------------------------------------------------------------
> 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
>

-- 
regards
tim mcgrath
phone: +618 93352228  
postal: po box 1289   fremantle    western australia 6160
web: http://www.portcomm.com.au/tmcgrath