OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-lcsc message

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


Subject: Re: [ubl-lcsc] Re: UBL 0.81 CCT draft-9-mod


Thanks for the clarification, Tim.  I see what you mean now.

I took the spirit of the discussion about changing IdentifierType
from xsd:token to xsd:normalizedString to be a facilitation of
layman user-assigned IDs used in businesses, where the IDs
might have inherited legacy position-oriented and/or space-filled
formating.

I looked at the attribute values and thought those IDs, on the
other hand, would have been assigned by (presumably standards and
organizational) agencies who are not (in my opinion)
expected to have likelihood of having inherited such 
formating restrictions with spaces.  Even for privately
held and controlled identifier values, the name of the
list of values, the version, and other metadata of the values
are usually (again, just in my limited opinion) not subject 
to the same spacing-filling restrictions.  Making this supposition,
then, xsd:token could fit the attribute's type requirements
better.

Certainly, this assessment is at most subjective.  So I'm
open to collect more suggestions to change them to other
types.  I've also collected some more feedbacks from Stephen
and can bundle these comments into draft-9-mod-2 perhaps
on Wednesday pending further inputs from other members of list.

Thanks.



Best Regards,
Chin Chee-Kai
SoftML
Tel: +65-6820-2979
Fax: +65-6743-7875
Email: cheekai@SoftML.Net
http://SoftML.Net/


On Mon, 8 Sep 2003, Tim McGrath wrote:

>>i agree that you are acting in accordance with the consensus of the
>>group but have you gone far enough?
>>
>>maybe i am mis-reading the code, but when i see
>>
>>>     <!-- ===== CCT: IdentifierType ===== -->
>>>     <xsd:element name="Identifier" type="cct:IdentifierType"/>
>>>     <xsd:complexType name="IdentifierType">
>>>         <xsd:simpleContent>
>>>             <xsd:extension base="xsd:normalizedString">
>>>                 <xsd:attributeGroup ref="cct:commonAttributes"/>
>>>                 <xsd:attribute name="schemeID" type="xsd:token"
>>> use="optional"/>
>>>                 <xsd:attribute name="schemeAgencyID" type="xsd:token"
>>> use="optional"/>
>>>                 <xsd:attribute name="schemeVersionID" type="xsd:token"
>>> use="optional"/>
>>>                 <xsd:attribute name="schemeAgencySchemeID"
>>> type="xsd:token" use="optional"/>
>>>                 <xsd:attribute name="schemeAgencySchemeAgencyID"
>>> type="xsd:token" use="optional"/>
>>>                 <xsd:attribute name="schemeDataURI" type="xsd:anyURI"
>>> use="optional"/>
>>>                 <xsd:attribute name="schemeURI" type="xsd:anyURI"
>>> use="optional"/>
>>>             </xsd:extension>
>>>         </xsd:simpleContent>
>>>     </xsd:complexType>
>>
>>
>> i understand it to mean that IdentifierTypes are now normalizedStrings.
>> however the schemeID, schemeAgencyID, etc... which are also
>>'identifier's, must be tokens.  so are we saying you can have embedded
>>spaces within an identifier - except the identifiers used as attributes
>>of an identifier???
>>
>>Chin Chee-Kai wrote:
>>
>>> On Sun, 7 Sep 2003, Tim McGrath wrote:
>>>
>>>>> PS chee-kai - i think your definitions are inconsistent- how can we
>>>>> change 'code' and 'identifier' to be 'normalizedString' and yet have
>>>>> their own internal codes and identifiers still as 'tokens'?
>>>>
>>>
>>> I could have erred, but in this case, I didn't quite catch
>>> what or where you're pointing out.
>>> The change for CodeType was only on one of its attributes called
>>> 'name', whose original type was xsd:token and now is
>>> xsd:normalizedString.
>>> The content type for CodeType remains as xsd:token.
>>>
>>> The change for IdentifierType was to have its content type
>>> changed from original xsd:token to xsd:normalizedString
>>> following Stephen's discussion in NDR, Ken's comment, and
>>> generally no disagreement with the idea.
>>>
>>> Could you elaborate please?
>>>
>>> Thanks.
>>>
>>>
>>>
>>> Best Regards,
>>> Chin Chee-Kai
>>> SoftML
>>> Tel: +65-6820-2979
>>> Fax: +65-6743-7875
>>> Email: cheekai@SoftML.Net
>>> http://SoftML.Net/
>>>
>>>
>>>
>>
>>--
>>regards
>>tim mcgrath
>>phone: +618 93352228
>>postal: po box 1289   fremantle    western australia 6160
>>
>>
>>
>>
>>
>>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.
>>
>>




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