[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl] A discussion topic for Manhattan - modelling UBLExtensions
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]