Re: [ubl] Customization proposal

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

Greetings UBL

Sorry that I can't be there or phone in next week.

These customisation thoughts and proposals from Ken
are looking, to me, increasingly realistic and acceptable
and very welcome.

I've a minor point about section 8.2.2. 
"Application handling of an arbitrary UBL instance input":
just to comment that it seems worth considering that
an implementation could use the subset schema here
too, as well as a similar use in the 'pure subset' handling
(8.2.1), before processing, to test for the existence
of 'impure' (outside the subset) elements. Of course,
it should * not * then reject the instance (subject to 8.2 
para #1 decision) if such elements exist in it but 
continue to process it with that in mind. In other words,
if there is such 'inpurity' (non-subset elements) then
there may be some implication to understand in that it
means that subsequent XSLT 'impurity removal' will
actually remove things that might have needed some 
human attention and so the pre-processed (pre-removal)
instance may need further exposure to the downstream
handling.

Another point is that paragraph 5.3 seems to be crucial
to the later discussion and arguments but the wording
(perhaps through the subtlety of the subject matter) 
could hopefully be clarified. On the other hand a lot of
the wording for similar topics in the paper could clarify
the index wording to accompany the SBS packages; 
especially clear are sections 7.1 and 7.2.

Elsewhere I think the terminology and underlying 
assumptions for them stating 'unable to process' and
'unacceptable to process' are a little pessimistic for the
kinds of implementations I would envisiage where 
rather than actual rejection of a message, an exception 
or warning could be thrown to cause the document to go
to a human for scrutiny before possible rejection as a 
last resort. That is because there are implementations
known where there are just too many 'rejections' and 
if all of these were returned there would be no business
benefit to anyone. However there are obviously others
who would see in the 'pessimistic' approach the optimistic
silver lining of removal of any need for human intervention.
I just don't see that happening in the near future in the 
circles in which I move.

Many thanks indeed Ken for what is shaping up, in my
view, to be an excellent aspect of UBL implementation
support and design guidance.

All the best

Stephen Green




>>> <jon.bosak@sun.com> 10/08/06 14:41:37 >>>
UBL TC members meeting next week in Montréal should remember to
prepare for our discussion of customization by reading Ken
Holman's proposal titled "UBL 2.0 subsets, extensions, versions,
validation and interchange":

   http://www.oasis-open.org/committees/document.php?document_id=18849 

Jon