[xsd-users] About xsd list

[badia]

Dear xsd users

About xsd list, we agree that all the items in a list are of the same 
primitive data type and any value inside an xml tag is considered as a 
single element.
What we do is that we take advantage of this last characteristic to do 
comparisons between lists e.g. if a list has a key status then we can 
check the validity of the document.
In our business domain, we have cases with a lot of items in a list 
(1024 or more)
We also use the list element as a contracted form for a list of pairs of 
items e.g. list(1 2 3)
to represent (12 13 23) ; since we typically have 64 items in a list, 
it's obviously more convenient than a sequence of 2016 items, see the 
example in the attachment.
In c++, we use the standard vector class. XBinder uses its own container 
for this while xsc apparently uses vectors (ref 
www.cs.wustl.edu/~schmidt/PDF/XSC_ACMSE.pdf")  and we consider this as a 
good feature. We would really like to see this in xsd as well !

Apart from that, what we mean by 'reader' is the  'driver' equivalent  
to parse an xml instance.

Regards
Boris Kolpackov wrote:

>Frederic,
>
>badia <badia at mesiog.obspm.fr> writes:
>
>  
>
>>First, xsd complains a lot about our xsd schemas syntax. Apart from the
>>things I mentioned to Boris so far, there is a new one concerning the
>>list element, I'm sending an attachment of a schema example which
>>contains one.
>>    
>>
>
>xsd:list construct is not yet supported by xsd. This feature is of very
>limited use (since it can only be used with certain types and uses space
>as delimiter) so it has somewhat lower priority on our list. Would that
>be possible for you to use sequence instead?
>
><xsd:complexType name="Tab1DataCol1Type">
>  <xsd:sequence>
>    <xsd:element name="el" type="xsd:int" maxOccurs="unbounded"/>
>  </xsd:sequence>
></xsd:complexType>
>
>This solution is a bit more verbose in the instance document
>(i.e., you have "<el>1</el> <el>2</el> <el>3</el>" instead of
>"1 2 3") but it is much more flexible.
>
>As of the problem with the anonymous types, we are working on the
>morphing backend that will automatically "name" anonymous types.
>It will appear in the next release which is due later this week or
>early next week.
>
>
>  
>
>>Second thing is it would be nice to see xsd generating a makefile and a
>>reader for the C++ classes just like xbinder does but I don't really
>>know what your schedule is and how much time you would be prepared to
>>spend on that ...
>>    
>>
>
>I am not quite sure what you mean by "reader". As of the makefiles, we
>think this feature will be of a limited use. Most projects have their
>own build systems with their own ways of writing makefiles, etc. If all
>you need is a temporary makefile just to try things out then it is quite
>easy to copy one of the makefiles found in the examples directory and
>modify it to your needs.
>
>One makefile-related thing that we do plan to implement is automatic
>dependency generation, similar to what gcc -M does.
>
>hth,
>-boris
>  
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: usecaselist.zip
Type: application/zip
Size: 1101 bytes
Desc: not available
Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20050913/ab149675/usecaselist.zip