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-ndrsc] Analysis and Response to Gunther's last minute RT, CCT & code lists


Hello Chee-Kai,

I added my answers under each of your comments.

Kind regards,

	Gunther

-----Original Message-----
From: Chin Chee-Kai [mailto:cheekai@softml.net] 
Sent: Montag, 13. Oktober 2003 11:57
To: UBL LCSC; UBL NDRSC
Subject: [ubl-ndrsc] Analysis and Response to Gunther's last minute RT, CCT & code lists


Hello folks,

I was thinking earlier about creating a subdirectory under
"xsd/cct/" in which Gunther will be fully responsible for
presence, conformance with NDR and compatibility with
other contents in "xsd/" for whatever he puts in there.

The good points in all earnest and favor brought by Gunther
has been to introduce the concept that UBL models should build
upon RT which builds upon CCT.  As of model draft-11, I believe
Tim & Stephen have worked out the Representation Terms to
take only from those listed in RT as provided by Gunther's 
schemas.

The last minute information brought by Gunther is, however, 
not so welcome.  It has caused great disturbance to LC and
FP as a chain reaction.  More responsible behavior would have
been much appreciated.

Irregardless of the late communication, the changeover from
CCT to RT is deemed sufficiently important that we lose more
nights of sleep and weekends to try to cope with the changes.




But on second thought, I think I don't wish to let the schemas
in "xsd/" get tainted due to his disregard for things like:

- some of the schemas, most importantly RT & CCT and also
  the Gunther's proprietary code list schemas, are not parseable
  XML files.  They lack proper namespace definitions, and 
  in certain places, proper schema import elements.

<GS>This are not proprietary code lists schemas. This code lists based on the rule 29!!!</GS>


- introducing his own code list namespaces that is different
  from the conclusion from code list group,

<GS>NDRSC decided this namespace representation and I thought, the NDRSC is responsinle for this conventions.</GS>

- introducing on his own accord new code lists (MIME?) that
  nobody from code list group seems to have known,

<GS>MIME is a supplementary component of Binary Object. Type of CCTS V1.9 and CCTS V2.0. The list of MIME based on www.ietf.org </GS>

- in introducing MIME, it induces questions about other
  IETF code lists that remain not included,

<GS>MIME is a fixed supplementary component of "Binary Object. Type" and shouldn't need more discussion.</GS>

- questionable code list implementations 

  (MIME code list maxLength having 3 when all the enumerated values
  mostly exceed 3)

<GS>This was a cut and paste change. I made this change.</GS>

- inconsistent implementation of code list against other
  UBL schema components 

  (RT has GraphicType, PictureType, VideoType and SoundType, 
  yet his implemented MIME code list has absolutely NO 
  support of image/*, audio/*, video/*, and appears to be 
  a haphazard and arbitrary listing of whatever happens to 
  be there).

<GS>But exactly this describes the CCTS V1.9</GS>


- incomplete implementation of code list against usage in
  other UBL schema components.  

  (MIME type definitions are structure-rich [RFC-2045 & 
  related standards].  Minimally, used as content-type 
  descriptions, there needs to be a corresponding minor 
  type for each major type.  Gunther's list does not permit 
  clear use of the values, does not permit clear implementation
  of validation, and when used in the only place of 
  RT:BinaryObjectType, does not describe clearly nor is 
  useful for understanding exactly what content type the 
  binary object contains).

<GS>You can read all in the CommonCoreComponent Paper about the binary object contains.</GS>

- improper and non-uniform treatment of code lists

  (RT depends selectively on CurrencyCode and LanguageCode lists,
  but then CountryCode list depends in turn on RT.
  This effectively means, absurd as it sounds, without 
  CurrencyCode nor LanguageCode, we cannot use CountryCode.)

<GS>No of the supplementary components using the CountryCode. I imported only this code list, which will be necessary for the supplementary components</GS>

- not following NDR's filenaming but uses his own proprietary
  naming that does not following "UBL-" + componentName + version,
  and has mixed use of underscores "_" and dashes "-".
  This, although seemingly a minor fix, has major impact on
  all higher-level schemas that import them.

<GS>See R29h</GS>

- not following NDR's global element definition rule. 
  There's clear absence of elements defined in RT for each 
  complexType.

<GS>There's no global declared element in the RT schema</GS>

- not following NDR's ContentType naming requirement for
  simpleType restrictions.

<GS>The simpleType restrictions is in each code list schema.</GS>

These are just *some* of the problems observed.  It is beginning
to take toll on various people when Gunther provides basic
components that require massive editing each time he sends
an update.  The point of listing the above is not to help
Gunther edit his schema design problems, but to illustrate
that an independent submission of work that doesn't go along with
discussions and conclusions reached so far causes more problems
to production team of people than help.

We will, however, take what good there is in those schemas,
namely the need to take names from RTs only.

It has therefore come to my reluctant conclusion that at this
point, we can only adopt a simplified version of his RT and CCT
contribution (because CCT is used quite heavily by RT).  This 
would meet the primary aim of aligning  LC's draft-8 with CCT
requirements.  And that is about all I think we can do at this
point.

The simplified version will discard code list implementations.




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.


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