Home » Archived » XML Schema Definition (XSD) » Analysis of XML Schema specific annotations, properties in Resource Impl.
| Analysis of XML Schema specific annotations, properties in Resource Impl. [message #68174] |
Fri, 19 May 2006 10:29  |
Eclipse User |
|
|
|
Originally posted by: mathiasfrz.web.de
Hi,
I tried the serialization of XML Schema based (annotated) Ecore models.
I tried this using the XMLResource.OPTION_EXTENDED_META_DATA option (and
all other generated options) in the generated RessourceFactory.
The result was an xml instance of the Schema which differentiates between
attributes and elements as specified in the schema (example: nested
elements specified in the schema are serialized as nested elements in the
XML instance of the schema).
After commenting out of XMLResource.OPTION_EXTENDED_META_DATA (and all the
other options) all nested elements specified in the schema were serialized
as attributes in a resulting xml instance of the schema.
On the other hand, I found no checks of xml schema defined restrictions
(like "minOccurs", "maxOccurs", "xmlns" for any) for the serialization of
instances of the XMLSchema. Did I something wrong?
... Or results the option OPTION_EXTENDED_META_DATA only in analysis of
the Annotation "kind" of the Ecore model ... and nothing more?
Thank you very much! (And thank you for your last very fast (and helpful)
answer!!!)
Mathias
|
|
|
| Re: Analysis of XML Schema specific annotations, properties in Resource Impl. [message #68185 is a reply to message #68174] |
Fri, 19 May 2006 11:57  |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
This is a multi-part message in MIME format.
--------------040608070808040600060002
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Mathias,
The constraints, if any, are generated as part of the validator.
The EMF Validation Framework Overview
< http://www.eclipse.org/emf/docs.php?doc=references/overview/ EMF.Validation.html>
EObjectValidator does all the constraint checking for a dynamic model
and for generated models there will be a generated validator, if there
are constraints in the model. Constraints such as min/maxOccurs simply
map to multiplicities of the features and can those are checked by the
reflective EObjectValidator. Constraints such as facet constraints on
simple types will result in a generated validator. In general, you can
use Diagnostician.INSTANCE.validate(EObject) to check all the
constraints; that's effectively what right clicking and running
"Validate" in the generated editor will do.
Mathias wrote:
> Hi,
> I tried the serialization of XML Schema based (annotated) Ecore
> models. I tried this using the XMLResource.OPTION_EXTENDED_META_DATA
> option (and all other generated options) in the generated
> RessourceFactory. The result was an xml instance of the Schema which
> differentiates between attributes and elements as specified in the
> schema (example: nested elements specified in the schema are
> serialized as nested elements in the XML instance of the schema).
> After commenting out of XMLResource.OPTION_EXTENDED_META_DATA (and all
> the other options) all nested elements specified in the schema were
> serialized as attributes in a resulting xml instance of the schema. On
> the other hand, I found no checks of xml schema defined restrictions
> (like "minOccurs", "maxOccurs", "xmlns" for any) for the serialization
> of instances of the XMLSchema. Did I something wrong?
> .. Or results the option OPTION_EXTENDED_META_DATA only in analysis of
> the Annotation "kind" of the Ecore model ... and nothing more?
> Thank you very much! (And thank you for your last very fast (and
> helpful) answer!!!)
>
> Mathias
>
>
--------------040608070808040600060002
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Mathias,<br>
<br>
The constraints, if any, are generated as part of the validator. <br>
<blockquote><a
href=" http://www.eclipse.org/emf/docs.php?doc=references/overview/ EMF.Validation.html">
|
|
|
| Re: Analysis of XML Schema specific annotations, properties in Resource Impl. [message #68197 is a reply to message #68185] |
Fri, 19 May 2006 12:38 |
| Eclipse User |
|
|
|
Originally posted by: mathiasfrz.web.de
Thank you for the quick answer! Now the verification of my constraints
works!
For understanding (and for my master thesis :-))
What you mean is that the resource implementation only uses the annotated
kind (element, attribute,..) of the ecore model elements for serializing
XML Schema instances (XML Documents).
This means, that the option OPTION_EXTENDED_META_DATA only results in an
analysis of the ExtendedMetaData.kind of the EObjects.
For checking other XML Schema specific details (such as min/maxOccurs,
wildcards) the Validator is used. Is this correct?
Thank you again,
Mathias
|
|
|
| Re: Analysis of XML Schema specific annotations, properties in Resource Impl. [message #68208 is a reply to message #68197] |
Fri, 19 May 2006 12:50 |
| Eclipse User |
|
|
|
Originally posted by: mathiasfrz.web.de
(better formulation of my question)
Hi Ed Merks,
Thank you for the quick answer! Now the verification of my constraints
works!
For understanding (and for my master thesis :-))
What you mean is that the resource implementation only uses the annotated
kind (element, attribute,..) of the ecore model elements for serializing
XML Schema instances (XML Documents). This means, that the option
OPTION_EXTENDED_META_DATA only results in an analysis of the
ExtendedMetaData.kind of the EObjects. Other XML Schema specific details
(such as min/maxOccurs, wildcards) have no influence to the serialization
(resource implementation), but to the Validator. Is this correct?
Thank you again,
Mathias
|
|
|
| Re: Analysis of XML Schema specific annotations, properties in Resource Impl. [message #68219 is a reply to message #68208] |
Fri, 19 May 2006 13:02 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Mathias,
The annotation information comes into play in other places as well. For
example, an element wildcard's feature will only allow features that
correspond to global elements in its contents (and it enforces the
namespace constraint on the namespace of those elements as well). The
OPTION_EXTENDED_META_DATA is used merely to instruct the serializer that
it should respect the annotations, rather than behave as if there are no
annotations.
Mathias wrote:
> (better formulation of my question)
>
> Hi Ed Merks,
>
> Thank you for the quick answer! Now the verification of my constraints
> works!
>
> For understanding (and for my master thesis :-))
>
> What you mean is that the resource implementation only uses the
> annotated kind (element, attribute,..) of the ecore model elements for
> serializing XML Schema instances (XML Documents). This means, that the
> option OPTION_EXTENDED_META_DATA only results in an analysis of the
> ExtendedMetaData.kind of the EObjects. Other XML Schema specific
> details (such as min/maxOccurs, wildcards) have no influence to the
> serialization (resource implementation), but to the Validator. Is this
> correct?
>
> Thank you again,
>
> Mathias
>
|
|
| |
| Re: Analysis of XML Schema specific annotations, properties in Resource Impl. [message #68241 is a reply to message #68231] |
Tue, 23 May 2006 11:39 |
| Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Mathias,
XMLMap predates ExtendedMetaData and it is not as expressive and hence
not as accurate at supporting all the XML Schema features.
Mathias wrote:
> Hi Ed Merks,
>
> Thank you for your answer! I analyzed the classes XMLSaveImpl and
> XMLHelperImpl to get a better understanding of the XML Schema specific
> serialization of Ecore instances. My question: What is the role of the
> XMLMap class in difference to the ExtendedMetaData class?
>
> Thank you very much!!!
>
> Mathias
>
>
|
|
| |
| Re: Analysis of XML Schema specific annotations, properties in Resource Impl. [message #598106 is a reply to message #68174] |
Fri, 19 May 2006 11:57 |
 Ed Merks
Messages: 33136
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------040608070808040600060002
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Mathias,
The constraints, if any, are generated as part of the validator.
The EMF Validation Framework Overview
< http://www.eclipse.org/emf/docs.php?doc=references/overview/ EMF.Validation.html>
EObjectValidator does all the constraint checking for a dynamic model
and for generated models there will be a generated validator, if there
are constraints in the model. Constraints such as min/maxOccurs simply
map to multiplicities of the features and can those are checked by the
reflective EObjectValidator. Constraints such as facet constraints on
simple types will result in a generated validator. In general, you can
use Diagnostician.INSTANCE.validate(EObject) to check all the
constraints; that's effectively what right clicking and running
"Validate" in the generated editor will do.
Mathias wrote:
> Hi,
> I tried the serialization of XML Schema based (annotated) Ecore
> models. I tried this using the XMLResource.OPTION_EXTENDED_META_DATA
> option (and all other generated options) in the generated
> RessourceFactory. The result was an xml instance of the Schema which
> differentiates between attributes and elements as specified in the
> schema (example: nested elements specified in the schema are
> serialized as nested elements in the XML instance of the schema).
> After commenting out of XMLResource.OPTION_EXTENDED_META_DATA (and all
> the other options) all nested elements specified in the schema were
> serialized as attributes in a resulting xml instance of the schema. On
> the other hand, I found no checks of xml schema defined restrictions
> (like "minOccurs", "maxOccurs", "xmlns" for any) for the serialization
> of instances of the XMLSchema. Did I something wrong?
> .. Or results the option OPTION_EXTENDED_META_DATA only in analysis of
> the Annotation "kind" of the Ecore model ... and nothing more?
> Thank you very much! (And thank you for your last very fast (and
> helpful) answer!!!)
>
> Mathias
>
>
--------------040608070808040600060002
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Mathias,<br>
<br>
The constraints, if any, are generated as part of the validator. <br>
<blockquote><a
href=" http://www.eclipse.org/emf/docs.php?doc=references/overview/ EMF.Validation.html">
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| | |
| Re: Analysis of XML Schema specific annotations, properties in Resource Impl. [message #598121 is a reply to message #68208] |
Fri, 19 May 2006 13:02 |
Ed Merks
Messages: 33136
Registered: July 2009 |
Senior Member |
|
|
Mathias,
The annotation information comes into play in other places as well. For
example, an element wildcard's feature will only allow features that
correspond to global elements in its contents (and it enforces the
namespace constraint on the namespace of those elements as well). The
OPTION_EXTENDED_META_DATA is used merely to instruct the serializer that
it should respect the annotations, rather than behave as if there are no
annotations.
Mathias wrote:
> (better formulation of my question)
>
> Hi Ed Merks,
>
> Thank you for the quick answer! Now the verification of my constraints
> works!
>
> For understanding (and for my master thesis :-))
>
> What you mean is that the resource implementation only uses the
> annotated kind (element, attribute,..) of the ecore model elements for
> serializing XML Schema instances (XML Documents). This means, that the
> option OPTION_EXTENDED_META_DATA only results in an analysis of the
> ExtendedMetaData.kind of the EObjects. Other XML Schema specific
> details (such as min/maxOccurs, wildcards) have no influence to the
> serialization (resource implementation), but to the Validator. Is this
> correct?
>
> Thank you again,
>
> Mathias
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
| Re: Analysis of XML Schema specific annotations, properties in Resource Impl. [message #598132 is a reply to message #68231] |
Tue, 23 May 2006 11:39 |
Ed Merks
Messages: 33136
Registered: July 2009 |
Senior Member |
|
|
Mathias,
XMLMap predates ExtendedMetaData and it is not as expressive and hence
not as accurate at supporting all the XML Schema features.
Mathias wrote:
> Hi Ed Merks,
>
> Thank you for your answer! I analyzed the classes XMLSaveImpl and
> XMLHelperImpl to get a better understanding of the XML Schema specific
> serialization of Ecore instances. My question: What is the role of the
> XMLMap class in difference to the ExtendedMetaData class?
>
> Thank you very much!!!
>
> Mathias
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
Goto Forum:
Current Time: Thu Apr 18 21:21:43 GMT 2024
Powered by FUDForum. Page generated in 0.02852 seconds |
] 
Search
Help
Register
Login
Home
