RE: [ubl-dev] Creating a new document... where to start?

["Stephen Green" <stephen_green@bristol-city.gov.uk>]

Sylvia

There is an important difference with your solution -
it relaxes rather than tightens the UBL Schema.
This is extension rather than restriction in that it allows any
codelist for currency rather than just the ISO codelist 0.3

The net result is that your instance is valid with your 
Schemas but not with UBL-proper (or 'UBL-vanilla').

In this case I do think a new namespace *might* be 
warranted.

If you only intend the Schemas for internal use, though, I
see no harm. If they might be sent to a registry of sorts
then I'd say that where restriction is used such that instances 
valid against the adapted Schemas are always
valid against UBL-vanilla, then I'd sya the same namespaces
can be used (where the intention is for secondary validation 
and/or subset definition). But where there is extension, I'd 
say one should avoid 'xsd:redefine' and keep to what it
presently says in the customization methodology paper
(in the 1.0cd package). The same with any change (even
restriction) which allows instances which aren't valid by
the original Schemas.

Steve


>>> "Sylvia Webb" <swebb@gefeg.com> 22/06/04 16:37:11 >>>
Ken,

I agree with your assessment about using different namespaces. As an
example, I have created a simple subset of the UBL PO.  This subset simply
defines what I want to send to a trading partner. I call it a Profile
schema. It contains no changes to the basic UBL Purchase Order. It is a
definition of what my company needs. I am not aware of any UBL rules that
require that a new namespace be used in such circumstances.  If I am wrong,
please point me to the document and section that states this requirement. 

Sylvia


-----Original Message-----
From: G. Ken Holman [mailto:gkholman@CraneSoftwrights.com] 
Sent: Monday, June 21, 2004 8:38 AM
To: ubl-dev@lists.oasis-open.org 
Subject: RE: [ubl-dev] Creating a new document... where to start?


At 2004-06-21 08:10 -0700, Scott Wiseman wrote:
>I think you should publish your restricted schema under your own 
>namespace. This should help.

How would you assess the impact on existing applications or implementations 
that rely on instances that use the published namespace?  How would you 
characterize how doing this would help his situation?

I'm of the opinion anyone setting out their own namespace would be 
instantly isolated from an installed base of free and commercial 
technologies where programs are keyed to manipulating information in the 
UBL namespace.  Unnecessary transliteration would be needed to do any 
useful work.

I see the UBL namespaces and base schemas as sacrosanct and that any 
parallel or restricted applications will, by economic and technical 
necessity, not be in a position to introduce additions.

Yes, there will be communities who build on UBL with their own extensions, 
but that is because as a community they will have the support of users and 
vendors to take advantage of those extensions.

But the biggest community of users will be small business users who will be 
disenfranchised from UBL by any anything other than an absolutely strict 
subset expression of constraints to meet simple business requirements while 
simultaneously satisfying the complex business requirements for which UBL 
was designed.

Stephen Green's efforts to pull together a Small Business Profile for UBL 
are noteworthy and noble, and we should all rally behind him to help him 
assess what the balance is to meet small business requirements sufficiently 
with as useful and compact a subset of UBL as possible.

Should the original poster use their own namespace, they would not be able 
to run their instances against freely-available stylesheets or upcoming 
commercial and free implementations of UBL-based systems, unless they went 
through a "translation step" to the standard UBL subset.  Why not just 
stick within the subset by using the UBL namespace provided that nothing 
expressed in the subset is going to violate the constraints of the original?

................... Ken


--
Public training 3 days XSLT & 2 days XSL-FO: Phoenix,AZ 2004-08-23
World-wide on-site corporate, govt. & user group XML/XSL training.
G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com 
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/u/ 
Box 266, Kars, Ontario CANADA K0A-2E0    +1(613)489-0999 (F:-0995)
Male Breast Cancer Awareness  http://www.CraneSoftwrights.com/u/bc 
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal