|
|
|
|
|
Re: EMF: Force load as a given type [message #1080786 is a reply to message #1080766] |
Tue, 06 August 2013 11:25 |
Ed Merks Messages: 33140 Registered: July 2009 |
Senior Member |
|
|
Rob,
Comments below.
On 06/08/2013 12:59 PM, Rob Mising name wrote:
> Hi Ed,
>
> Sorry to disagree with you, but according to the schema spec it is
> valid to have this, the schema shows the case where there is BOTH
>
> 1) A complex type called NewOperation
> 2) An Anonymous complex type called NewOperation
This sentence is a contradiction. An anonymous thing has no name. You
have an element called NewOperation and yes, that isn't a name clash
with respect to a complex type called NewOperation.
>
> So there is a traditional "name clash" at the top level, but they are
> of two different types (one element and one complex type), so the
> schema spec allows this.
Yes, that's allowed.
>
> This would also be the case for:
>
> <xsd:complexType name="NewOperation">
> <xsd:sequence>
> <xsd:element name="e1" type="xsd:string"></xsd:element>
> </xsd:sequence>
> </xsd:complexType>
> <xsd:element name="NewOperation" type="xsd:string"/>
Yes that's allowed too.
>
>
> So one complex type and a simple element - both with the same name.
Yep.
>
> If the names do not clash then we have managed to get EMF to handle
> this case (By adding a hidden element into the ecore's DocumentRoot
> for the top level complex type - with a name matching the type).
Yes.
>
> However this does not work when there is something else with the same
> name as the code in:
>
> BasicExtendedMetaData.getLocalElement(EClass eClass, String namespace,
> String name)
What doesn't work?
>
> it looks for the first matching element and returns that.
There can only be one element defined for a given namespace and name.
> However in our case there could now be two with a matching name.
I've not seen you define two elements with the same name.
> Ideally I suppose in our situation we would also want it to somehow
> check the try of the element to ensure that it matches.
I don't know what you mean.
>
> I hope I have done a better case of explaining what we have in our system.
No, because everything you said above is about whether the schema is
valid, yet everything I said earlier was about whether the instance XML
conforms to the schema. It doesn't. You can't make it work. You
either have to change the schema to match your instance or you have to
change the instance conform to your schema.
> Any ideas or hints you have are really appreciated.
So again, if you have an element in your schema with an anonymous type
it will never ever be possible to use an xsi:type for that element in an
XML instance because it will never ever be possible to define a subtype
of that element's schema type because you can only define subtypes for
named types not for anonymous types.
>
> Thanks
>
> Rob
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
|
|
|
Re: EMF: Force load as a given type [message #1080913 is a reply to message #1080895] |
Tue, 06 August 2013 14:31 |
Ed Merks Messages: 33140 Registered: July 2009 |
Senior Member |
|
|
Rob,
Comments below.
On 06/08/2013 4:04 PM, Rob Mising name wrote:
> Hi Ed,
>
> I did previously check the schema with:
> 1) Eclipse
> 2) XMLSpy
>
> And the schema is valid, although I do admit confusing.
Yes, I keep saying the schema is valid.
>
> From the Spec, I guess it does not need to satisfy 1.2.1.2.4 as it
> satisfies 1.2.1.1
But it doesn't satisfy 1.2.2.
>
> If you had a schema that was just:
>
> <xsd:complexType name="NewOperation">
> <xsd:sequence>
> <xsd:element name="e1" type="xsd:string"></xsd:element>
> </xsd:sequence>
> </xsd:complexType>
>
> Then the following XML would be fine:
>
> <file:NewOperation xsi:type="file:NewOperation"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:file="http://www.example.org/NewFile/">
> <e1>asgdfg</e1>
> </file:NewOperation>
No because the root element must correspond to a global element declared
in the schema.
>
>
> So adding additional information to the schema (that is still valid)
> and does not alter the existing definition, such as:
>
> <xsd:element name="NewOperation">
> <xsd:complexType>
> <xsd:sequence>
> <xsd:element name="in" type="xsd:string"/>
> </xsd:sequence>
> </xsd:complexType>
> </xsd:element>
>
That declares the name for the root element so is necessary for a root
NewOperation element to be valid at all.
> Should not change that the XML is still valid.
You seem stuck on the point of schema validity which is not my point.
My point is whether the XML conforms to the valid schema.
>
> I do want to stress that I really appreciate all the support you give
> on this forum, and please be assured I do spend time investigating and
> verifying things before I post to try and ensure I am not wasting your
> time.
I can't emphasize enough that just your NewOperation element declaration
demands that if <NewOperation> appears as the root element it must
contain a nested <in> element, it's a required element in the content
type. That constraint can't be restricted away and can't be eliminated
via extension (and in any case, extension and restriction are not
possible for the anonymous complex type) so it's not possible to specify
a valid derived type via xsi:type in the XML and it's simply not
possible to avoid the necessity for an <in> element to appear...
>
> Thanks
>
> Rob
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
|
Re: EMF: Force load as a given type [message #1080940 is a reply to message #1080932] |
Tue, 06 August 2013 15:23 |
Ed Merks Messages: 33140 Registered: July 2009 |
Senior Member |
|
|
Rob,
Comments below.
On 06/08/2013 5:10 PM, Rob Mising name wrote:
> Ah! I think I see where you are coming from now.
>
> You mean that the: xsi:type="file:NewOperation" part in the XML is
> what makes it invalid - because in the first example it is refering to
> a type.
Yes, so there must be a type definition for it in the schema.
>
> Then without xsi:type="file:NewOperation" in the second example - it
> would mean it matches with the element - then in turn has incorrect
> element values within the complex type.
Yes.
>
> Think I've got you now!
>
> I guess this in turn means that there is no way of having XML validate
> against the complete schema, other than with the element version of
> "NewOperation" - it sort of "obscures" the complex type with the same
> name.
Yes, the NewOperation complex type isn't really usable directly in an
xsi:type, other than for elements of type xsd:anyType.
>
> Thanks
>
> Rob
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Powered by
FUDForum. Page generated in 0.04027 seconds