FW: [ciq] RE: Version 3.0 of CIQ Specs.

[Max Voskob <max.voskob@paradise.net.nz>]

Michael,

 

I agree that we may borrow some good ideas from UBL or, in fact, from anyone else if they add value. Lets look into UBL and what can be taken from there.

 

I had a problem with "string255" because today it's 255 and tomorrow its 256. What r we going to do then? Run a global replace on all schemas?

The way it is done now is that "string" sits in its own namespace and doesn;t clash with xs:string and it's easy to change the constraints on it.

I thought if taking it out into some sort of TYPES.XSD, but it's the only simple data type we declare apart from those enumerations. It doesn't make much sense to have a separate file for just one or 2 declarations.

We probably need to rename it into something like "ciq-string" to make it obvious that it's not xs:string.

 

Cheers,

Max

 

---

From: Michael.Roytman@vertexinc.com [mailto:Michael.Roytman@vertexinc.com]
Sent: Thursday, 14 July 2005 13:25
To: Max Voskob
Cc: ciq@lists.oasis-open.org
Subject: Re: [ciq] RE: Version 3.0 of CIQ Specs.

Max,

 

Points on complexity are well taken. We will need to balance complexity with maintainability of the specification. There is also consistency since UBL, Tax XML and other groups may choose to reuse CIQ schemas and code lists.

 

What about defining a "string"? It is a primitive data type defined within the XML Schema spec. We should have and alternative name "String255" or something to distinguish from xs:string. I was also wondering whether we should move all types into CIQ-types.xsd and just reference a single file instead of having some constructs declared in xAL-types and xNL-types.

 

I am not fixated on UBL by any means, but some of their rules make a lot of sense.

Regards,

 

Michael.

-----Max Voskob <max.voskob@paradise.net.nz> wrote: -----

To: ciq@lists.oasis-open.org
From: Max Voskob <max.voskob@paradise.net.nz>
Date: 07/13/2005 04:10PM
Subject: [ciq] RE: Version 3.0 of CIQ Specs.

Michael,

Thanx for your feedback. All valid points.

Alignment with UBL wasn't a requirement for CIQ, but simplicity and ease of implementation are.
Attribute naming can be changed to lCC if there is a need for this.
Putting every enumeration in a separate file and separate namespace will add unnecessary complexity.

Nonetheless, nothing is set in stone so far.

Looking forward for more info from you.

Cheers,
Max

-----Original Message-----
From: Michael.Roytman@vertexinc.com [mailto:Michael.Roytman@vertexinc.com]
Sent: Thursday, 14 July 2005 03:59
To: Ram Kumar; Max Voskob
Cc: ciq@lists.oasis-open.org
Subject: Re: Version 3.0 of CIQ Specs.


Gentlemen,

I am in the process of reviewing the CIQ 3.0 documentation and schemas. So far I have found the
information to be readable, logical and easy to understand. While reviewing the schemas, there are a
few discrepancies with the UBL Name and Design rules (if we choose to follow their recommendation)
that I would like to bring to your attention:
Attributes throughout the specifications should be in lowerCamelCase
[UBL NDR GNR9]
Enumerations-code lists should be provided in separate files to support
the modularity principles. As stated in the specification, values can be
added/modified/removed at a later time. To minimize the impact on the
entire structure, the impact should be limited to the code list
undergoing the changes, not the entire set of code lists.
Each code list must be maintained in its own namespace [UBL NDR NMS18]

Upon completion of my review, I will try to use the schemas to represent current work of Tax XML on
the Certificate of Residence project.
Kind regards,


Michael Roytman.

(See attached file: UBL-NDR-Checklist-1.0.pdf)


|---------+---------------------------->
| | Ram Kumar |
| | <kumar.sydney@gma|
| | il.com> |
| | |
| | 07/13/2005 04:54 |
| | AM |
| | Please respond to|
| | Ram Kumar |
| | |
|---------+---------------------------->

>---------------------------------------------------------------------------------------------------
----------------------------|
|
|
| To: "Michael.Roytman@vertexinc.com" <Michael.Roytman@vertexinc.com>
|
| cc: john.glaubitz@vertexinc.com, Max Voskob <max.voskob@paradise.net.nz>
|
| Subject: Re: Version 3.0 of CIQ Specs.
|

>---------------------------------------------------------------------------------------------------
----------------------------|




Hi Michael,

Thanks. I am sure you will find these schemas easier to implement as they are pretty flat structure.
If you need any assistance, please do not hesitate to contact me or Max. V will be more than happy
to assist. If you think something is missing, let us know.

Regards,

Ram

On 7/12/05, Michael.Roytman@vertexinc.com <Michael.Roytman@vertexinc.com>
wrote:
>
>
>
>
> Hello Ram,
>
> I am reviewing the specs and the schemas, and will update the Tax XML
group
> as well as the Certificate of Residence sub-group. I am also working
> to update the proof of concept that we presented in Sydney to use the
> CIQ
3.0
> constructs.
> Thanks,
>
> Michael.
>
>
> |---------+---------------------------->
> | | Ram Kumar |
> | | <kumar.sydney@gma|
> | | il.com> |
> | | |
> | | 07/12/2005 06:21 |
> | | AM |
> | | Please respond to|
> | | Ram Kumar |
> | | |
> |---------+---------------------------->
>
>---------------------------------------------------------------------------------------------------
----------------------------|

> |
|
> | To: john.glaubitz@vertexinc.com,
michael.roytman@vertexinc.com
|
> | cc:
|
> | Subject: Version 3.0 of CIQ Specs.
|
>
>---------------------------------------------------------------------------------------------------
----------------------------|

>
>
>
>
> Hi John and Michael,
>
> Can you please inform the TaxXML TC about the draft specs. of version
> 3.0 that is now available for review?
>
> Thank you,
>
> Regards,
>
> Ram
>
>
>
>



---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. You may a link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php