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


Subject: Re: [ubl-ndrsc] NDR Checklist Clarification


my interpretation of [D6] is:

data type =  qualifier + (primary or secondary representation term )
NOT
data type =  (primary qualifier + primary) or  (secondary qualifier 
+secondary representation term )

either way, as far as UBL is concerned in all known cases, qualifier is 
null, therefore data type is either a primary or secondary 
representation term.  my question to mark is can we therefore drop the 
qualifer altogether and make this rule fixed.

it is up to the CCTS people to say if this is complaint or not.


Chin Chee-Kai wrote:

> Tim & Mark,
>
> On Sat, 20 Sep 2003, Tim McGrath wrote:
>
>>> 6.1.4.3.3 Data Type Rules for Definitions
>>> [D6] The definition of a Data Type shall use a structure that is 
>>> based on the existence
>>> of primary and secondary Representation Terms of the associated Core
>>> Component Type, and is enhanced by Qualifier Terms.
>>
>
> Thanks, Tim.  This [D6] paragraph seems to imply that in
> implementations, the Data Type is a function of 4 variables:
> - Qualifier primary Representation Term
> - primary Representation Term
> - Qualifier secondary Representation Term
> - secondary Representation Term
>
> and appears consistent with what [D14] describes.
> This implies that we could need 4 columns in the spreadsheets.
>
> But Mark is saying primary rep term == secondary rep term
> and no such thing as "qualifier rep term".  This implies
> that we could/must need only 1 column in the spreadsheets.
>
> Can we nail this down quickly?
>
> Thanks.
>
>
>
> Best Regards,
> Chin Chee-Kai
> SoftML
> Tel: +65-6820-2979
> Fax: +65-6743-7875
> Email: cheekai@SoftML.Net
> http://SoftML.Net/
>
>
>
>>> 6.1.4.3.4 Rules for Data Type Dictionary Entry Names
>>> [D14] The Dictionary Entry Name of a Data Type shall consist of a 
>>> Representation
>>> Term—preceded by Qualifier Term(s) as necessary —followed by a dot, 
>>> a space
>>> character, and the term Type. The space character shall separate 
>>> words in multi-word
>>> Qualifier Terms and Representation Terms. Each Qualifier Term shall 
>>> be followed by an underscore.
>>> To allow spell checking of the words in the Dictionary Entry Name, a 
>>> space character shall follow
>>> the underscores after Qualifier Terms.
>>> [Example]
>>> Country_ Identifier. Type
>>>
>>> This would explain why we have this column.  It has been in the 
>>> models and schemas since at least 0p70 - so we have had it for 12 
>>> months and it passed reviews, presumably several times.  The good 
>>> news is that we have never found anything worth putting in there, so 
>>> it is currently always blank.
>>>
>>> Sounds to me as if the CCTS has two conflicting views on derived 
>>> Representation Terms - one calling them 'secondary' and the other 
>>> calling them 'qualified'.
>>>
>>> Chee-Kai's concern is that it may impact his schema generator.   My 
>>> feeling is that what we are doing currently is correct.  Each 
>>> Representation Term (in our models) has a complexType.  The use of 
>>> Qualifier for Representation Term impacts the CCTS meta data and the 
>>> naming only.
>>>
>>> Mark, as Editor of CCTS , do you propose we should drop the 
>>> Qualifier for Representation Term?
>>>
>>>
>>> CRAWFORD, Mark wrote:
>>>
>>>> The CCTS specifies primary and secondary representation terms.  
>>>> Both are lexically synonimous to "representation term".  There is 
>>>> no such thing as "qualifier representation term".  If LC has that 
>>>> in the spreadsheet, then they need to clarify and ensure 
>>>> conformance with CCTS.
>>>>
>>>>     -----Original Message-----     From: Chin Chee-Kai 
>>>> [mailto:cheekai@softml.net]     Sent: Thu 9/18/2003 10:14 PM 
>>>>     To: UBL NDRSC     Cc:     Subject: [ubl-ndrsc] NDR Checklist 
>>>> Clarification
>>>>     
>>>>     
>>>>
>>>>
>>>>     R13:     ----------     For every primary representation term 
>>>> used in the UBL model, a named     complex type MUST be defined. 
>>>>     ----------     R14:     ----------     For every secondary 
>>>> representation term used in the UBL model, a named     complex type 
>>>> MUST be defined.     ----------
>>>>     How do "primary representation term" and "secondary 
>>>> representation     term" relate to each other, and to 
>>>> "representation term" and     "qualifier representation term"?  Are 
>>>> they 4 different concepts,     or some are synonyms or something else?
>>>>     In the spreadsheet models, there are only "qualifier 
>>>> representation     term" and "representation term".  Please clarify.
>>>>
>>>>
>>>>
>>>>     R90:     -----------     A RootSchema in one UBL namespace that 
>>>> is dependant upon type definitions     or element declarations 
>>>> defined in another namespace MUST NOT import     schema modules 
>>>> from that namespace.     -----------
>>>>     What is this talking about??
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>     Best Regards,     Chin Chee-Kai     SoftML     Tel: 
>>>> +65-6820-2979     Fax: +65-6743-7875     Email: cheekai@SoftML.Net 
>>>>     http://SoftML.Net/
>>>>
>>>>
>>>>     To unsubscribe from this mailing list (and be removed from the 
>>>> roster of the OASIS TC), go to 
>>>> http://www.oasis-open.org/apps/org/workgroup/ubl-ndrsc/members/leave_workgroup.php. 
>>>>
>>>>
>>>>  
>>>>
>>>
>>> -- 
>>> regards
>>> tim mcgrath
>>> phone: +618 93352228  postal: po box 1289   fremantle    western 
>>> australia 6160
>>>
>>>
>>>
>

-- 
regards
tim mcgrath
phone: +618 93352228  
postal: po box 1289   fremantle    western australia 6160






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