Topic 0: Proposed global issues for ebXML TA's consideration

[Farrukh Najmi <Farrukh.Najmi@east.sun.com>]

I started this new thread based on some conversations from the terminology
thread because it is important across groups and should be considered as having
global implications for ebXML. Sorry for the subject change. I hope you agree
that it is appropriate to separate these as global issues.

These issues are being debated redundantly in the context of different WGs when
they really should be addressed by a more global group like TA or Coord.


Naming Conventions
------------------------
We should have a consistent ebXML approach to naming classes, attributes and
methods. I have proposed camel case convention (upper for classes, lower for
attributes and methods).

Object Identification
------------------------
We should have a consistent ebXML approach to identifying object identification
in ebXML. GUID (globally unique id) is something I have heard from TA
discussions and I support it.

Object Versioning
---------------------
We should have a consistent ebXML approach to object versioning. Should version
be a separate class with attributes? Should it be two attributes of the class
whose instance is being versioned? I support the latter.

Can the team think of other such global issues where we need to save our
energies and let TA drive them instead?

Matthew MacKenzie wrote:

> Farukh, Group:

FYI, the correct spelling is Farrukh
<snip>

>
>
>
>
> <F.N>
>
> >   majorVersion  -->  partially to Version
> >   minorVersion  -->  partially to Version
>
> This is not a naming issue but a modeling one but.... I chose to not have a
> separate Version object in the model which encapsulated the two
> objects because it seemed to be unnecessary overhead. That would have led to
> a reference from a ManagedObject to a Version object. In a
> relational DB implementation it would be an extra join for no good reason
> that I could think of. So unless we identify a good reason I vote we
> opt for simplicity (fewer classes in model, fewer joins, less comlicated
> queries in implementations). Team share thoughts.
> </F.N>
> <MM>
>
> I don't think that element level decisions should be made with an eye toward
> building RDBMS structures, such decisions ,
> if made, favor traditional/relational models where joins and complicated SQL
> are common.  Tomorrows query models
> will be XML oriented, at least in this scope, so I suggest either leaving
> majorVersion and minorVersion, OR,
> using just Version with a type atribute, e.g.
>
> <element Version="1.22.1" VersionType="major"/> <--icky, but is supportive
> of DOM-type queries or accumulative SAX-type
>                                                    analysis.
>
> <Version type="major">1.22.1</Version> <--functional, appeals to my common
> sense.
>
> </MM>
>
> <FN>
> > registryStatus  -->  RegStatus
>
> I have already made the point on obviousnes. Is RegStatus registry status or
> registration status? Whichever it is, why dont we spell it out?
> What do we save by abbreviating? 4 bytes in a repository that is likely to
> hold terabytes? FWIW, I originaly called it just plain status. I
> borrowed what made sense from OASIS that it is better to say it is a
> registryStatus so we should use the better name from OASIS, only get
> rid of the abbreviation. This is a good example of borrowing a good thing
> but improving upon it if needed.
> </FN>
>
> <MM>
>
> Another possible model to explore is (IMHO) proper use of attributes.
> Imagine the repository
> as an object, and Registry and Registration as sub objects, quite possibly
> very far away package/namespace wise.
> What makes more sense:
>
> Object.registryStatus()
> registry.status()
>
> My pick is the latter, so why not extrapolate that to elements,
>
> <Registration status="10200"/>
>
> ??
>
> In my opinion, the status of something doesn't deserve to be a noun, leave
> it as an adjective.
>
> </MM>
>
>
>
> --
> Matthew MacKenzie
> VP Research & Development
> XML Global

--
Regards,
Farrukh

begin:vcard 
n:Najmi;Farrukh 
tel;fax:781-442-1610
tel;work:781-442-0703
x-mozilla-html:TRUE
url:www.sun.com
org:Sun Microsystems;Java Software
adr:;;1 Network Drive, MS BUR02-302;Burlington;MA;01803-0902;USA
version:2.1
email;internet:najmi@east.sun.com
fn:Farrukh S. Najmi
end:vcard