Re: [ubl-ndrsc] Re: [ubl-lcsc] Re: [ubl-ndrsc] UBL: question on CCTlanguage component

[Anne Hendry <anne.hendry@sun.com>]

Table 8-2 shows both, one right after the other,  both type string.  I 
thinkone problem with 8-2 is that it seems to have been alphabetized, as 
opposed to being ordered by the structures it's defining!

Ah, to me, though, looking at this table (8-2), following your logic, I 
would expect there then to be language.content, and then maybe 
language.code. identifier, as there is for amount.content and 
amount.currency.identifier.   However, my logic expects more along the 
lines of (eg) code.name.text and code.name.language, or datetime.content 
and datetime.language.  So one of the first questions for me is 'What 
types need to have language specified' and then, what components need to 
have a language specified, and then make lanagues a supp component of 
that type.  All the other types are grouped, as if they could be in a 
structure, but language is just hanging out there on it's own.  I'll 
have to look at this a bit more, but I don't see why language should be 
separated out as you have it in this example - I'd think it would have 
to be x.language...., or y.language. ..., not language.x....  because 
the language has to apply to some aspect of some type, either the name 
of the a components (text) or a format (date).  But perhaps I'm looking 
at things the wrong way around...

-Anne

Tim McGrath wrote:

> I cannot find where it says they are indicator. Content???  di you 
> mean Identifier. Content?
>
> In the data model i derived fro the tables in 8-1 and 8-2, you will 
> see that both Language.Identifier and Language.Locale.Identifier are 
> Identifiers and therefore have an Identifer. Content (ie xsd:token).
>
> This conundrum exposes the 'flat' structures we have built for CCTs 
> and Rep. Terms , when they should have been more sophisticated.  That 
> is, we should have had things like...
>
> <Language>
> <Identifier>
> <Content>
> EN
> </Content>
> </Identifier>
> <LocaleIdentifier>
> <Content>
> US
> </Content>
> </LocaleIdentifier>
> </Language>
>
> where the schema reflects the true structures of the CCTs and not the 
> table
>
>
> CRAWFORD, Mark wrote:
>
>> Anne,
>>
>> Language supplementary components are of indicator. Content.
>> Mark Crawford
>> Research Fellow - LMI XML Lead
>> W3C Advisory Committee, OASIS, RosettaNet Representative
>> Vice Chair - OASIS UBL TC & Chair Naming and Design Rules Subcommittee
>> Chair - UN/CEFACT XML Syntax Working Group
>> Editor - UN/CEFACT Core Components
>> ______
>> Logistics Management Institute
>> 2000 Corporate Ridge, McLean, VA 22102-7805
>> (703) 917-7177   Fax (703) 917-7481 Wireless (703) 655-4810
>> mcrawford@lmi.org
>> http://www.lmi.org
>> "Opportunity is what you make of it"
>>
>>
>> -----Original Message-----
>> From: Anne Hendry <anne.hendry@sun.com>
>> To: ubl-lcsc@lists.oasis-open.org <ubl-lcsc@lists.oasis-open.org>; 
>> ubl-ndrsc@lists.oasis-open.org <ubl-ndrsc@lists.oasis-open.org>
>> Sent: Sat Feb 28 01:16:14 2004
>> Subject: [ubl-ndrsc] UBL: question on CCT language component
>>
>>   Hi,
>>
>> In matching up the UBL xsd datatype assignments to cct types, I could 
>> use some clarification on the 'language*' components.  All other 
>> components listed in table 8-2 of ccts 2.01 have a 'content' 
>> component and then some supplementary components.  However, language* 
>> components seem to be all supplementary, with no content component - 
>> they just appear as 'Language.Identifier' and 
>> 'Language.Locale.Identifier'.  So, then, going through the xsd 
>> representation of the Code type in table 8-2, for example, I have all 
>> the attributes (supplementary components) of Code type accounted for, 
>> but there is one extra in the schema that is not in the cct 8-2 
>> table.  That is 'languageID'.  Here is the xsd for the 'Code' element:
>>
>> - <xsd:simpleContent>
>> - <xsd:extension base="xsd:token">
>>  <xsd:attribute name="listID" type="xsd:token" use="optional" />
>>  <xsd:attribute name="listAgencyID" type="xsd:token" use="optional" />
>>  <xsd:attribute name="listAgencyName" type="xsd:token" use="optional" />
>>  <xsd:attribute name="listName" type="xsd:token" use="optional" />
>>  <xsd:attribute name="listVersionID" type="xsd:token" use="optional" />
>>  <xsd:attribute name="name" type="xsd:token" use="optional" />
>>  <xsd:attribute name="languageID" type="xsd:language" use="optional" />
>>  <xsd:attribute name="listURI" type="xsd:anyURI" use="optional" />
>>  <xsd:attribute name="listSchemeURI" type="xsd:anyURI" use="optional" />
>>  </xsd:extension>
>>  </xsd:simpleContent>
>>
>> The definition of the 'Language.Identifier' component in the ccts 8-2 
>> table defines it as "The indentifier of the language used in the 
>> corresponding text string."  Well, ok, there is a 'text' string 
>> (name) in the schema right above this that corresponds to the ccts 
>> entry in 8-2 'Code.Name.Text'.  However, there are other 'text' 
>> strings (eg. in BinaryObject Name, etc) in 8-2 tha t don't seem to 
>> have a 'languageID' attribute attached.
>>
>> So my questions are:
>>
>> a) Why does Language.Identifier not have a content component?  It 
>> seems like somewhat of a free-floating supplementary component the 
>> way it is now.
>> b) When/how do we choose to use the Language.Identifier?
>> c) Along with Language.Identifier in table 8-2 there is 
>> 'Language.Locale.Identifier', also a seemingly free-floating 
>> supplementary component.  Is it expected that wherever there is a 
>> Language.Identifier attribute needed/used there should also be a 
>> Language.Locale.Identifier?
>>
>> I am only looking at the cct schema. I'm assuming the rep terms 
>> schema is going away.  Is this a correct assumption and I should only 
>> look at cct?  What about the cc parameters schema - will that be 
>> auto-generated (or will that one be removed too)??
>>
>> Thanks,
>> An ne
>>
>>
>> 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. 
>>
>>
>>
>>
>> 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-lcsc/members/leave_workgroup.php. 
>>
>>
>>  
>>
>