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: Re: [ubl-ndrsc] URGENT: Containership of series of like elements


I also agree with Eve this issue need to be brought to the fore.

May i also suggest that to clarify and focus the discussion you ensure 
your clearly explain what you mean by containership and containers and 
in particular how this differ from aggregations of elements.

for exmaple, the problem i have with your statement 'for the following 
reasons...' is that it is a no-brainer - who could argue with it! the 
issue is when and what is a container. whilst you do give a definition 
it might help to say what it isn't as well.  i also feel that examples 
will be useful to get everyone on the same page.

The issue of the name 'Details' is a seperate issue.  if you recall we 
decided (at least we did in LC) that the RT would not apply to UBL Names 
of instances of aggregates - because the CCTS says it must always be 
'Details' and this seems superfluous.  We have no jurisdiction over the 
Dictionary Entry Name which is a CCTS convention.  I suggest we sort out 
the concept we are trying for, then look at what we call them.


Eve L. Maler wrote:

> 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
>

-- 
regards
tim mcgrath
fremantle  western australia 6160
phone: +618 93352228  fax: +618 93352142 





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


Powered by eList eXpress LLC