ubl-lcsc message

Subject: XSD data types - was Re: [ubl-lcsc] Re: UBL 0.81 CCT draft-9-mod

From: Tim McGrath <tmcgrath@portcomm.com.au>
To: Chin Chee-Kai <cheekai@softml.net>
Date: Mon, 08 Sep 2003 11:11:39 +0800

thanks, i just wanted to know that you recognised the problem. your arguments add strength to the idea that it is very subjective about when we need to restrict content formats.

whilst there is some appeal about the schema-validation of data types, in practice this can create problems. most EDI people will be familair with the trap of enforced data types - like murphy's law, someone always has an exception to the rule.

we need to consider the following...

1. w.r.t. systems architectures. what happens if the data validation of the schema parser fails? typically, it is the logic of the processing application that knows how to deal with this - so why not let it do the validation.

2. do we need to make these decisions up-front? could not specific implementors extend our schemas to add the facets necessary for this type of validation if they wanted it?

3. if we accept this is a valid tactic then we should revisit the use of XSD dateTime as well.

Maybe we are trying to be too smart here. the critical requirement for UBL is for semantic clarity, not presentation of data.

Chin Chee-Kai wrote:

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.




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.

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

Follow-Ups:
- Re: [ubl-lcsc] XSD data types - was Re: [ubl-lcsc] Re: UBL 0.81 CCT draft-9-mod
  - From: Chin Chee-Kai <cheekai@softml.net>

References:
- Re: [ubl-lcsc] Re: UBL 0.81 CCT draft-9-mod
  - From: Chin Chee-Kai <cheekai@softml.net>