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

["G. Ken Holman" <gkholman@CraneSoftwrights.com>]

At 2004-06-21 22:45 +0100, Stephen Green wrote:
>I thought your advice to Jeffrey was just the sort of advice I'm after
>for defining a small business profile without necessarily wishing to have
>any side affects on instances beyond defining a convenient, proposed
>standard subset of UBL suitable for small finance apps and spreadsheet
>accounting systems while allowing the small businesses the benefit of having
>the standard 'vanilla' UBL namespaces and all the legal standing that may be
>attached to these in their trading documents.

I've just attempted some words in my response to Sylvia where I distinguish 
"normative constraints", "derived constraints" and "supplemental constraints":

   http://lists.oasis-open.org/archives/ubl-dev/200406/msg00028.html

>Given then, obviously, that the proposed small business profile would be
>a much more radical restriction of UBL orders, invoices and perhaps other
>documents than the restriction of a codelist Schema down to one code,
>what would be your advice about using XSD, Relax and/or Schematron
>to define such a subset?

I would see W3C Schema as suitable for derived constraints that are 
obtained importing and redefining the normative constraints using the XSD 
techniques that guarantee that subset constraints do not violate the whole 
set of constraints.

I would see ISO/IEC 19757-2 RELAX-NG and ISO/IEC 19757-3 Schematron as 
suitable for supplemental constraints used in parallel with the mandatory 
use of the normative constraints.

It will be exciting to see an implementation of ISO/IEC 19757-10 DSDL 
Framework, but I don't know when it will happen.  There may be a role for 
ISO/IEC 19757-4 NVDL (Namespace-based Validation Dispatching Language), but 
I'm not sure.

>The main factors to consider might be the following:
>
>1. the definition of this subset might be the primary requirement and
>validation
>secondary (perhaps, what do others think?)

Sure, since validation is the less important bit ... knowing what to 
validate is most important, and people can then choose one or perhaps many 
different ways to perform the validation.

>2. the instances should still primarily be valid against unchanged UBL
>normative Schemas (hence the same namespaces)

I think that is sacrosanct and using W3C Schema imported restriction 
derivation gives us that automagically.  For other techniques to be 
categorically precise would probably need the supplemental constraint 
expressions to be derived from the definition you describe in (1).

>3. the definition should be worthy of being considered normative

Sure ... perhaps with one or more normative expressions to express the 
constraints of the definition.

>4. the objective is to provide a standard profile, widely accepted in
>software design such that software of larger businesses can send messages
>taylored quite generally to small businesses' needs

Sounds good.

>5. ultimately there might be a context attached to such a profile such that,
>as
>Chee-Kai pointed out, context-aware software can recognise, say in ebXML
>CPAs
>or the WS equivalents, the need to send documents which comply with the
>specified profile so that the receiving software can understand the message
>(this, I guess, could be added at a later stage so if it does require XSD,
>it need
>not mean that an alternative means be used at this stage in defining the
>subset)

Hmmmmmmm ... such context would be out-of-band to the UBL instance unless 
we could squeak into the normative definition a placeholder context 
description with open-ended values.  The supplemental and derived 
constraints would be able to successfully constrain a particular context by 
the presence of the value in the placeholder, but one would need a scheme 
for how contexts could be further contextualized.

>6. this is a radical pruning of the whole UBL model with the emphasis on
>simplification
>and limited functionality software or tools

Sure ... that would meet a large user base without impacting on the user 
base interested in full UBL.

>7. hopefully we won't have to resort to a prose spec or just have to define
>the subset
>with a spreadsheet or table -
>something closer to what an application can read would
>presumably be preferable

That's an implementation detail ... let's focus on defining *what* the 
small business profile contains, and then we'll look at how the subset gets 
expressed.  Provided we continue to use tools for the profile definition 
(like spreadsheet tools), there should be an opportunity for 
automation.  If we discover we need the description expressed using more of 
a formalism, we can make a formalism the normative expression of the 
description.

But given the XML base of Open Office tools, we should be pretty safe.

>Sorry to be asking for the earth here.

I don't think you are asking for too much at all.

>- I believe there are many asking for such a profile

We implementers needed to know this and it is exciting to be in a position 
to make UBL more implementable to more people.

Thanks again, Stephen, for your hard work.

.......................... 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