OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [ubl-dev] ReceiptAdvice Help Needed


Thomas

Sorry, I should add that there is a cut-off point for 1.1
additions of content which is coming up very soon (can't 
recall the exact date but I think there's about a month
to go) so its probably not feasible for you to have a 
submission to that. So really it depends on whether folk in
UBL spot your comment here on this list (perhaps a comment 
too on the UBL comment page of the website might not go amis)
and decide to add it to the list of 1.1 content updates.

All the best

Stephen


>>> "Stephen Green" <stephen_green@bristol-city.gov.uk> 10/03/05 10:39:30 >>>
Thomas

There is a customisation methodology as a key feature of
UBL. It would be especially important if you wanted to keep
your use of UBL as 'conformant' or 'comlpliant' and to be
in a better position to exchange messages with users
of 'out of the box', uncustomised UBL. That seems to be
the official line anyway (the customisation document is
in the /doc/cm folder in the UB package or online at
http://docs.oasis-open.org/ubl/cd-UBL-1.0/doc/cm/wd-ubl-cmsc-cmguidelines-1.0.html).

Personally I'd consider any negative impacts of any
customisation on your adoption of future minor releases of UBL,
which, while seeking to maintain backwards compatibility
(with respect to instances and the W3C Schema derivation
mechanism) with previous releases of UBL do not necessarily
cater for backwards compatibility with customised versions.
I guess that keeping to the agreed customisation methodology, 
essentially by keeping to the UBL naming and design rules
in editing the Schemas and using W3C Schema (XSD) 
derivation, importing the UBL official Schemas and basing
any new types on those, I guess that this would help keep
you in a strong position with regard to future releases of UBL.

Happily, perhaps, your comments are likely to be noted in
the UBL modeling team and UBL is just now starting to model
a new 1.1 release so you might find something to fix this in
there (provided your issues are considered of sufficiently
widespread significance). If you can wait (perhaps to the end of
the year) for UBL 1.1 and petition perhaps for your requirements
with the UBL TC (have you access to a representative standards
body for your industry who might put a submission together
for UBL 1.1?) I'd suggest that that would be best. However,
if you can't or don't wish to do that, you could possibly keep
conformant with UBl by customisation in the way explained in the
link given above or just accept that you might be less conformant
but not in disgrace :-) just by adding what you need to your UBL
messages and giving the additions a new namespace perhaps.

That's my take, for what it's worth. I'm a little new to all this
myself and hoping to see how all the theory works out in
practise. My own experience of practise only includes the
use of include/redefine with another standard but I didn't
like that as it broke common sense in that XSD requires 
include to use the same namespace as the included Schema
(is this use or misuse of the standard?) and infact it resulted
in a non-standard message to some extent which would limit
the scope for reuse. I like the UBL Customisation Methodology
in that it offers a way to maintain more official conformance
while keeping pace with your own trading requirements - but
this could be a negative thing when trying to also keep pace
with new releases of the standard (e.g. if UBL 1.1 includes
your extra stuff and you've also added it yourself, it might
be tricky for you to update your messages, especially if they
include other or slightly different customisations to the
1.1 additions).

Aplogies for the long treatise :-)

All the best and good luck

Stephen Green



>>> "Seay, Thomas" <thomas.seay@xip.net> 10/03/05 03:49:43 >>>


<<UBL is much more suited to adding custom elements than what you may
be used to with EDI.>>

First of all, thanks for your kind response.  In regards to the above, how is that so?
It looks to me that adding a custom element would be violating the standard.  If there is
a means for doing this (adding my custom element without breaking the standard), I would be
very interested in learning about that.


Thanks for any help that might be provided in regards to this.

Thomas Seay
Xerox International Partners
thomas.seay@xip.net 




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]