Matt,
You can never legislate against bad-practice.
All you can do is provide good
guidelines.
The notion of the WebDAV style approach is
appealing - allowing users to
manage their space thru that interface - but what
they are building shows
up on the Registry-side as a browse-and-drilldown
classification heirarchy
is very appealing. With the simple addition
of 'Public' and 'Private' access
models when you create a new folder - seems like
this would be very
doable. The Registry administrator would
still need to approve
stuff to make it visible via the
registry....
Thanks, DW
----- Original Message -----
Sent: Friday, May 14, 2004 2:29 PM
Subject: Re: [regrep] Folder proposal
overview
I am not sure I am happy with user specified URLs as they are
specified now, for the reason you state...sorta.
I would prefer to have
a WebDAV binding that exposes a folder view of the classification schemes.
User specified URLs would be created by making the desired classification
hierarchy. A registry operator could even designate a scheme for that purpose
if security is an issue.
The issue of "folders" has other
ramifications as well.
- Path hardening (encoding version information
into a path spec) - Relative paths. (less of an issue for registry per say,
but an issue for apps that use them as filesystems).
-Matt
On
May 14, 2004, at 2:55 PM, David RR Webber wrote:
One further thought -
currently the Adobe registry has a classification structure/smaller>/fontfamily> and
ability to navigate up and down that - and when you add content you/smaller>/fontfamily> have to
pick a classification node to assign to it. You must also create that/smaller>/fontfamily> classification
structure, you just cannot build it arbitarily on the fly - (that was/smaller>/fontfamily> the
snag with user defined URLs)./smaller>/fontfamily> This
is exactly analogous to folders - therefore - it would be good to harmonize/smaller>/fontfamily> these
two structures and mechanisms into
one..../smaller>/fontfamily> DW./smaller>/fontfamily> -----
Original Message -----/x-tad-bigger>/fontfamily> /x-tad-bigger>From:/x-tad-bigger>
/x-tad-bigger>Matthew
MacKenzie/x-tad-bigger>/color> /x-tad-bigger>/fontfamily> To:/x-tad-bigger>/fontfamily>
/x-tad-bigger>regrep@lists.oasis-open.org/x-tad-bigger>/color>
/x-tad-bigger>/fontfamily> Sent:/x-tad-bigger>/fontfamily>
Friday, May 14, 2004 11:41 AM/x-tad-bigger>/fontfamily> Subject:/x-tad-bigger>/fontfamily>
Re: [regrep] Folder proposal
overview/x-tad-bigger>/fontfamily>
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.
___________________________ Matthew
MacKenzie Senior Architect IDBU Server Solutions Adobe Systems
Canada
Inc. http://www.adobe.com/products/server/ mattm@adobe.com +1 (506)
871.5409
___________________________/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>
|