Re: [ubl-ndrsc] Position Paper: Modeling Roles in UBL revision 3

["Eve L. Maler" <eve.maler@sun.com>]

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