MHonArc v2.5.0b2 -->
ubl-ndrsc message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [ubl-ndrsc] UBL: question on CCT language component
Anne
I'm worried that in all this we might inadvertently drop the LC/NDR
resolution to use xsd:normalizedString wherever there is the possibility
that more than one space need be preserved (having business meaning).
I think it was decided for Identifier but there was less certainty about
using it for Code.
*I note that most Supp Comps are identifiers.*
Perhaps this got neglected as changes were made to the Schemas and
then the omissions reinforced as we discussed xsd:token versus xsd:string.
Steve
----- Original Message -----
From: "Anne Hendry" <anne.hendry@sun.com>
To: <ubl-lcsc@lists.oasis-open.org>; <ubl-ndrsc@lists.oasis-open.org>
Sent: Saturday, February 28, 2004 6:16 AM
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_workgro
up.php.
>
>
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]