If the string representation should stay, there should at least be an
indication of this within the llrpdef.xml, i.e.
it should be changed to something like
<field type="u8v" name="ProtocolID" enumeration="AirProtocols"/>
instead of
<field type="u8v" name="ProtocolID"/>
If not, there is no way (or at least I don't see one) to handle this
correctly for LTKJava (as LTKJava uses a automatic generation approach
and relys on what is given by llrpdef.xml)
- Basil
Christian Floerkemeier wrote:
> I am not in favour of shortening the strings.
>
> I just hope that there won't be any protocol identifiers with whitespaces in
> the future like "ISO 18000-6B". Clients would have to parse the text field
> and distinguish whitespace as list item delimiters from whitespaces in the
> protocol identifiers themselves.
>
> In Table 3, the LLRP spec says values 2-255 are reserved for future use. The
> interpretation in llrpdef.xml and LLRP.xsd is that values other than 0 and 1
> are not allowed. I wonder whether this is too restrictive. Does future use
> imply that this will be possibly handled in LLRP version 1.x? or via a
> separate document in which these values are assigned?
>
> - Christian
>
>
>
>> -----Original Message-----
>> From: [EMAIL PROTECTED]
>> [mailto:[EMAIL PROTECTED] On
>> Behalf Of John R. Hogerhuis
>> Sent: Dienstag, 18. Dezember 2007 13:09
>> To: LLRP Toolkit Development List
>> Subject: Re: [ltk-d] XML encoding of PerAntennaAirProtocol -
>> inconsistencybetween llrp-1x0.xsd and llrp-1x0.xml?
>>
>> A major purpose of LTK-XML is to make a human-readable form
>> of binary LLRP. So, I suggest to leave it as a string when
>> outputting XML.
>>
>> Practically I can see how using an enum here will appreciably
>> increase the size of lists in the textual format. Perhaps we
>> could change
>>
>> <xs:simpleType name="AirProtocols">
>> <xs:restriction base="xs:string">
>> <xs:enumeration value="EPCGlobalClass1Gen2"/>
>> <xs:enumeration value="Unspecified"/>
>> </xs:restriction>
>> </xs:simpleType>
>>
>> to something like:
>> <xs:simpleType name="AirProtocols">
>> <xs:restriction base="xs:string">
>> <xs:enumeration value="C1G2"/>
>> <xs:enumeration value="Unspec"/>
>> </xs:restriction>
>> </xs:simpleType>
>>
>> This is a deviation from the indentifier spellings used in
>> the spec, which we have tried to maintain, but if this is a
>> problem I wouldn't be opposed to this change.
>>
>> Other than size of the XML text file I cannot see any good
>> reason to display integers instead of the enumerated strings.
>>
>> -- John.
>>
>> --------------------------------------------------------------
>> -----------
>> SF.Net email is sponsored by:
>> Check out the new SourceForge.net Marketplace.
>> It's the best place to buy or sell services for just about
>> anything Open Source.
>> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.n
> et/marketplace
>> _______________________________________________
>> llrp-toolkit-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/llrp-toolkit-devel
>>
>
>
> -------------------------------------------------------------------------
> SF.Net email is sponsored by:
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services
> for just about anything Open Source.
> http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> _______________________________________________
> llrp-toolkit-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/llrp-toolkit-devel
-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
llrp-toolkit-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/llrp-toolkit-devel
