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] Applicability of 'Forwarding instructions' in the absence of an ordering context


Jon,

It's interesting to compare this to the DOJ NIEM approach. They too have used CCTS and NDR to define a vocabulary of deliberately overly inclusion components for use in 7 domains relating to government - Emergency Management, Immigration, Infrastructure Protection, Intelligence, International Trade, Justice and Person Screening.

They have an online tool available from http://www.niem.gov - that allows you to search and select that metadata vocabulary of components and generate your own schema subsets (SSG) for use in actual exchanges - essentially creating transaction structures on the fly from the common lexicon sets.  There is also extension mechanisms so you can add localized components or extend existing NIEM ones.  [Note: the SSG saves selections to a specialized wantlist.xml so changes / additions can be made later - and also figures out the dependencies for you - most of the time!].

This certainly requires a strong knowledge of XML, schema, the domain lexicons and modelling in UML - and they teach a one week class to prepare people on that.

The OASIS Emergency TC has created transactions that combine NIEM components with CIQ - specifically the EDXL xsd's currently out for review - and that work is continuing jointly with the NIEM community (aside - great advert for collaboration between standards groups).

Implementers of course then build to these derived schemas - so you end up with the same conformance / compatible with combination that UBL has adopted around schema and semantics.

I guess the NIEM approach equates to the UBL subset one - where people are free to dominate new subset derived schemas back to UBL for inclusion in future releases.

Anyway - there may be things in NIEM that could be instructive for future UBL approach definitions...

DW

"I love deadlines. I like the whooshing sound they make as they fly by". (Douglas Noel Adams 1952 - 2001, author Hitch-Hiker's Guide to the Galaxy)


> -------- Original Message --------
> Subject: Re: [ubl-dev] Applicability of 'Forwarding instructions' in
> the absence of an ordering context
> From: jon.bosak@sun.com
> Date: Wed, February 20, 2008 9:44 am
> To: ubl-dev@lists.oasis-open.org
> 
> [stephengreenubl@gmail.com:]
> 
> | I have some reservations about how general statements in the main
> | body of the UBL 2 spec relate to conformant use of the UBL
> | document types, in comparison to the weight of the schemas and
> | their definitions.
> 
> There's no comparison between the two.  The process descriptions,
> are, strictly speaking, semantic; that is, they provide the
> semantic context for the schemas.  Part of the answer to the
> question "What's an Invoice?" is that it's the thing that fulfills
> the role of Invoice in the relevant process diagrams.  But the
> description does not limit your use of an Invoice document.  This
> is stated at the beginning of Section 4 of the UBL 2.0 Standard:
> 
>    The processes described in this section, and the business rules
>    associated with them, define a context for the use of UBL 2.0
>    business documents. They are normative insofar as they provide
>    semantics for the UBL document schemas, but they should not be
>    construed as limiting the application of those schemas.
> 
> The distinction is critical from the viewpoint of standards
> development because it makes clear that UBL is not an initiative
> to define process conformance; if it were, we'd still be years
> away from producing anything useful.  It's an initiative to define
> document conformance.
> 
> | As such I would interpret UBL's conformance requirements (still to
> | be fully elaborated in the forthcoming Customisation Guidelines)
> | as implying that as long as the use of the documents doesn't
> | contravene the document definitions found in the schemas then
> | reuse of the documents is OK without change when the instance
> | structure, semantics and syntax conform to the schemas.
> 
> It's actually even looser than that.  The Customization Guidelines
> are still a work in progress, but we've arrived at a very clear
> distinction between *conformance* and *compatibility.*  From the
> latest draft:
> 
>    2.1.1. UBL Conformance
> 
>    UBL conformance at the instance and schema level means there
>    are no constraint violations when validating the instance
>    against a standard UBL schema. A UBL conformant instance is an
>    instance that validates against a standard UBL document
>    schema. A UBL conformant schema is a schema that will validate
>    only UBL conformant instances.
> 
>    2.1.2. UBL Compatibility
> 
>    To be UBL compatible means to be consistent with the principles
>    behind UBL's models or their development. These principles are
>    defined in the ebXML Core Component Technical Specification and
>    the UBL Naming and Design Rules. While we cannot assume
>    conformance and interoperability of these customized documents,
>    we can expect some degree of familiarity through the re-use of
>    common objects.
> 
> | I don't think it has yet been made a firm conformance requirement
> | that a document's use match the UBL 2 spec process diagram and
> | description.  Otherwise this would need to be added to the
> | Custmisation Guidelines document and I don't think this has been
> | included in the latest draft.
> 
> Adherence to the process diagrams will never be a UBL conformance
> requirement.  As noted in the definitions above, UBL conformance
> is a strictly mechanical concept that has only to do with
> validation against the Standard schemas.  Compatibility, on the
> other hand, does depend on semantic alignment, and defining this
> dependence cleanly is still a near-term work item for the
> Customization Guidelines.  Whether adherence to the process
> diagrams is a requirement for compatibility (as opposed to
> conformance) is an interesting question, and I thank the group for
> raising it as an issue.
> 
> Jon
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org


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