[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [ubl-ndrsc] Position Paper: Modeling Roles in UBL revision 3
At 02:15 PM 2/22/02 -0600, Burcham, Bill wrote: >Changes: > * It's in PDF now. Woo hoo! I'm on the map. > * Section 2 Problem Description has been reworked to reflect > discussions between Burcham and Maler (on the list) regarding duplicate > rules. It's now clear that only rules 1, 5 and (1 and 5 together) merit > consideration. > * Put sections 3, 4 and 5 -- the various Options sections into "plus > and minus" form. > * Normalized voice (hey this isn't about me ok?!? :-) Okay, I've finally gotten my head around the logic that makes case #1 and case #11 be the same. Sorry it took me so long. I believe, though, that the assessment of cases #3, #6, #9, and #12 as reflecting the absence of a design rule is not quite accurate. Rather, it could be said that they mean the absence of a design rule *with respect to the relationship of tag names and their XSD types*; they admit relationships based on other factors. In fact, you are proposing just such an alternative factor in saying that tag names should be based on "roles" irrespective of type assignment (where sometimes the roles might appear to match up perfectly with structural types and sometimes they might not). So, now that I understand the gist of the position paper more fully (and hopefully accurately), here are reactions to the specific proposals being made: P0 (regarding the UBL model containing a notion of "property"): I don't see a problem with this, though I might avoid the phrase "model element" because it's too easy to confuse with XML elements. P1 through P5 (regarding tag naming based solely on "roles" and the mechanisms to make this happen): The killer for me is P3, where there is an admission that it's difficult to make the generation of roles deterministic because role identification is left up to "experience and taste". Considering that XSD types are not just structural templates but are supposed to convey some semantics, I find it really hard to base element names solely on their roles and not at all on types; type-based names would rely much less on experience and taste. So, in summary, I'm not crazy about the idea of divorcing tag names from their types. There's an idea that we haven't discussed at all yet that may provide a bit of a way out: Using XSD ancestor types to reflect commonalities. Our two examples of the tag name/type conundrum are headers and status codes. In each case, there are similar semantics and similar (but not identical) structures. What I would normally consider doing, in order to make processing take advantage of this fact, is to create an ancestor HeaderType type that factors out the structurally identical bits to the extent possible, and then extend it to create OrderHeaderType and InvoiceHeaderType. The common "role" is now baked into the type hierarchy and is accessible to software. These have to be documented somehow in the catalog, and I don't really care what we call them. I don't want to distract from Bill's proposal, but we would have run into the question of ancestor types at some point anyway, and it seems to me that the question is precisely about reflecting different types of commonality... Questions about this issue would include: - Should types that are functionally abstract (i.e., are never used directly in assigning a type to a native UBL element) be declared literally abstract, so that extension designers couldn't use them directly themselves without further work? - What are the criteria for creating a more deeply nested type hierarchy in any one case? To what extent should structural commonalities be factored into the ancestor type? - How should ancestor types be documented in the dictionary? What kinds of "things" are they? I suspect that followups to this idea belong in a separate thread, but I'll let other responders judge whether the idea is sufficiently connected to the "role" proposal and follow up accordingly. Eve -- Eve Maler +1 781 442 3190 Sun Microsystems XML Technology Center eve.maler @ sun.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC