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

[Matthew MacKenzie <matt@xmlglobal.com>]

Farrukh,

I aggree with your statements below, except I think that the section you
have outlined
on "Object Versioning" should be extended to "Object Attribute
Representation", because having
consistency in this area will make ebXML application design & implementation
much more clear.  If
the XML Object representation is consistent and well thought out, the tasks
of (un)serialization become
easier, in that software can be re-used across the whole gamut of ebXML
objects.

For instance, if I was transporting an ebXML registry object with SOAP,
using the Apache/IBM SOAP
kit, when my SOAP app was deployed I would have to specify serialization
classes for the ebXML payload.  If
the ebXML representation was consistent, the same serialization class(es)
could be used for a wide variety of
ebXML messages.

Cheers, Matthew MacKenzie

-----Original Message-----
From: Farrukh Najmi [mailto:Farrukh.Najmi@east.sun.com]
Sent: Thursday, September 21, 2000 7:59 AM
To: Matthew MacKenzie
Cc: Farrukh.Najmi@east.sun.com; ebxml repository; Stojanovic, Nikola
Subject: Topic 0: Proposed global issues for ebXML TA's consideration


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