Re: [ubl-ndrsc] Minutes from 30 October

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

Hi folks,

Apologies that I've been absent so much.  I knew this was going to 
happen eventually, but I didn't think it would happen so suddenly. 
Right now I actually do anticipate being able to join at least parts of 
the next two calls (November 6 and 11), but will not be able to chair or 
prepare minutes; it looks like these tasks have been parceled out, and I 
wanted to thank those folks who are picking up the slack and doing such 
a great job.

(By the way, I will be in Menlo Park for the next F2F meeting, but will 
have a few holes in my schedule.  I will be present all of Monday, 
Tuesday morning, and all of Wednesday, but will miss Thursday and Friday.)

Great work this week!  I have a few follow-up comments on this discussion:

CRAWFORD, Mark wrote:

> * Discussion Point:  Object classes (aggregate BIEs) are turned into 
> complex type         definitions and element declarations that are 
> directly bound to these types.
> 
> - Team agrees.  Gunter will review Pearl Script.
> 
> * Discussion Point:  Properties (association and basic BIEs) are turned 
> into element references in the content models of the object class 
> complex types. If a suitable element declaration was not already created 
> above, it is created now. (There may be multiple elements with the same 
> type but different names.)
> 
> - Arofan thinks it is worth pointing out that he does not believe with 
> the current naming rules we will end up with the multiple elements but 
> there is no need to change the statement.  This appears to be driven by 
> the spreadsheet approach as much as the naming rules.  Bill believes 
> this may be true because we are adding the Type to the name.

If Arofan and Bill are comfortable, then I'm sure things are okay.  What 
I was concerned about was that, as Bill had pointed out in Burlington, 
the LC SC folks might inadvertently assign the same truncated UBL name 
to two things that have quite different meanings, and that this would 
obviously throw a monkey wrench into the works.  But if the LC SC folks 
are reasonable vigilant, there should be no problem.

> * Discussion Point: The properties are bound to types indicated by the 
> relevant      representation terms. Where a representation term 
> corresponds to one of the prescribed CCTs, its corresponding XSD type is 
> used. Where a representation term corresponds to an object class 
> (aggregate BIE), that complex type is used instead.
> 
> -  Team agrees, however there is concern on Gunter’s part on how to make 
> this happen (basic BIE’s and XSD) with the scripts. Gunter is especially 
> concerned if we have restrictions and he is trying to get the pearl 
> scripts to be able to handle restrictions. There seems to be support for 
> including in the NDR document a mapping of prescribed CCTs and XSD types 
> (Mark to do). 

I wasn't sure I understand Gunther's concern about restrictions as 
explained in his recent email.  I had thought that all the vanilla UBL 
components won't need restrictions, since mostly we will just have one 
or more elements bound to the identical type.  Perhaps the concern is 
only with the handcrafting of the CCT module, in which case it probably 
does come down to selecting UBL-invented secondary representation terms 
and then applying the specialized type based on that secondary term.

> * Discussion Point: A combination of the definition of the generic 
> element-as-object-class (the original declaration, associated with a 
> type) and the specific element-as-property-of-a-higher-object-class (the 
> reference in a content model) provides a complete view of the meaning.
> 
> -  Team agrees and Mavis to incorporate as text for NDR document.
> 
> * Discussion Point:  (Additive to last discussion point) Eve made the 
> statement “This probably affects assembly since it creates elements and 
> attaches BIE definitions that can be referenced by assemblers of new 
> message types.” 
> 
> - The team did not understand this, and will ask Eve for clarification.

What I meant here was that, with these rules, we will end up with (a) a 
set of BIEs (object classes) realized as types, and (b) *also* a set of 
generic global elements bound to those types.  It's only when one of 
those elements is associated with a content model (higher-level object 
class) in a complex type definition that it acquires "property" 
semantics.  Therefore, the assembly use case that I introduced in 
Burlington is successfully served by the ability to reference our new, 
global, generic elements in building new object classes and messages.  I 
guess this amount to a simple observation and isn't really a point for 
discussion, unless someone tells me that my analysis is wrong.

	Eve

-- 
Eve Maler                                        +1 781 442 3190
Sun Microsystems                     NEW!!! cell +1 781 354 9441
Web Technologies and Standards               eve.maler @ sun.com