For namespaceURL and schemaLocation, the type should
be other than xs:unsignedInt. I'm not sure of the exact name
of the right type. Some simple string.
-gww
_____
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Paul Dietrich
Sent: Tuesday, December 04, 2007 8:38 AM
To: LLRP Toolkit Development List
Subject: [ltk-d] changes to llrp definition schema llrpdef.xsd
We'd like to propose a few changes to the llrpdef.xsd schema as we learn
more about the LTK structured extension framework.
1) Add namespace prefix, schema location. Libraries that use the
llrpdef.xml and AcmeDef.xml to generate extension XML require knowing
the namespace for custom extensions and optionally knowing the
schemaLocation where the XXX.xsd schema lives. We propose to add a an
element to the llrpdef.sdl
<xs:complexType name="namespaceDefinition">
<xs:sequence>
<xs:element name="annotation" type="llrpdef:annotation"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="namespacePrefix" type="llrpdef:name"
use="required"/>
<xs:attribute name="namespaceURL" type="xs:unsignedInt"
use="required"/>
<xs:attribute name="schemaLocation" type="xs:unsignedInt"
use="required"/>
</xs:complexType>
This is similar to the vendorDefinition element but serves
to translate a namespacePrefix to a complete namespaceURL. Additional
attributes would be added to customMessage and customParameter to
include a namespace prefix.
<xs:complexType name="customParameterDefinition">
<xs:sequence>
<xs:element name="annotation" type="llrpdef:annotation"
minOccurs="0" maxOccurs="unbounded"/>
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element name="field" type="llrpdef:fieldDefinition"/>
<xs:element name="reserved" type="llrpdef:reservedDefinition"/>
</xs:choice>
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element name="parameter" type="llrpdef:parameterReference"/>
<xs:element name="choice" type="llrpdef:choiceReference"/>
</xs:choice>
<xs:sequence minOccurs="0" maxOccurs="unbounded">
<xs:element name="allowedIn"
type="llrpdef:allowedInParameterReference"/>
</xs:sequence>
</xs:sequence>
<xs:attribute name="name" type="llrpdef:name" use="required"/>
<xs:attribute name="vendor" type="llrpdef:name" use="required"/>
<xs:attribute name="namespacePrefix" type="llrpdef:name"
use="required"/>
<xs:attribute name="subtype" type="xs:unsignedInt" use="required"/>
</xs:complexType>
2) We currently define types CustomParameter and CustomMessage
which include information on the vendor, but enumerations and choices
are left as it. We propose to add customEnumeration and CustomChoice
which would have the same attributes (except subtype) as
customParameter.
3) There has been some concern over the limit of 255 custom
extension message per PEN. We don't forsee this as a problem in the
short term, but want to leave space for LTK structured extensions beyond
255. We'd like to have the LTK reserve subtype 255 for future
extensions. This would mean that libraries would have to error-out when
producing code for any custom extension that tries to use the 255
subtype.
4) We'd like to establish a formal rule for LTK libraries that
when generating code from custom extension.xml files. All references to
parameters within messages and other parameters not found in the file
are assumed to be from the llrp namespace. By creating this default
rule, this allows us to add an attribute at a later time if we want to
allow incorporation of one extension directly within another and not
through an extension point.
Comments?
Paul
-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
llrp-toolkit-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/llrp-toolkit-devel
