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] | [Elist Home]


Subject: [ubl-ndrsc] URGENT: Containership of series of like elements


I have a feeling that I buried my questions and issues too far down in 
my response to the meeting minutes from this week.  This message 
highlights the questions; I'd like to ask for an IMMEDIATE 
response/reaction, so that the proposal can proceed on the ubl-comment 
list in a timely fashion:

>> The NDR SC worked on the wording of the Containership proposal and 
>> puts forward the following:
>>
>> The NDR SC advocates the use of containers for the following reasons:
>>
>> * having the flexibility to extend content models using XSD
>> * for efficient use of existing XML tools and technologies (e.g. XPath 
>> etc.)
>> * general issues of clarity and usability
>>
>>
>> The NDR SC wishes to put forth the following rule for containership 
>> for feedback from participants on the ubl-comment list. This proposal 
>> merely touches on part of the wider containership issue. Please note 
>> that this diverges from the modelling in the current distribution OP65.
>>
>> A group of like elements constitutes a model element in its own right. 
>> The type of the containing element has a relationship to the type of 
>> the contained element.  The name of the container Type  uses the type 
>> name of the contained element and adds the word "List".
>>
>> Here is an example of the proposed model:
>>
>> The Order object class has a property called LineItemList. 
>> LineItemList is an instance of the object class called LineItemList.  
>> A LineItemList contains one or more instances of object class LineItem.
>>
>> The dictionary entry name for this property LineItemList is 
>> Order.LineItemList.LineItemList.
> 
> 
> This assumes that we are no longer using "Details" in the position of a 
> representation term, but instead the type of the property.  I agree with 
> this idea in principle, but did this get discussed as a separate item 
> and agreed to?  Conflating the type-as-RT issue with containership of 
> series of like items -- especially since 0pt65 emphatically doesn't 
> follow this type-as-RT rule -- may be very confusing to reviewers.
> 
>> When the  existing naming rules are applied the resultant XML element 
>> name would be LineItemList.
>>
>> Consequently, you have the freedom to choose a property term that 
>> differs from the representation term to accomodate elements that might 
>> be named as follows:
>> Dictionary Entry Name = Order.Accepted.LineItemList with an XML 
>> element name of AcceptedLineItemList.
> 
> 
> This isn't how our existing naming rules work (I thought).  We assume in 
> our rules that "Details" is the RT, and "Details" always gets dropped -- 
> but if the RT is something else (at the aggregate level), we don't say 
> whether it gets dropped.

I feel that my concern over "Details" in the RT position is really 
important.  Would the intent of the NDR group's work this week be harmed 
if we were to go back to our "normal" assumption about Details as an RT, 
and then take up that question separately later?

My specific proposal is to submit the following text to the ubl-comment 
list, rather than the text that appeared in the minutes.  Mostly I have 
removed the discussion of "Order.Accepted.LineItemList" (I have also 
incorporated Mike G.'s corrections to the code examples).  Note that an 
element such as <AcceptedLineItemList> could still be created using the 
existing naming rules, with "Accepted" as the property qualified and 
"LineItemList" as the property term, which is why I was able to leave 
such an element in the code example below.

			*		*		*

The NDR SC advocates the use of containers (elements that group and 
associate a selection of subelements) for the following reasons:

* having the flexibility to extend content models using XSD
* for efficient use of existing XML tools and technologies (e.g.
   XPath etc.)
* general issues of clarity and usability

The NDR SC wishes to put forth the following rule for containership for 
  feedback from participants on the ubl-comment list. This proposal merely
touches on part of the wider containership issue. Please note that this
diverges from the modelling in the current distribution OP65.

A group of like elements constitutes a model element in its own right. 
The type of the containing element has a relationship to the type of the 
contained element.  The name of the container type uses the type name of 
the contained element and adds the word "List".

Here is an example of the proposed model:

The Order object class has a property called LineItemList. LineItemList 
is an instance of the object class called LineItemList.  A LineItemList 
contains one or more instances of object class LineItem.

The dictionary entry name for this property LineItemList is
Order.LineItemList.Details.

When the existing naming rules are applied the resultant XML element 
name would be LineItemList.

Here are the XML instances for these two examples

Example 1.
<LineItemList>
     <LineItem>...</LineItem>
     <LineItem>...</LineItem>
     <LineItem>...</LineItem>
</LineItemList>

Note that LineItemList is of type LineItemList.

Example 2.
<AcceptedLineItemList>
     <LineItem>...</LineItem>
     <LineItem>...</LineItem>
     <LineItem>...</LineItem>
</AcceptedLineItemList>

Note that here also the type of AcceptedLineItemList is LineItemList.

			*		*		*

Again, let me ask you folks to respond as soon as possible to ensure 
that we don't delay in going forward with our plan to ask for 
ubl-comment advice.

Thanks,

	Eve

-- 
Eve Maler                                        +1 781 442 3190
Sun Microsystems                            cell +1 781 883 5917
XML Web Services / Industry Initiatives      eve.maler @ sun.com



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


Powered by eList eXpress LLC