RE: Topic 1: Terminolgy alignment

[Matthew MacKenzie <matt@xmlglobal.com>]

Farukh, Group:

I have a couple of comments, made inline ...

-----Original Message-----
From: Farrukh Najmi - JavaSoft East [mailto:Farrukh.Najmi@East.Sun.COM]
Sent: Wednesday, September 20, 2000 10:19 PM
To: ebxml repository
Subject: Topic 1: Terminolgy alignment

<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>


<FN>
ExternalData Vs. RelatedData
------------------------------------
> 9) With the above clarifications, I'm OK with the content of Section
2.3.2,
> although I'd prefer a term for these objects as something other than
> "External Object".  How about "Related Data".  Note that there's no
> requirement that these things even have a persistent object identifier,
> just a Name and a URL is sufficient.

The concept is exactly that of OASIS RelatedData. I thought it was a good
idea, and I borrowed. It is a named hyperlink with none of the
overhead of the managed object.

It was a good idea but I felt it needed improvement. My problem with
RelatedData was that it was ambiguous. The key concept is that the
object is external and that it's life cycle is not managed by RS. Related is
not the key concept because two objects that are associated could
be considered as related. A TPA that use a Process could be considered
Related to the innocent bystander. External was my first stab. I am
open to other suggestions. However, Related is ambiguous and ambiguity is
something I would like us to avoid.

The 'Data' part did not feel right because I felt that everything in the
model is an Object (more on this in topic 2 tommorow). Having a
common base class for everything in the model has been a very valuable thing
in SmallTalk and Java compared to C++. It gives you a place
to put functionality that you want available consistently in the entire
model.

Some alternatives that I had thought of were UnmanagedObject, HyperLink,
LinkedObject. In retrospect I think I actually prefer
LinkedObject more than ExternalObject. Team share your thoughts.
</FN>

<MM>

How about:

<Object>
	...
	<RelatedData type="object"
personality="UnmanagedObject"><![CDATA[com.foo.bar.Obj]]></RelatedData>
</Object>

??
</MM>

<FN>
However, he has also made quite comments in this terminology topics which I
frankly feel where overly prescriptive. I was thinking that the
OASIS team would be very supportive of v0.1 because of the obvious salute to
the quality of their work in the number of concepts,
terminologies and ideas borrowed. I was actually quite surprised by the
level of prescriptivity and expectation of conformance to the level of
'd' Vs. 'D'.
</FN>

<MM>
'd' Vs. 'D' is a distinction you actually make (camel case ...).  Why can
others not suggest their
coding style, this is a democratic process, correct?
</MM>

I would like to note that you guys seem to be working really hard on this
stuff, and it will be all
worthwhile if all of your thought processes can be merged into a final
document!

I think a priority would be to have a formal nitpick process, so if someone
doesn't like an element or the data model it is representing, this distaste
can be described tersely, and quickly voted upon for technical merit.  Save
the long discussion for more fundamental problems.  Some of us are purely
concerned with processing eficiency, and we can help if such a process is
implemented.

my 0.02 CAD (~0.0149 USD)

Cheers,

--
Matthew MacKenzie
VP Research & Development
XML Global