Home » Archived » XML Schema Definition (XSD) » Changing an element from type= to ref=
| Changing an element from type= to ref= [message #57873] |
Fri, 18 February 2005 19:49  |
 Johnathan Nightingale
Messages: 2
Registered: July 2009 |
Junior Member |
|
|
Hi folks,
Sorry if this is a FAQ, but my newsgroup search didn't turn up much.
Basically the situation I have is that my XSD model is loaded on a file
with a perfectly normal complexType containing several elements in a
sequence. Some of the elements use type="..." specifiers, and some are
element refs.
While interacting with our editor, our user will at various times want to
change the type on these elements, and may choose a complexType or an
element, so we need to support all four possibilities:
1) used to use type="..." now uses ref=".."
2) ref -> type
3) ref -> ref
4) type -> type
Cases 3 and 4 work fine, but cases 1 and 2 we're hitting problems. We had
assumed that, for instance for case #2, we could do something like:
element.setTypeDefinition(newType);
element.setName(newName);
and then we realised that we should probably make it:
element.setResolvedElementDeclaration(element);
element.setTypeDefinition(newType);
element.setName(newName);
just to be sure. But when this serializes, we end up with an element that
contains a name, type AND ref attributes, which is obviously bad XSD. A
similar problem strikes when we try to go the other way - nulling name and
typeDefinition, and setting the resolved element.
Is there something obvious we're missing here? We don't want to get to
the point where we first have to create a new element, remove the old one
from its particle, insert the new one, and then copy over annotations,
etc. if there's a cleaner way to make it all magically work. :)
Thanks,
Johnathan
|
|
|
| Re: Changing an element from type= to ref= [message #57898 is a reply to message #57873] |
Fri, 18 February 2005 20:31  |
Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
This is a multi-part message in MIME format.
--------------060604060502080507020605
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Johnathan,
The 2) case isn't expected and isn't handled correctly so you should
open a bugzilla. You can access the DOM directly and remove the "ref"
attribute manually as a workaround, i.e,
element.getElement().removeAttribute("ref")
I think 1) case should work iff you null the type and name first and set
the reference after, but I haven't tried that.
Johnathan Nightingale wrote:
> Hi folks,
>
> Sorry if this is a FAQ, but my newsgroup search didn't turn up much.
> Basically the situation I have is that my XSD model is loaded on a
> file with a perfectly normal complexType containing several elements
> in a sequence. Some of the elements use type="..." specifiers, and
> some are element refs.
>
> While interacting with our editor, our user will at various times want
> to change the type on these elements, and may choose a complexType or
> an element, so we need to support all four possibilities:
>
> 1) used to use type="..." now uses ref=".."
> 2) ref -> type
> 3) ref -> ref
> 4) type -> type
>
> Cases 3 and 4 work fine, but cases 1 and 2 we're hitting problems. We
> had assumed that, for instance for case #2, we could do something like:
>
> element.setTypeDefinition(newType);
> element.setName(newName);
>
> and then we realised that we should probably make it:
>
> element.setResolvedElementDeclaration(element);
> element.setTypeDefinition(newType);
> element.setName(newName);
>
> just to be sure. But when this serializes, we end up with an element
> that contains a name, type AND ref attributes, which is obviously bad
> XSD. A similar problem strikes when we try to go the other way -
> nulling name and typeDefinition, and setting the resolved element.
>
> Is there something obvious we're missing here? We don't want to get
> to the point where we first have to create a new element, remove the
> old one from its particle, insert the new one, and then copy over
> annotations, etc. if there's a cleaner way to make it all magically
> work. :)
>
> Thanks,
>
> Johnathan
>
>
--------------060604060502080507020605
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">
</head>
<body bgcolor="#ffffff" text="#000000">
Johnathan,<br>
<br>
The 2) case isn't expected and isn't handled correctly so you should
open a bugzilla.
|
|
|
| Re: Changing an element from type= to ref= [message #594106 is a reply to message #57873] |
Fri, 18 February 2005 20:31 |
Ed Merks
Messages: 33139
Registered: July 2009 |
Senior Member |
|
|
This is a multi-part message in MIME format.
--------------060604060502080507020605
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Johnathan,
The 2) case isn't expected and isn't handled correctly so you should
open a bugzilla. You can access the DOM directly and remove the "ref"
attribute manually as a workaround, i.e,
element.getElement().removeAttribute("ref")
I think 1) case should work iff you null the type and name first and set
the reference after, but I haven't tried that.
Johnathan Nightingale wrote:
> Hi folks,
>
> Sorry if this is a FAQ, but my newsgroup search didn't turn up much.
> Basically the situation I have is that my XSD model is loaded on a
> file with a perfectly normal complexType containing several elements
> in a sequence. Some of the elements use type="..." specifiers, and
> some are element refs.
>
> While interacting with our editor, our user will at various times want
> to change the type on these elements, and may choose a complexType or
> an element, so we need to support all four possibilities:
>
> 1) used to use type="..." now uses ref=".."
> 2) ref -> type
> 3) ref -> ref
> 4) type -> type
>
> Cases 3 and 4 work fine, but cases 1 and 2 we're hitting problems. We
> had assumed that, for instance for case #2, we could do something like:
>
> element.setTypeDefinition(newType);
> element.setName(newName);
>
> and then we realised that we should probably make it:
>
> element.setResolvedElementDeclaration(element);
> element.setTypeDefinition(newType);
> element.setName(newName);
>
> just to be sure. But when this serializes, we end up with an element
> that contains a name, type AND ref attributes, which is obviously bad
> XSD. A similar problem strikes when we try to go the other way -
> nulling name and typeDefinition, and setting the resolved element.
>
> Is there something obvious we're missing here? We don't want to get
> to the point where we first have to create a new element, remove the
> old one from its particle, insert the new one, and then copy over
> annotations, etc. if there's a cleaner way to make it all magically
> work. :)
>
> Thanks,
>
> Johnathan
>
>
--------------060604060502080507020605
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">
</head>
<body bgcolor="#ffffff" text="#000000">
Johnathan,<br>
<br>
The 2) case isn't expected and isn't handled correctly so you should
open a bugzilla.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Sat Apr 20 15:21:57 GMT 2024
Powered by FUDForum. Page generated in 0.03342 seconds |
] 
Search
Help
Register
Login
Home
