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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ciq-comment message

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


Subject: Public Comment


Comment from: fraser.crichton@solnetsolutions.co.nz

Name: Fraser Crichton
Title: XML Developer
Organization: Solnet Solutions
Regarding Specification: CIQ Version 3

Hi, 

I have some feedback from developer’s perspective. In general I think this is a very important standard and I hope that it will see significant uptake. However, there are some things that I hope you will give some consideration to in the planned version 3.  

I notice you are using XLink, which I think is a good idea, but I’m wary of its support in parsers and processors. Have you done much proof of concept work to clarify that this will work as intended? 

I understand that you want to make the schemas as extensible as possible and as a result have used- 

<xs:anyAttribute namespace="##other" processContents="lax"/>

However, this means that you have fully namespace qualified all your attributes and it’s not something I’ve seen elsewhere and indeed many of the standards I’ve looked at recommend against qualifying attributes. Again, I’d be interested to know what POC work you’ve done to see how the schemas will work with attributes from another namespace (I’m also not entirely convinced by the requirement for this as attributes generally are used to convey metadata and not significant information, however…). 

I saw recently some other feedback from Michael.Roytman@vertexinc.com on the version 3 spec and I’d like to reiterate some of the points made.

"Attributes throughout the specifications should be in lowerCamelCase [UBL NDR GNR9]”

- even if it’s not a goal of xCIQ to be compatible with UBL it’s easier on developers if you follow accepted practice which the UBL naming and design rules seems to be becoming.

“Enumerations-code lists should be provided in separate files to support the modularity principles.” 

- it may add complexity but it will also make versioning and customisation easier. 

Anyway, that’s my 2 cents worth. 

Thanks,

Fraser




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