[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl] Customization proposal
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]