Re: Brainstorm not to expose INTERNAL Properties

[Fuhwei Lwo <fu...@bricemedia.com>]

Option 1 would only work if SDO implementation never needs to expose  any internal EMF properties. I am not sure whether there is a  possibility that we need to map the internal EMF properties to  something so the SDO users can control some EMF like behavior.
  
  What kind of internal EMF properties are we talking about here?  Can you share them?  Thanks.
  
  Best regards,
  
  Fuhwei Lwo

Yang ZHONG <le...@gmail.com> wrote:  Current SDO impl bases on EMF, EMF may produce INTERNAL Properties besides
user designation.
It may be nice for SDO not to expose the INTERNAL Properties.

Here lists some thoughts JUST as a START, it's much more important if YOU
brainstorm please.
Frank has provided options such as
1. SDOXSDEcoreBuilder builds user Properties at the beginning of
getEStructuralFeatures() List and INTERNAL properties at the end of
getEStructuralFeatures().
    SDO can simply hide high-index INTERNAL Properties without too much
performance sacrifice.
2. SDO maintains a seperated List from getEStructuralFeatures()

I agree with either of the two options and feel like it may be another
option to extend getEAllStructuralFeatures() to change the property List in
effect.

Really hope to see your comment on any of the options even more options from
you.

No matter what option, an interesting thing to consider is the order of
INTERNAL Properties from SUPER typeS and user Properties from subtype.
Really hope to see good solution to that concern so that List decoration
(index translation) can be evitable.

Thanks in advance.

-- 

Yang ZHONG

Re: Brainstorm not to expose INTERNAL Properties

[Jeremy Boynes <jb...@apache.org>]

On 7/2/06, Yang ZHONG <le...@gmail.com> wrote:
> EMF may not necessarily be *the* implementation of SDO, and SDO
> implementations may not necessarily *all* use EMF.

+1

> As a SDO user, you may
> not necessarily want to "control some EMF like behavior". I think for
> whatever internal EMF Properties SDO stops exposing, equivalent API will be
> provided within helpers such as XMLHelper, XSDHelper (and SDOUtil).
>

I agree to the extent that such behaviour makes sense in the context
of SDO. We should not add things into the API to support users who
really just want EMF - they should just use EMF.

--
Jeremy

---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: Brainstorm not to expose INTERNAL Properties

[Yang ZHONG <le...@gmail.com>]

EMF may not necessarily be *the* implementation of SDO, and SDO
implementations may not necessarily *all* use EMF. As a SDO user, you may
not necessarily want to "control some EMF like behavior". I think for
whatever internal EMF Properties SDO stops exposing, equivalent API will be
provided within helpers such as XMLHelper, XSDHelper (and SDOUtil).

Internal EMF Property candidates not to be exposed, *may* include "mixed",
"any", "substitutionGroup" and so on. This thread focus on *how* not to
expose internal Properties, as for *which*, there may be other thread(s)
even case by case.


On 7/1/06, Fuhwei Lwo <fu...@bricemedia.com> wrote:
>
> Option 1 would only work if SDO implementation never needs to expose  any
> internal EMF properties. I am not sure whether there is a  possibility that
> we need to map the internal EMF properties to  something so the SDO users
> can control some EMF like behavior.
>
> What kind of internal EMF properties are we talking about here?  Can you
> share them?  Thanks.
>
> Best regards,
>
> Fuhwei Lwo
>
> Yang ZHONG <le...@gmail.com> wrote:  Current SDO impl bases on
> EMF, EMF may produce INTERNAL Properties besides
> user designation.
> It may be nice for SDO not to expose the INTERNAL Properties.
>
> Here lists some thoughts JUST as a START, it's much more important if YOU
> brainstorm please.
> Frank has provided options such as
> 1. SDOXSDEcoreBuilder builds user Properties at the beginning of
> getEStructuralFeatures() List and INTERNAL properties at the end of
> getEStructuralFeatures().
>    SDO can simply hide high-index INTERNAL Properties without too much
> performance sacrifice.
> 2. SDO maintains a seperated List from getEStructuralFeatures()
>
> I agree with either of the two options and feel like it may be another
> option to extend getEAllStructuralFeatures() to change the property List
> in
> effect.
>
> Really hope to see your comment on any of the options even more options
> from
> you.
>
> No matter what option, an interesting thing to consider is the order of
> INTERNAL Properties from SUPER typeS and user Properties from subtype.
> Really hope to see good solution to that concern so that List decoration
> (index translation) can be evitable.
>
> Thanks in advance.
>
> --
>
> Yang ZHONG
>
>
>


-- 

Yang ZHONG