One further thought - currently the Adobe registry
has a classification structure
and ability to navigate up and down that - and when
you add content you
have to pick a classification node to assign to
it. You must also create that
classification structure, you just cannot build it
arbitarily on the fly - (that was
the snag with user defined URLs).
This is exactly analogous to folders - therefore -
it would be good to harmonize
these two structures and mechanisms into
one....
DW.
----- Original Message -----
Sent: Friday, May 14, 2004 11:41 AM
Subject: Re: [regrep] Folder proposal
overview
We (Adobe Engineering) like the Folder concept. It addresses
problems that we have encountered.
Good work,
Farrukh.
-Matt
On May 14, 2004, at 12:27 PM, Carl Mattocks
wrote:
+1 on leveraging XACML and minimal change to
spec
<quote who="Farrukh Najmi">
<from meeting note 5/13/04> Folder idea (carry over
from F2F). Farrukh not present. Duane’s concern that it could violate
the MVC and bring registry into UI. </from meeting note
5/13/04>
I had explained this at the New Orleans f2f that
everything I propose is part of Information Model (the M in MVC). There
is no violation of MVC by introducing view into the specs.
We
are defining a registry and a repository. All repositories support
a notion of files and folders as part of their model to
facilitate structural organization of content (see nt:file and
nt:folder in JSR 170 for example). This has nothing to do with views
(how the structure is displayed).
No let us go back to the
motivation of why I am proposing this enhancement in historical
retrospective perspective...
In version 2.5 we added an HTTP
interface that allowed all RegistryObjects and RepositoryItems to be
accessible via a URL based upon its id. The problem was that the URL
was meaningless to the submitter (kind of like a KAVI URL).
So
next we introduced post 2.5 and approved the "User defined
URL" feature. This feature augmented the HTTP interface by allowing
a submitter to optionally provide one or more user defined URLs that
were meaningful to the user. This was a major
improvement.
However we still have an issue that user-defined URLs
have no access control. Anyone can assign any (potentially misleading)
URL to objects they own. For example lets us say Duane is using the
following URLs prefix for all hist
objects:
..../userData/duane/....
Now along comes Farrukh
and submits some false information allegedly pertaining to Duane under
the
URL:
..../userData/duane/companyInfo/aboutDuanesCompany.html
There
is absolutely nothing that Duane can do since I published that URL on
*MY* object. But the damage is done to Duane's stellar
reputation.
The File/Folder metaphor proposal augments the
user-defined URLto allow Duane to protect his stellar
reputation. The Registry has a userData folder as root of all userData.
The folders access control allows anyone to create files and folders in
it. Duane creates a folder named "duane" under it and sets its access
control to only allow Duane and possible his dear wife and some choice
friends to create files and folders under it. I simply will not be able
to write my slanderous files under Duane's folder. Dang! ;-)
How
would this work? Quite simple really. We use some of our existing "few
good primitives" and put them to work for this use case as
follows...
To create a Folder one creates a
RegistryPackage.
To assign access control to a folder access
control one uses "reference access control" using XACML ACP that we
already support. See a couple of examples attached. The examples have
comments explaining things.
To create a file within a folder one
simply creates a RegistryObject (which could be a RegistryPackage /
folder) and adds it as a member of the RegistryPackage for the folder.
The file can have its own ACP. This is just like Unix file system
permissions which is a tried and trusted model. BTW Unix filesystem is
not violating MVC - is it?
Finally, note that we do not have to
introduce any new "Folder" or "File" type in RIM. In fact we do not
have to change RIM at all!
In summary, with little effort we
provide a valuable enhancement to our repository feature.
Does
this explaination address some of the concerns and clear
some misunderstandings?
PS: My apologies for missing yesterday's
meeting. My best friend's epic 2 month long wedding party had another
significant event.
-- Regards, Farrukh
To unsubscribe
from this mailing list (and be removed from the roster of the OASIS
TC), go
to http://www.oasis-open.org/apps/org/workgroup/regrep/members/leave_workgroup.php.
--
Carl Mattocks
co-Chair OASIS (ISO/TS 15000) ebXMLRegistry
Semantic Content SC co-Chair OASIS Business Centric Methodology TC CEO
CHECKMi v/f (usa) 908 322 8715 www.CHECKMi.com Semantically Smart
Compendiums (AOL) IM CarlCHECKMi
To unsubscribe from this mailing
list (and be removed from the roster of the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/regrep/members/leave_workgroup.php.
___________________________/bigger>/color> Matthew
MacKenzie /bigger>Senior
Architect IDBU Server Solutions Adobe Systems Canada
Inc. http://www.adobe.com/products/server/ mattm@adobe.com +1 (506)
871.5409/smaller>/color>
|