Christian,
This dovetails into the response I was preparing for John. The initial extended
schema I tried used <xs:element name="LLRPStatus" type="llrp:LLRPStatus"/>, but
the validator tried to find LLRPStatus within the extended namespace, not llrp
(LTK-XML). Modifying example2.xsd to use the name/type attributes instead of
ref yielded the following from XMLStarlet:
$ xml val -e --xsd example2.xsd example2.xml
example2.xml:7: element LLRPStatus: Schemas validity error : Element
'{http://www.llrp.org/ltk/schema/core/encoding/xml/1.0}LLRPStatus': This
element is not expected. Expected is (
{http://ltk.example.com/ltk/schema/encoding/xml/0.1}LLRPStatus ).
example2.xml - invalid
This is when I found: http://www.w3schools.com/schema/el_element.asp. Under the
attribute description, it states that ref may include a namespace prefix, while
type does not make any mention of namespace. What I believe is happening is by
defining name, the element is now a member of the extended namespace, and thus
must be prefixed with the extended namespace before the child elements may be
validated against the core namespace (after the validator follows the type
attribute). Modifying example2.xml to prefix LLRPStatus as if it were in the
extended namespace validates properly against the name/type XSD. I tested
invalid content within LLRPStatus and it correctly identified the error against
the core LTK-XML namespace.
<example:LLRP_CUSTOM_MESSAGE MessageID="1001"
xmlns:example="http://ltk.example.com/ltk/schema/encoding/xml/0.1";
xmlns:llrp="http://www.llrp.org/ltk/schema/core/encoding/xml/1.0";
xmlns="http://www.llrp.org/ltk/schema/core/encoding/xml/1.0";>
<example:LLRPStatus>
<StatusCode>M_Success</StatusCode>
<ErrorDescription></ErrorDescription>
</example:LLRPStatus>
</example:LLRP_CUSTOM_MESSAGE>
But I can't believe this is the appropriate way to include a core LLRP
parameter, by creating an element with the same name in the extended namespace.
Thanks,
C
-----Original Message-----
From: Christian Floerkemeier [mailto:[email protected]]
Sent: Thursday, June 04, 2009 11:04 AM
To: LLRP Toolkit Development List
Subject: Re: [ltk-d] Recommended change to llrp-1x0.xsd
Chris,
I do not understand why it is necessary to reference llrp:LLRPStatus.
Why wouldn't defining it the conventional way with name and type the
conventional way work for you?
e.g. <xs:element name="LLRPStatus" type="llrp:LLRPStatus" />
instead of <xs:element ref="llrp:LLRPStatus" />.
Even, if you LLRPStatus was defined under the extension name space,
referencing a complex type would not be allowed (as mentioned in the
text you quoted).
Christian
John R. Hogerhuis wrote:
> On Thu, Jun 4, 2009 at 9:55 AM, Chris Delaney <[email protected]>
> wrote:
>
>> As these are (mostly) recently released products, it is not clear to me that
>> the desired behavior is possible when only importing complex types (i.e. not
>> having the imported complex types declared as global elements). In fact, the
>> paragraph following the third example at:
>> http://www.w3.org/TR/xmlschema-0/#DefnDeclars
>> seems to imply exactly what we are finding. The second sentence reads, "In
>> general, the value of the ref attribute must reference a global element,
>> i.e. one that has been declared under schema rather than as part of a
>> complex type definition." It also goes on to state the limitation we
>> originally tried to avoid, that using ref= means the global elements may
>> exist as the root element within an instance document.
>>
>
> FWIW, I read that differently. I think all the complex types in
> question are declared directly under the schema element so given
> import, ref should work. I think what they are getting at there is
> that it cannot be something nested within a complex type.
>
> I think we need an XML expert to weight in here as to what we're doing wrong.
>
> Otherwise, what is "import" tag for?
>
> -- John.
>
> ------------------------------------------------------------------------------
> OpenSolaris 2009.06 is a cutting edge operating system for enterprises
> looking to deploy the next generation of Solaris that includes the latest
> innovations from Sun and the OpenSource community. Download a copy and
> enjoy capabilities such as Networking, Storage and Virtualization.
> Go to: http://p.sf.net/sfu/opensolaris-get
> _______________________________________________
> llrp-toolkit-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/llrp-toolkit-devel
------------------------------------------------------------------------------
OpenSolaris 2009.06 is a cutting edge operating system for enterprises
looking to deploy the next generation of Solaris that includes the latest
innovations from Sun and the OpenSource community. Download a copy and
enjoy capabilities such as Networking, Storage and Virtualization.
Go to: http://p.sf.net/sfu/opensolaris-get
_______________________________________________
llrp-toolkit-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/llrp-toolkit-devel
------------------------------------------------------------------------------
OpenSolaris 2009.06 is a cutting edge operating system for enterprises
looking to deploy the next generation of Solaris that includes the latest
innovations from Sun and the OpenSource community. Download a copy and
enjoy capabilities such as Networking, Storage and Virtualization.
Go to: http://p.sf.net/sfu/opensolaris-get
_______________________________________________
llrp-toolkit-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/llrp-toolkit-devel
