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] Re: proposal for extension to UBL-Order

Hi Christine,

What you said is essentially the idea.  The actual implementation
details, however, differ somewhat  between different ways  of 
customization and schema modification.  By "customization" and
"schema modification", I mean modifying UBL's schema to derive
from it a slightly modified version which is suitable for your
actual implementation.  Of course, you'll do this because of
inserting some new elements into the schema (like what you described)
rather than introducing a comment block, which is a separate idea.

For customization, the namespace value is changed for the entire
UBL-derived schema, not just the new element that you introduce.
If this sounds confusing, just think of UBL's schemas as atomic --
an indivisible piece of tool that you either use it as-is or 
leave it alone.  By customizing, you'll use the UBL schema types
as building blocks to create your schema.   From here, there're
2 lines of thoughts: 

(1) UBL Customization Guidelines.   The idea is also to use the main
documents (eg. Order, OrderResponse, Invoice, etc) as starting point
for derivations, then apply schema extensions, restrictions, etc 
schema command facilities to "morph" the schema on-the-fly during 
parsing to arrive at the final in-memory schema version.  Your 
memory and imagination  needs to be as good as a schema validator 
so you can be reasonably sure that what you cannot see is still 
going to be what you get.   A lot of it is still under debate as 
you can check with the mail archives.  

(2) Atomic Model for Customization, which is to use schema types
defined in UBL as starting points, then statically stack them up
(just like C, Java programming, defining new structs embedding
pointers to already-defined structs).  This is what I'm pointing
out as another idea;  so you can assess if it makes sense.  Those 
already-defined UBL schema types are treated as atomic black-boxes.  
While stacking up these types under a new enveloping type, you can 
also introduce at the same time non-UBL types local to your purposes.

Details of (1) are found inside UBL's zip archive, for (2), allow
me to point you to an article at: 

Perhaps others on the list might have further thoughts.

PS: Pardon me for replying this towards ubl-dev as well, as I'm
    also having some interest to hear on this from others regarding
    the topic.

Best Regards,
Chin Chee-Kai
Tel: +65-6820-2979
Fax: +65-6743-7875
Email: cheekai@SoftML.Net

On Thu, 8 Sep 2005, Christine Spietz wrote:

>>Dear Chin Chee-Kai,
>>A lot of thanks for your answer, it is very informative. I will discuss your
>>proposals in our working group this afternoon.
>>Perhaps you can give me one more hint about your proposal to "Adding another
>>tag using customized schema".
>>If I understood this proposal I have to embed an element, for instance
>><xsd:element name="MyDocument" type="myNamespace:myDocumentType"/> with an
>>other namespace in the UBL-Order.
>>the Namespace is declared (xmlns:myNamespace ="xy") an an import-statement
>>ist added:
>>When importing the namespace I don't have to provide a value for
>>The instance document must then identify a schema that implements
>>Thus at runtime you have to match up the reference to myDocumentType with an
>>implementation of myDocumentType.
>>For example an instance document may have this:
>>xsi:schemaLocation="http://ubl.org ubl.xsd http://ourInstitution.org
>>so in this instance document schemaLocation is identifying a schema
>>ourSchema.xsd, which is to provide the implementation of myDocumentType.
>>But I think I have misunderstood your proposal to "Adding another tag using
>>customized schema", because in this case I have to embed a new element into
>>the UBL-Order-Schema or did you mean to embed this in a comment underneath
>>the Item->Description?
>>It would be very nice if you can give me yet another little hint.
>>I am looking forward to here from you. Thanks for your help!
>>Best regards
>>Christine Spietz
>>----- Original Message -----
>>From: "Chin Chee-Kai" <cheekai@SoftML.Net>
>>To: "Christine Spietz" <spietz@fh-bingen.de>
>>Cc: "UBL-Dev" <ubl-dev@lists.oasis-open.org>
>>Sent: Thursday, September 08, 2005 9:16 AM
>>Subject: Re: [ubl-dev] Re: proposal for extension to UBL-Order
>>>>>Christine Spietz wrote:
>>>>>> We have our own XML-Documents to describe the required values for an
>>>>>> agricultural operation, so if we would like to use the UBL-Order, we
>>>>>> have to embed this document as a string-value in
>>>>>> "Order->cac:Orderline->LineItem->Item->Description" or is there an
>>>>>> other opportunity which we haven't seen yet?
>>> I'll really suggest not to use this method for various reasons.
>>> Mechanically, it may seem to work because your own XML-Documents
>>> get re-encoded into string-value space that will get pass schema
>>> validation (or rather, invalidation).
>>> But one of the main reasons you would pick UBL, if you do use UBL,
>>> would be that each tag has not only a standardized spelling, but
>>> also a standardized meaning to it.  If you "re-type" a tagname,
>>> the meaning of that tag is changed.  A "Order->..->Description"
>>> is no longer a description for human, but rather an embedded
>>> structured document and without any hint or sign stating so
>>> except by looking at it.
>>> So, supposing one of these days the "Order->..->Description"
>>> contains a human note say "The offer of 80% discount is not valid
>>> if OrderResponse is not received within 24hrs.", which will get
>>> discarded by your application because it is designed to parse
>>> the string for XML document and not to show to human user...
>>>>>> If there is not, we would like to know, if there is a possibility to
>>>>>> make an extension on the element "Item", so that there is a
>>>>>> possibility to have an element "Description" of the type
>>>>>> xsd:anyElement. Then it would be possible to integrate our
>>>>>> XML-Documents into the UBL-Order.
>>> There're quite a number of ways to do it, not all may be suitable
>>> in your particular environment and not all bear the same level of
>>> "correctness" that will not get frowned upon by someone.  But here're
>>> a few ways:
>>> - Embedded comment blocks:  your app "recognises" a valid comment
>>>  block following the "Order->..->Description" tag as instruction
>>>  to parse the content (something like the early days of embedding
>>>  scripts within HTML pages...)
>>>  <!-- [[MY-APP-EXT]]
>>>       <?xml version="1.0" ...>
>>>       <Your XML Document follows>
>>>  -->
>>>  where "[[MY-APP-EXT]]" tells your app to start parsing.
>>> - Human-machine description in the "Order->..->Description"
>>>  field:  you fill in "[[MY-APP-EXT]]http://.../my-xml-doc.xml";.
>>>  And store your XML doc at the URL referenced.
>>>  This is different from embedding the document, as the type of
>>>  the field isn't changed.
>>> - Adding another tag using customized schema.  There're different
>>>  ways to do this as well.  Can't type them all here now....
>>> Best Regards,
>>> Chin Chee-Kai
>>> SoftML
>>> Tel: +65-6820-2979
>>> Fax: +65-6743-7875
>>> Email: cheekai@SoftML.Net
>>> http://SoftML.Net/

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