OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

regrep message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [regrep] Folder proposal overview


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
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 -----
From: Matthew MacKenzie
To: regrep@lists.oasis-open.org
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.


___________________________
Matthew MacKenzie
Senior Architect
IDBU Server Solutions
Adobe Systems Canada Inc.
http://www.adobe.com/products/server/
mattm@adobe.com
+1 (506) 871.5409

___________________________
Matthew MacKenzie
Senior Architect
IDBU Server Solutions
Adobe Systems Canada Inc.
http://www.adobe.com/products/server/
mattm@adobe.com
+1 (506) 871.5409


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]