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

["Burcham, Bill" <Bill_Burcham@stercomm.com>]

response inline:
> -----Original Message-----
> From: Eve L. Maler [mailto:eve.maler@sun.com]
> Sent: Sunday, February 24, 2002 7:43 PM
>
> 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.

Actually, P3 does not assert that generation of role (names) is a matter of
taste, rather that candidacy of a particular name for catalog inclusion
might be left up to taste or that a more deterministic heuristic such as
"number of occurrences" might be formulated.

Generation of role names themselves is no more or less a matter if taste and
experience than generation of type names.  From P1 all properties are named
based on their role.  What P3 says is that while all properties carry names
derived from their role, only some roles will be (re)used often enough to
warrant inclusion (description) in a catalog.

I'll owe that it is sometimes the case that the role name is the same as the
class name (of the property).  That is certainly not proscribed by any of
the candidate rules.  Is it worth prescribing such a rule:

P6: often a property's role name is the same as its class. In that case it's
ok to use the class name as the property name if that's the best choice.

> 
> So, in summary, I'm not crazy about the idea of divorcing tag 
> names from 
> their types.

The position is not that they must be different, rather that one cannot
deduce the property name from the property type (name).  

> 
> 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 think inheritance is grand, but it doesn't eliminate the need for
role-based naming.  In Java-land we almost never write a function that
operates on a ByteArrayOutputStream -- instead we write f(OutputStream s) so
that f() operates on any kind of output stream.  Note though that it's
usually really convenient for me to name my formal parameter something other
than "OutputStream" (in this case I called it "s").  This is another
instance of role-based naming.  What role does this particular instance of
OutputStream play in this function.

  aside: on the other hand, some folks like Charles Simonyi of Microsoft
think it's really important for every single
  variable or property name to carry along the type name (Hungarian code).
Even with Hungarian code though, there is
  recognition that you've got the "role part" of the name and the "type
part" of the name -- similar to our "property
  term" and "representation term".  f(OutputStream s) would be something
like f(OutputStream sOutputStream) in Hungarian.

So inheritance is useful, and base-type names often match up with role
names, but you still need role names.  Another for-instance: remember the
situations where I have two properties of the same type and need to
distinguish between 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?

Maybe that question ought to be answered by envisioning the processing logic
(as opposed to simply looking for common structures).  Try this one on: two
(or more) types should be generalized (into a base type) when those types
share some common structure _and_ useful processing logic (operations) is
envisioned for that common structure.

Either of these by themselves doesn't seem sufficient to warrant
generalization.  For instance simply sharing common structure doesn't seem
to be sufficient -- I believe that would lead us on a wild goose chase of
pattern matching -- classic newbie designer faux paux (is a circle an
ellipse or the other way 'round).  Thinking only in terms of common
processing logic (independent of structure) might lead us to make _all_ UBL
types derive from some Grand Unified UBL Base Type since we might envision
some processing logic that we might want applicable across any of our
structures. (hmmm.. now that I wrote that I'm thinking about it again and
that sounds kinda neat... no! ... must...not... give.. in)  Seriously
though, the latter seems like it's going to have to be handled outside our
system in "processing logic" land.

> 
> - 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
> 
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>