Home » Modeling » EMF » XML namespaces in XMI documents
| XML namespaces in XMI documents [message #418032] |
Wed, 02 April 2008 20:45  |
Eclipse User |
|
|
|
Originally posted by: Robertson_Don.emc.com
Firstly, my apologies for posting to eclipse.modeling as well. I only just
noticed this group.
I noticed that in generated XMI documents the root element is namespaced
with an explicit prefixed namespace declaration, but there is no default
namespace declaration and subordinate elements are not explicitly prefixed.
For example, "elements" below is not qualified (ecore and EMF from Ganymede
distribution) ...
<?xml version="1.0" encoding="UTF-8"?>
<rdb:Schema xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:rdb="http://www.eclipse.org/qvt/1.0.0/Operational/examples/rdb">
<elements xsi:type="rdb:Table"/>
</rdb:Schema>
My understanding of XML is that the subordinate elements are not within a
namespace - containment only offers visibility to in-scope namespace
declarations, not implicit namespace assignment (except to an in-scope
default namespace).
Is this the intended behavior? If so, it complicates the use of XMI
documents in an XML repository (eg. with XQuery). And I can't see a point to
it.
Hopefully I am just plain wrong. If not, I know I can control serialization,
but as a default behavior this means the whole organization will have to do
so if we are to have EMF-generated documents co-resident in a repository.
Any comments?
|
|
|
| Re: XML namespaces in XMI documents [message #418033 is a reply to message #418032] |
Wed, 02 April 2008 21:12  |
 Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
Don,
Comments below.
Robertson, Don wrote:
> Firstly, my apologies for posting to eclipse.modeling as well. I only just
> noticed this group.
>
I'll let it go this time! :-P
> I noticed that in generated XMI documents the root element is namespaced
> with an explicit prefixed namespace declaration, but there is no default
> namespace declaration and subordinate elements are not explicitly prefixed.
>
That's the XMI way...
> For example, "elements" below is not qualified (ecore and EMF from Ganymede
> distribution) ...
>
> <?xml version="1.0" encoding="UTF-8"?>
> <rdb:Schema xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:rdb="http://www.eclipse.org/qvt/1.0.0/Operational/examples/rdb">
> <elements xsi:type="rdb:Table"/>
> </rdb:Schema>
>
> My understanding of XML is that the subordinate elements are not within a
> namespace - containment only offers visibility to in-scope namespace
> declarations, not implicit namespace assignment (except to an in-scope
> default namespace).
>
For sure that's true. For an XML element to have a namespace, it must
be qualified with prefix or an xmlns="..." declaration must be in scope.
> Is this the intended behavior? If so, it complicates the use of XMI
> documents in an XML repository (eg. with XQuery). And I can't see a point to
> it.
>
It is the intended behavior. Features of classes are serialized as if
they are local element or attribute declarations in a complex type,
which by default are not qualified
(attribute/elementFormDefault="qualified" or form="qualified" on the
attribute/element would be necessary).
> Hopefully I am just plain wrong.
Well, it is the proper XMI default serialization. I'm not sure why
unqualified attributes are okay but unqualified elements concern you.
It's kind of the equivalent issue...
> If not, I know I can control serialization,
> but as a default behavior this means the whole organization will have to do
> so if we are to have EMF-generated documents co-resident in a repository.
>
You can use extended meta data annotations to force them to be
serialized in a qualified form, but I don't think you should need to do
that. I don't think you'll find many XMI serializations which take that
approach...
> Any comments?
>
Hopefully you've had enough of my comments. :-P
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: XML namespaces in XMI documents [message #418034 is a reply to message #418033] |
Wed, 02 April 2008 22:02 |
| Eclipse User |
|
|
|
Originally posted by: Robertson_Don.emc.com
Thanks for your response Ed.
The standard serialization works fine for "XML as documents", which is
exactly how we are using them now with EMF (successfully - thanks). My
problem arises when I want to aggregate these and potentially other XML data
sets (over which I have no control) into a common repository and reason
about them. Now the unqualified names become quite a nuisance because our
Xqueries cannot use qualified references and have to filter out potential
name collisions very deliberately.
I think I will have to consider an alternate serialization. Of course, the
serialization will have to work both for EMF consumption and for Xquery
consumption. I have to say though, that it doesn't seem like an uncommon use
case for EMF-generated XML to be consolidated in an XML repository for
non-EMF consumption.
I appreciate your explanation.
Don
On 4/2/08 2:12 PM, in article ft0ssh$f45$1@build.eclipse.org, "Ed Merks"
<merks@ca.ibm.com> wrote:
> Don,
>
> Comments below.
>
> Robertson, Don wrote:
>> Firstly, my apologies for posting to eclipse.modeling as well. I only just
>> noticed this group.
>>
>
> I'll let it go this time! :-P
>> I noticed that in generated XMI documents the root element is namespaced
>> with an explicit prefixed namespace declaration, but there is no default
>> namespace declaration and subordinate elements are not explicitly prefixed.
>>
> That's the XMI way...
>> For example, "elements" below is not qualified (ecore and EMF from Ganymede
>> distribution) ...
>>
>> <?xml version="1.0" encoding="UTF-8"?>
>> <rdb:Schema xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI"
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>> xmlns:rdb="http://www.eclipse.org/qvt/1.0.0/Operational/examples/rdb">
>> <elements xsi:type="rdb:Table"/>
>> </rdb:Schema>
>>
>> My understanding of XML is that the subordinate elements are not within a
>> namespace - containment only offers visibility to in-scope namespace
>> declarations, not implicit namespace assignment (except to an in-scope
>> default namespace).
>>
> For sure that's true. For an XML element to have a namespace, it must
> be qualified with prefix or an xmlns="..." declaration must be in scope.
>> Is this the intended behavior? If so, it complicates the use of XMI
>> documents in an XML repository (eg. with XQuery). And I can't see a point to
>> it.
>>
> It is the intended behavior. Features of classes are serialized as if
> they are local element or attribute declarations in a complex type,
> which by default are not qualified
> (attribute/elementFormDefault="qualified" or form="qualified" on the
> attribute/element would be necessary).
>> Hopefully I am just plain wrong.
> Well, it is the proper XMI default serialization. I'm not sure why
> unqualified attributes are okay but unqualified elements concern you.
> It's kind of the equivalent issue...
>>>They do concern me :-)
>> If not, I know I can control serialization,
>> but as a default behavior this means the whole organization will have to do
>> so if we are to have EMF-generated documents co-resident in a repository.
>>
> You can use extended meta data annotations to force them to be
> serialized in a qualified form, but I don't think you should need to do
> that. I don't think you'll find many XMI serializations which take that
> approach...
>> Any comments?
>>
> Hopefully you've had enough of my comments. :-P
|
|
|
| Re: XML namespaces in XMI documents [message #418035 is a reply to message #418034] |
Wed, 02 April 2008 22:37 |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------020901080909030908090103
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Don,
Certainly my XQuery knowledge is thin at best but if there is no support
for proper schema-aware processing, i.e., processing which would make it
easy to find all instances of a given type, regardless of the fact that
there might be 1000 different elements (local or global) using that
type, then XQuery is pretty much useless. I kind of doubt XQuery is
useless, which makes me think that XQuery would be more than capable to
dealing with qualified and unqualified local element declarations in a
manner that makes the distinction between the two an irrelevant
syntactic detail. So I don't imagine this can be a big problem for a
fully functional XQuery processor...
In any case, it's pretty easy, though tedious, to produce a
serialization where all local element declarations are qualified.
Annotations on the Ecore model and options in the resource factory are
all that are needed.
Robertson, Don wrote:
> Thanks for your response Ed.
>
> The standard serialization works fine for "XML as documents", which is
> exactly how we are using them now with EMF (successfully - thanks). My
> problem arises when I want to aggregate these and potentially other XML data
> sets (over which I have no control) into a common repository and reason
> about them. Now the unqualified names become quite a nuisance because our
> Xqueries cannot use qualified references and have to filter out potential
> name collisions very deliberately.
>
> I think I will have to consider an alternate serialization. Of course, the
> serialization will have to work both for EMF consumption and for Xquery
> consumption. I have to say though, that it doesn't seem like an uncommon use
> case for EMF-generated XML to be consolidated in an XML repository for
> non-EMF consumption.
>
> I appreciate your explanation.
>
> Don
>
>
> On 4/2/08 2:12 PM, in article ft0ssh$f45$1@build.eclipse.org, "Ed Merks"
> <merks@ca.ibm.com> wrote:
>
>
>> Don,
>>
>> Comments below.
>>
>> Robertson, Don wrote:
>>
>>> Firstly, my apologies for posting to eclipse.modeling as well. I only just
>>> noticed this group.
>>>
>>>
>> I'll let it go this time! :-P
>>
>>> I noticed that in generated XMI documents the root element is namespaced
>>> with an explicit prefixed namespace declaration, but there is no default
>>> namespace declaration and subordinate elements are not explicitly prefixed.
>>>
>>>
>> That's the XMI way...
>>
>>> For example, "elements" below is not qualified (ecore and EMF from Ganymede
>>> distribution) ...
>>>
>>> <?xml version="1.0" encoding="UTF-8"?>
>>> <rdb:Schema xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI"
>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>>> xmlns:rdb="http://www.eclipse.org/qvt/1.0.0/Operational/examples/rdb">
>>> <elements xsi:type="rdb:Table"/>
>>> </rdb:Schema>
>>>
>>> My understanding of XML is that the subordinate elements are not within a
>>> namespace - containment only offers visibility to in-scope namespace
>>> declarations, not implicit namespace assignment (except to an in-scope
>>> default namespace).
>>>
>>>
>> For sure that's true. For an XML element to have a namespace, it must
>> be qualified with prefix or an xmlns="..." declaration must be in scope.
>>
>>> Is this the intended behavior? If so, it complicates the use of XMI
>>> documents in an XML repository (eg. with XQuery). And I can't see a point to
>>> it.
>>>
>>>
>> It is the intended behavior. Features of classes are serialized as if
>> they are local element or attribute declarations in a complex type,
>> which by default are not qualified
>> (attribute/elementFormDefault="qualified" or form="qualified" on the
>> attribute/element would be necessary).
>>
>>> Hopefully I am just plain wrong.
>>>
>> Well, it is the proper XMI default serialization. I'm not sure why
>> unqualified attributes are okay but unqualified elements concern you.
>> It's kind of the equivalent issue...
>>
>
>
>>>> They do concern me :-)
>>>>
>
>
>>> If not, I know I can control serialization,
>>> but as a default behavior this means the whole organization will have to do
>>> so if we are to have EMF-generated documents co-resident in a repository.
>>>
>>>
>> You can use extended meta data annotations to force them to be
>> serialized in a qualified form, but I don't think you should need to do
>> that. I don't think you'll find many XMI serializations which take that
>> approach...
>>
>>> Any comments?
>>>
>>>
>> Hopefully you've had enough of my comments. :-P
>>
>
>
--------------020901080909030908090103
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Don,<br>
<br>
Certainly my XQuery knowledge is thin at best but if there is no
support for proper schema-aware processing, i.e., processing which
would make it easy to find all instances of a given type, regardless of
the fact that there might be 1000 different elements (local or global)
using that type, then XQuery is pretty much useless. I kind of doubt
XQuery is useless, which makes me think that XQuery would be more than
capable to dealing with qualified and unqualified local element
declarations in a manner that makes the distinction between the two an
irrelevant syntactic detail. So I don't imagine this can be a big
problem for a fully functional XQuery processor...<br>
<br>
In any case, it's pretty easy, though tedious, to produce a
serialization where all local element declarations are qualified.
Annotations on the Ecore model and options in the resource factory are
all that are needed. <br>
<br>
<br>
Robertson, Don wrote:
<blockquote cite="mid:C419508B.2F4E%25Robertson_Don@emc.com" type="cite">
<pre wrap="">Thanks for your response Ed.
The standard serialization works fine for "XML as documents", which is
exactly how we are using them now with EMF (successfully - thanks). My
problem arises when I want to aggregate these and potentially other XML data
sets (over which I have no control) into a common repository and reason
about them. Now the unqualified names become quite a nuisance because our
Xqueries cannot use qualified references and have to filter out potential
name collisions very deliberately.
I think I will have to consider an alternate serialization. Of course, the
serialization will have to work both for EMF consumption and for Xquery
consumption. I have to say though, that it doesn't seem like an uncommon use
case for EMF-generated XML to be consolidated in an XML repository for
non-EMF consumption.
I appreciate your explanation.
Don
On 4/2/08 2:12 PM, in article <a class="moz-txt-link-abbreviated" href="mailto:ft0ssh$f45$1@build.eclipse.org">ft0ssh$f45$1@build.eclipse.org</a>, "Ed Merks"
<a class="moz-txt-link-rfc2396E" href="mailto:merks@ca.ibm.com"><merks@ca.ibm.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Don,
Comments below.
Robertson, Don wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Firstly, my apologies for posting to eclipse.modeling as well. I only just
noticed this group.
</pre>
</blockquote>
<pre wrap="">I'll let it go this time! :-P
</pre>
<blockquote type="cite">
<pre wrap="">I noticed that in generated XMI documents the root element is namespaced
with an explicit prefixed namespace declaration, but there is no default
namespace declaration and subordinate elements are not explicitly prefixed.
</pre>
</blockquote>
<pre wrap="">That's the XMI way...
</pre>
<blockquote type="cite">
<pre wrap="">For example, "elements" below is not qualified (ecore and EMF from Ganymede
distribution) ...
<?xml version="1.0" encoding="UTF-8"?>
<rdb:Schema xmi:version="2.0" xmlns:xmi=<a class="moz-txt-link-rfc2396E" href="http://www.omg.org/XMI">"http://www.omg.org/XMI"</a>
xmlns:xsi=<a class="moz-txt-link-rfc2396E" href="http://www.w3.org/2001/XMLSchema-instance">"http://www.w3.org/2001/XMLSchema-instance"</a>
xmlns:rdb=<a class="moz-txt-link-rfc2396E" href="http://www.eclipse.org/qvt/1.0.0/Operational/examples/rdb">"http://www.eclipse.org/qvt/1.0.0/Operational/examples/rdb"</a>>
<elements xsi:type="rdb:Table"/>
</rdb:Schema>
My understanding of XML is that the subordinate elements are not within a
namespace - containment only offers visibility to in-scope namespace
declarations, not implicit namespace assignment (except to an in-scope
default namespace).
</pre>
</blockquote>
<pre wrap="">For sure that's true. For an XML element to have a namespace, it must
be qualified with prefix or an xmlns="..." declaration must be in scope.
</pre>
<blockquote type="cite">
<pre wrap="">Is this the intended behavior? If so, it complicates the use of XMI
documents in an XML repository (eg. with XQuery). And I can't see a point to
it.
</pre>
</blockquote>
<pre wrap="">It is the intended behavior. Features of classes are serialized as if
they are local element or attribute declarations in a complex type,
which by default are not qualified
(attribute/elementFormDefault="qualified" or form="qualified" on the
attribute/element would be necessary).
</pre>
<blockquote type="cite">
<pre wrap="">Hopefully I am just plain wrong.
</pre>
</blockquote>
<pre wrap="">Well, it is the proper XMI default serialization. I'm not sure why
unqualified attributes are okay but unqualified elements concern you.
It's kind of the equivalent issue...
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">They do concern me :-)
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap=""><!---->
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">If not, I know I can control serialization,
but as a default behavior this means the whole organization will have to do
so if we are to have EMF-generated documents co-resident in a repository.
</pre>
</blockquote>
<pre wrap="">You can use extended meta data annotations to force them to be
serialized in a qualified form, but I don't think you should need to do
that. I don't think you'll find many XMI serializations which take that
approach...
</pre>
<blockquote type="cite">
<pre wrap="">Any comments?
</pre>
</blockquote>
<pre wrap="">Hopefully you've had enough of my comments. :-P
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
<br>
</body>
</html>
--------------020901080909030908090103--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Fri Apr 19 22:57:13 GMT 2024
Powered by FUDForum. Page generated in 0.03265 seconds |
] 
Search
Help
Register
Login
Home
