OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-ndrsc message

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


Subject: Re: [ubl-ndrsc] FW: [ubl-dev] Details on the Methodology




Grimley Michael J NPRI wrote:
> Greetings,
> 
> This was discussed when we were going through every feature of XML Schema and making a decision on whether or not to allow *the LCSC* to take advantage of it. We were reminded on several occasions (by Mark and Jon) that our vote was *only* on whether to allow the LCSC to use them, and in many cases the decision was based solely on whether they were currently using the construct or not.
> 
> Because of this, I think we should make clear that the rules in the NDR are only normative for the LCSC (as was the original intent when the votes were taken).
> 

Correct

> Maybe we should revisit each rule and decide which ones should (must?) also apply to customizers. 

While this seems logical, I wonder if we should embark in this activity (and the one
implied in the next sentence): do we know enough regarding the needs of customizers
to determine what they could/should use or not? I think not; personally, I think
that the safest thing to say would be that the NDR rules apply normatively to LCSC,
but not to others; others should look at them as recommendations that carry no
normative weight. While the application of XSD extension methods does preclude
some choices (pardon the pun), this applies to context driven customizations only; I'm sure
many vertical organizations would prefer to be UBL-conscious (or UBL-sympatico)
rather than UBL compliant, and in that case it really it is not up to us to tell
them what to use or not to use.

However, I know that a lot of people do not agree with the above and would like to
see the NDR rules be applied normatively to more than LCSC; fair enough. But it will
cause headaches for years to come.


> Also, I believe there was a decision made that any rules targeted solely to customizers would be contained in the Context Methodology deliverable.
> 
> Thank You,
> Mike Grimley
> 
> ----------------------------------------------------------------------------
> 
> Anne Hendry said (on ubl-dev):
> 
> Regarding the use (or not) of xsd:choice, I do recall several discussions
> on this, but don't recall the details of the final decision.   There is the
> intention, for the final UBL release, to flesh out the rules checklist with additional information on each rule.  I can bring this question and your other comment (on splitting the document) to the attention of the NDR team.  Their next meeting is this coming Wednesday.  
> 
> 
>>    I really cannot understand why UBL forbids xsd:choice. Aside from
>>    the fact that even DTDs permit choices, there are many
>>    applications in which a content model must reflect a choice. For
>>    example, suppose a government form allows the user to include
>>    either a TIN or SSN for identification purposes, or another
>>    application allows one of 4 parameters for a search. How can we
>>    possibly create UBL-compliant XSDs that meet our business needs
>>    with such a restriction on content models? We would be forced to
>>    create redundant schema that differ only in such choices, an
>>    obvious maintenance headache.
>>     
> 
> 
> To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/ubl-ndrsc/members/leave_workgroup.php.
> 

-- 
Eduardo Gutentag               |         e-mail: eduardo.gutentag@Sun.COM
Web Technologies and Standards |         Phone:  +1 510 550 4616 x31442
Sun Microsystems Inc.          |
W3C AC Rep / OASIS BoD




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