Re: [ubl-dev] looking for practical examples

[Stephen Green <stephengreenubl@gmail.com>]

Hi Ken

I had, like you say, dismissed the thought of using redefine or
substitution groups for customisation. What I'm thinking of here
is the way someone might produce a document schema as a
new namespace document reusing much of the standard set of
schemas.

Like this:

[Custom Doc Schema] ---imports-->[Standard Doc Schema]----imports---->...
                               |                         |
                               |
`---imports--->[Standard Common Schema(s)]---...
                               |
                               |
                                `---imports--->[Custom Common Schema(s)]
                                                         |

`---imports--->[Standard Common Schema(s)]---...

or

[Custom Doc Schema]
                               |
                               |
                               |
                               |
                                `---imports--->[Custom Common Schema(s)]
                                                         |

`---imports--->[Standard Common Schema(s)]---...

or

[Custom Doc/Common Hybrid Schema] ---imports-->[Standard Doc
Schema]----imports---->...
                                                       |

`---imports--->[Standard Common Schema(s)]---...

There is no XSD derivation here, just plain old reused schemas. There
might be cases of
two imports for the same namespace but maybe that is OK.

If my custom document needs to extend the CatalogueLine (e.g. to make
an InventoryLine,
as in our previous case), remind me, can't I just create a new custom
'common' aggregate
schema with the new InventoryLine which imports most of the types and
elements from
the standard common schemas but adds a new basic entity element. This
gives me the first
choice (which might need an Naming and Design Rule) - whether to put
the new basic element
and type in the same schema as my InventoryLine or whether to separate
it like Standard UBL
into another common schema for basic entities. Then I need to do
something to make the
'common' (reusable) InventoryLine and its extra entity available to
the custom document (say,
Inventory document). Here comes the second choice - do I need to
create another schema
as a document schema (like Standard UBL/NDR) or just put the custom
document element
and type into the same schema as everything else (if the previous
choice resulted in just the
one schema for the 'common'/reusable stuff). A further choice is
(perhaps a no-brainer) whether
or not to import the Catalogue document schema: I guess the no-brainer
answer is 'no' (but it
might not be so obvious if I was creating my own custom version of and
existing UBL document
like an Invoice).

Would all this create namespace clashes? I wouldn't think so but would
have to try it. What it
does do is lend itself to using UBL Naming and Design Rules only
slightly adapted for custom
schema creation and including all the CCTS stuff like ISO 11179 data
dictionary names, etc.
This allows better harmonisation and mapping with the standard UBL and
with other similarly
designed (same extended NDR) custom documents. It then seems
irrelevant whether I am
creating a new document type (like Inventory), just reusing common
entities, or calling my
document the same name as a standard one (but with my own namespace(s)).

Is there no provision for any of this in customisation guidelines? Or
is it assumed that there
will always be wholesale replacement of all the schemas. Now comes an
important bit it seems
to me: if I do rewrite the schemas, can't I do it like above to put
the new entities into separate
schemas anyway? If so wouldn't that still require a set on new NDRs -
maybe that is why it
seems to not be the approach with 2.1. But with 2.1 there is liberty
for the TC to rewrite all the
schemas: Not such a simple task for a customizer perhaps. They might
prefer to point their
new schemas' imports at (at least) the standard common schemas to
avoid too much change
for implementations. If there were rules for doing this it might help
interoperability across
implementations which use these rules and aid interoperability efforts
like SET to ensure tools
could cope with such custom schemas.

Best regards

- Steve



2009/2/13 G. Ken Holman <gkholman@cranesoftwrights.com>:
> At 2009-02-13 07:40 +0000, Stephen Green wrote:
>>
>> I'm not entirely OK with the diagram.
>
> Feedback is good ... thanks for this note.
>
>> I had envisiaged something
>> more along the lines of augmenting rather than replacing the
>> common schemas. I had thought, to meet the cust guidlines we
>> requirements, we would suggest people keeping all of the UBL
>> OASIS standard schemas intact and adding the custom types in
>> additional schema(s).
>
> I thought back in 2006 (2007? 2005?) you and I were unable to successfully
> achieve this with W3C Schema constraint semantics and constructs.  I'm
> supposing from my knowledge of W3C Schema you are suggesting we redefine the
> base constructs with new definitions.
>
> Since we are focused here on subset schemas (extension schemas are in
> different namespaces), wouldn't this require creating a redefining schema
> that redefines all of the changed constructs (which is what I'm doing in my
> replacement schema), and leave all of the unchanged (and possibly unused)
> constructs intact?  And some users may not want the unused constructs taking
> up cycles in their schema processing.
>
> Then the document schema itself would have to change in order to import the
> redefining schemas instead of the original schemas.
>
> When you and I looked at it I thought we could not find any convenient,
> elegant or even fully functional way to cover all the bases required for
> schema subset customization.  I was convinced at the time it couldn't be
> done and haven't looked at it since.
>
>> Then the choice would be whether to put all
>> the new elements and types into just one custom schema (which
>> imports the UBL common schemas) - with the document element
>> as root - or whether, like with the UBL standard schema modules,
>> to split the schema into either two or three - either {document plus
>> custom basic schema plus custom aggregate schema} or
>> {custom document schema plus custom common schema}.
>
> In W3C schema, each fragment can define constructs for only one namespace
> (unlike constraint languages such as RELAX-NG).  We would need "parallel"
> fragments for each fragment ... which is what I already have ... but
> avoiding the complexity of redefinition and implemented simply with schema
> replacement.
>
> I understand other companies with schema subset specification tools are also
> creating replacement schemas.  The difference as I've come to understand is
> that their schema fragments are wholly reconstituted from abstract
> representations, whereas my schema fragments are mechanically processed from
> the OASIS fragments with unused constructs simply commented out.  Someone
> looking into the fragments my software produces will actually see the
> original OASIS constructs inside, as I preserve everything that was changed
> from the original.
>
> I see the use of W3C Schema redefine is not covered in NDR 2.0, whereas the
> schemas my software produce satisfy NDR 2.0 because they are using
> mechanically processed from NDR 2.0 compliant fragments.
>
>> Also
>> there would need to be a guideline on how to do the imports -
>> whether, say, the custom document schema imports everything
>> or whether the custom common schema(s) import their respective
>> standard schemas and are imported by the custom document
>> schema.
>
> I'm assuming above you mean "how to do the redefines" since the importation
> is based on namespaces.  Though as I said above, there is no way for the UBL
> document schema to import the redefined common library schemas without
> changing the files the import statements point to, so again you have to
> actually touch the document schemas.
>
> I've come to the conclusion in my own work and teaching that fragment
> replacement of NDR 2.0 compliant fragments synthesized from delivered UBL
> 2.0 fragments is easily understood, very robust and has a built-in audit
> trail for anyone "not trusting" the integrity of reconstituted schema
> fragments they may be using.
>
> I would *welcome* a working demonstration of W3C Schema compliant fragments
> that can achieve the redefinition incorporating untouched UBL 2.0 fragments
> ... but that is beyond my ken.  And I would weigh the end-user impact of
> that approach against the approach I've described when using my tools ...
> which would be easiest for them to understand and deploy.  I felt if they'd
> already deployed the UBL 2.0 fragments, they'd be aware of how to deploy the
> subset version of the UBL 2.0 fragments.
>
> Can anyone on this list demonstrate the use of W3C Schema redefine
> incorporating untouched UBL 2.0 fragments?  Given the industry's lack of
> consistency in the implementation of redefine, would this demonstration work
> across multiple W3C Schema implementations?  (I embarrassed myself earlier
> in the UBL TC work by improperly relying on Xerces's and MSV's incorrect and
> inconsistent behaviours at the time for other aspects of UBL)
>
>> Thinking of the possibility of using SET (OASIS SET TC)
>> tools for interoperability between custom and standard documents,
>> I'd suggest the guidelines might consider how to ensure the design
>> provides a consistent data dictionary within the schemas with a
>> use case that SET schema to OWL tools can create their OWL
>> ontology from the custom schema set (including the standard
>> UBL schema set). The aim would be to ensure a set of tools can
>> ascertain what impact the customisation might have on any existing
>> implementation based on the standard UBL schemas.
>
> Shouldn't that assessment be at a more abstract level?  Shouldn't the schema
> artefacts be simply synthesized from the abstraction?  That is what I'm
> doing with the subset specification in OpenOffice:  one deals with that in
> the spreadsheets and then presses the button to get the schemas, which
> happen to be synthesized by using the original schema fragments as input,
> and conform to NDR 2.0.
>
> Thanks for the discussion, Steve!  I've only just proposed to the UBL TC the
> inclusion of these diagrams, so we'll see how the discussion ensues there.
>  But I welcome more discussion here, especially from outsiders trying to
> understand how they would specify a conformant subset of UBL.
>
> And now would be the time for someone to present how to do all of this with
> W3C Schema and untouched UBL 2.0 fragments.  I don't think it can be done.
>
> . . . . . . . . Ken
>
> 2009/2/12 G. Ken Holman <gkholman@cranesoftwrights.com>:
>> At 2009-02-10 19:13 +0000, Stephen Green wrote:
>>>
>>> 1. Create a new document called, say, Inventory - with your own
>>> namespace for the document but import the common schemas so
>>> you can make it almost the same as the UBL Catalogue - just with
>>> a new InventoryLine, like Ken says, which adds StockQuantity or
>>> something like that (and maybe a few more things like that). There
>>> are a few things to make the writing of the schema (like Ken, I too
>>> strongly recommend keeping to a schema - testing the messages
>>> that they are valid by the schema - at design stage at least). You
>>> will want the extra InventoryLine and somewhere to put it in the set
>>> of schemas. Maybe Ken has an opinion on whether to put this
>>> aggregate in the document schema (I guess that breaks the NDR,
>>> Ken) or whether to create not just a custom document schema but
>>> a 'common' schema too: If the latter then maybe both a basic and
>>> an aggregates common schema?
>>
>> Precisely!  The following is a diagram from our training material that we
>> delivered in Australia in January, and is now available as part of the
>> latest edition of our "Practical Universal Business Language Deployment"
>> book (published today!):
>>
>>  http://www.CraneSoftwrights.com/sales/Crane-UBLProfile/#schemasy
>>
>> I'm proposing to the UBL TC that these diagrams be included in the
>> customization guidelines.
>
>
> --
> Upcoming hands-on XSLT, UBL & code list hands-on training classes:
> Brussels, BE 2009-03;  Prague, CZ 2009-03, http://www.xmlprague.cz
> Training tools: Comprehensive interactive XSLT/XPath 1.0/2.0 video
> Video lesson:    http://www.youtube.com/watch?v=PrNjJCh7Ppg&fmt=18
> Video overview:  http://www.youtube.com/watch?v=VTiodiij6gE&fmt=18
> G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
> Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/u/
> Male Cancer Awareness Nov'07  http://www.CraneSoftwrights.com/u/bc
> Legal business disclaimers:  http://www.CraneSoftwrights.com/legal
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org
>
>



-- 
Stephen D. Green

Document Engineering Services Ltd



http://www.biblegateway.com/passage/?search=matthew+22:37 .. and voice