Re: Question about ACL's
Hi, I'd go with (2) which is the approach I took with SiXDML. I chose that for a number of reasons, a.) Faster ramp up time to learn APIs than learn how internals work. b.) Less dependance on internals of DB will mean that it less resistant to changes in the implementation since APIs typically stay consistent while internals do not in Open Source applications. c.) Easier to modify for both yourself and end users. d.) Users don't need a different build of Xindice to use your application and finally once the project proves useful the code can be moved into the DB internals for perf reasons if necessary. --- Bryan Field-Elliot [EMAIL PROTECTED] wrote: Hi, I'm working on a project which, roughly, must provide the following capabilities: 1) Users of the service can create their own private document collection. 2) Users can add/remove/update documents within their collection, at will. 3) Users can optionally open up their collection to others, using highly granular ACL's for read and write operations. (e.g. The public can read this document (or this class of document). Also, users A, B, and C can read or write this other document (or this other class of document)). We are investigating both XML:DB API, and Xindice, as a possible API foundation and/or actual back-end implementation to meet these requirements. Admittedly I am new to both of these projects. In browsing the available materials this afternoon, I found nothing in either XML:DB API or Xindice which knows about users, permissions, etc, except at the whole collection level (not granular enough for us). I am assuming then that this kind of functionality isn't available out of the box. My question for this group is, if I were to use XML:DB API (and probably Xindice), how roughly would I go about designing this enhancement? I can think of two approaches but I don't know enough to say which is the better approach: (1) We develop an XML:DB API shim layer - our own implementation of XML:DB API which is a filter for a real XML:DB API implementation (such as Xindice's), adding authorization checks to every API command (assuming some security context has already been established). This is similar to the approach that JDBC connection pools take - they implement the JDBC interface as a shallow pass-through to a real JDBC provider, adding pooling functionality in the process. (2) We do this at the application level - e.g. choose an implementation (such as Xindice) and dig in deep - modify the sources to add this kind of functionality. or, (3), I'm way off base here and am better off starting from scratch than trying to do this with XML:DB API/Xindice Opinions would be greatly appreciated, Thank you, Bryan = THINGS TO DO IF I BECOME AN EVIL OVERLORD #230 I will not procrastinate regarding any ritual granting immortality. __ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ -- Post a message: mailto:[EMAIL PROTECTED] Unsubscribe:mailto:[EMAIL PROTECTED] Contact administrator: mailto:[EMAIL PROTECTED] Read archived messages: http://archive.xmldb.org/ --
Re: Question about ACL's
Duh. I meant, go with (1) :) --- Bryan Field-Elliot [EMAIL PROTECTED] wrote: Good advice -- but when you said, I'd go with (2), did you actually mean, I'd go with (1)? Everything else you've said would indicate thus Bryan On Tue, 2002-04-16 at 17:21, Dare Obasanjo wrote: Hi, I'd go with (2) which is the approach I took with SiXDML. I chose that for a number of reasons, a.) Faster ramp up time to learn APIs than learn how internals work. b.) Less dependance on internals of DB will mean that it less resistant to changes in the implementation since APIs typically stay consistent while internals do not in Open Source applications. c.) Easier to modify for both yourself and end users. d.) Users don't need a different build of Xindice to use your application and finally once the project proves useful the code can be moved into the DB internals for perf reasons if necessary. --- Bryan Field-Elliot [EMAIL PROTECTED] wrote: Hi, I'm working on a project which, roughly, must provide the following capabilities: 1) Users of the service can create their own private document collection. 2) Users can add/remove/update documents within their collection, at will. 3) Users can optionally open up their collection to others, using highly granular ACL's for read and write operations. (e.g. The public can read this document (or this class of document). Also, users A, B, and C can read or write this other document (or this other class of document)). We are investigating both XML:DB API, and Xindice, as a possible API foundation and/or actual back-end implementation to meet these requirements. Admittedly I am new to both of these projects. In browsing the available materials this afternoon, I found nothing in either XML:DB API or Xindice which knows about users, permissions, etc, except at the whole collection level (not granular enough for us). I am assuming then that this kind of functionality isn't available out of the box. My question for this group is, if I were to use XML:DB API (and probably Xindice), how roughly would I go about designing this enhancement? I can think of two approaches but I don't know enough to say which is the better approach: (1) We develop an XML:DB API shim layer - our own implementation of XML:DB API which is a filter for a real XML:DB API implementation (such as Xindice's), adding authorization checks to every API command (assuming some security context has already been established). This is similar to the approach that JDBC connection pools take - they implement the JDBC interface as a shallow pass-through to a real JDBC provider, adding pooling functionality in the process. (2) We do this at the application level - e.g. choose an implementation (such as Xindice) and dig in deep - modify the sources to add this kind of functionality. or, (3), I'm way off base here and am better off starting from scratch than trying to do this with XML:DB API/Xindice Opinions would be greatly appreciated, Thank you, Bryan = THINGS TO DO IF I BECOME AN EVIL OVERLORD #230 I will not procrastinate regarding any ritual granting immortality. __ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ -- Post a message: mailto:[EMAIL PROTECTED] Unsubscribe: mailto:[EMAIL PROTECTED] Contact administrator: mailto:[EMAIL PROTECTED] Read archived messages: http://archive.xmldb.org/ -- = THINGS TO DO IF I BECOME AN EVIL OVERLORD #230 I will not procrastinate regarding any ritual granting immortality. __ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/ -- Post a message: mailto:[EMAIL PROTECTED] Unsubscribe:mailto:[EMAIL PROTECTED] Contact administrator: mailto:[EMAIL PROTECTED] Read archived messages: http://archive.xmldb.org/ --
Re: Remarks about XML:DB API
--- Tom Bradford [EMAIL PROTECTED] wrote: On Thursday, February 7, 2002, at 02:09 PM, Kimbro Staken wrote: The problem comes if there is no root collection. For instance I have an Oracle 9i impl where the collection hierarchy is flat. I had to synthesize a root collection in order to have a starting point to create collections. This isn't intuitive when the database doesn't support a hierarchy of collections. I actually agree with Dare on this, Services tied to collections is too limiting. We need a cleaner distinction of database level services. I don't think all services should be database level, but the concept needs to exist. My only argument is that Collection-level services are needed, and shouldn't be eliminated. I have no problem with adding Database level services. :) This can easily be supported by doing what I did with SiXDML. Just add getService(String, String) to the Database class. = LAWS OF COMPUTER PROGRAMMING, VIII Any non-trivial program contains at least one bug. http://www.25hoursaday.com Carnage4Life (slashdot/advogato/kuro5hin) __ Do You Yahoo!? Send FREE Valentine eCards with Yahoo! Greetings! http://greetings.yahoo.com -- Post a message: mailto:[EMAIL PROTECTED] Unsubscribe:mailto:[EMAIL PROTECTED] Contact administrator: mailto:[EMAIL PROTECTED] Read archived messages: http://archive.xmldb.org/ --
Re: Problems With Implementing XMLDB API
- Original Message - From: Jonathan Borden [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, January 12, 2002 8:11 PM Subject: Re: Problems With Implementing XMLDB API Exactly, the XQuery 1.0 and XPath 2.0 data models have merged. If XML:DB is really going to be the standard API for XML databases, we need to track this work. That said, what is important is what we can do with 'it' not whether 'it' is named 'Value' or 'Resource'. The current XML:DB API and Model is good. We can simply subclass the Resource class as has been intended from day 1. IMHO, this is *not* the right decision. A Resource is supposed to be a type the database knows how to store/manage. The results of an XPath query are a _superset_ of the types that an XML database should know how to store. Clinging onto XPath query results = = Resource is sentimentalism and does not make for a well designed API. It is a choice that will lead to many users of the API shooting themselves in the foot and lots of exceptions at runtime (the worst kind) as people realize that not all implementors of the Resource interface are actually resources. A better solution would be to design support for XQuery/XPath 2.0 types and make sure that the types that correspond to nodes/nodesets/complexTypes implement the XMLResource interface. -- THINGS TO DO IF I BECOME AN EVIL OVERLORD #59 I will never build a sentient computer smarter than I am. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- Post a message: mailto:[EMAIL PROTECTED] Unsubscribe:mailto:[EMAIL PROTECTED] Contact administrator: mailto:[EMAIL PROTECTED] Read archived messages: http://archive.xmldb.org/ --
Re: Problems With Implementing XMLDB API
Like saying goes about opinions,.everybody has one. I merely stated my opinion about the XML:DB API after the trying to implement Core Level 1 Conformance over eXcelon's DXE[0] . My last manager told me I was opinionated, over time you'll realize this too and not feel that I am trying to _dictate_ my will. Anyway I disagree that the return types from an XPath query should implement the Resource interface since it is a BIG assumption that the average NXD will know how to persist any return type from a query. APIs like XML:DB, JDBC, ODBC, etc are meant to be lowest common denominator, your suggestion is the duirect opposite of that and is instead a highest common denominator API (just like CORBA) and we know how those turn out. [0] I don't work for them I'm doing it for fun. -- THINGS TO DO IF I BECOME AN EVIL OVERLORD #59 I will never build a sentient computer smarter than I am. - Original Message - From: Jonathan Borden [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, January 12, 2002 8:33 PM Subject: Re: Problems With Implementing XMLDB API Dare Obasanjo wrote: - Original Message - From: Jonathan Borden [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, January 11, 2002 3:05 PM Subject: Re: Problems With Implementing XMLDB API Err, so addResource on a BinaryResource is OK _from an interface point of view_ when addResource on an integer doesn't make sense? Do you really mean this? Considering that a number of native XML databases store BLOBS including Tamino and eXcelon as well as the fact that a few XML-enabled databases support storing XML as blobs such as DB2 (XMLCLOB type) and Oracle (in regular CLOBs) I don't see why it should be unreasonable to expect an API that expects to be used by XML databases not to support storing binary resources. On the other hand expecting the database to expect to know how to manage floating point numbers and booleans is ludicrous in my opinion. You are always entitled to your opinion. I can understand the sentiment of not wanting to mix XML and primitive datatypes other than 'string', but this is not the way of the world. The XPath 1.0 model already deals with strings, boolean values and numbers. Moreover, the strong message we are getting from the database community is in fact that there are many people who do desire 'XML' databases to handle boolean values, numbers and dates. This project, XML:DB aims to be a standard API for XML databases. Surely we want to handle the needs of people who are designing and using XML databases. I mean, if the API is not able to serve as an acceptable mechanism for executing an XQuery or an XPath 2.0, what is the point? Just because we support XPath 1.0, does not mean that we have ever intended to _limit_ ourselves to XPath 1.0. A collection/list/set of integers is a _perfectly_ reasonable and well understood entity. Not for storing in a XML database. Again, you are entitled to your opionion. I suggest, rather than dictate what you personally think ought to be in an XML database, rather, read what others intend: http://www.w3.org/TR/query-datamodel/#sequences ... Note: Sequences replace node-sets from XPath 1.0... You may find this ludicrous, but I believe the job of XML:DB is not to dictate to the XML community what an XML database ought to contain, rather to serve the needs of this community. [snip] Because those are *validation* problems as opposed to *type* problems. Validation and type are _closely_ related concepts. Hence the term: DTD Document _Type_ Definition, what is used for classical XML validation. Jonathan -- Post a message: mailto:[EMAIL PROTECTED] Unsubscribe:mailto:[EMAIL PROTECTED] Contact administrator: mailto:[EMAIL PROTECTED] Read archived messages: http://archive.xmldb.org/ -- _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- Post a message: mailto:[EMAIL PROTECTED] Unsubscribe:mailto:[EMAIL PROTECTED] Contact administrator: mailto:[EMAIL PROTECTED] Read archived messages: http://archive.xmldb.org/ --
Re: Resources and Types
In addition I'd suggest that somewhere in the API a
QName[] getSupportedTypes( ) ;
is added as well as an error code be added in ErrorCodes such as
UNSUPPORTED_RESOURCE_TYPE
which can be one of the specified error codes when an XMLDBException is thrown
from a
Collection#storeResource( )
call. That is if this is the direction the XML:DB API decides to go in.
--
THINGS TO DO IF I BECOME AN EVIL OVERLORD #1
My Legions of Terror will have helmets with clear plexiglass visors, not
face-concealing ones.
- Original Message -
From: Jonathan Borden [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Sunday, January 13, 2002 11:03 AM
Subject: Resources and Types
An XML:DB Resource corresponds to a DOM Node. The sub-type XMLResource
does directly correspond to a DOM Node, and hence supports the DOM Node
types.
Currently it is possible to support simple datatypes via this mechanism as
each of these datatypes has a textual representation, and hence can be
returned via a text node.
One option is for XML:DB to wait until the DOM becomes XML Schema aware and
leverage whatever mechanism DOM decides to convey type information. On the
other hand not every XML:DB implementation will be DOM oriented, e.g. they
might be SAX oriented, and SAX has not yet decided _if_ or how to handle
types.
Our options are roughly:
1) Forget types
2) Wait for DOM and SAX to become type aware (and then implement the type
aware versions)
3) Implement a _simple_ form of _optional_ type awareness in XML:DB
The XML:DB Resource is already most of the way there and with a relatively
small change could easily get there in terms of _being able_ to transmit
types _if the underlying database so desires_
To be clear, the mechanism I propose would allow detailed types to be
transmitted, but would largely allow the database to decide how much type
information to transmit.
The String Resource::getResourceType() currently returns either
BinaryResource or XMLResource. I propose the following change:
class QName {
String namespace;
String localName;
QName(String ns; String ln) {
namespace = ns;
localName = ln;
}
}
QName getResourceType() // or better getNamedType()
QNames for types:
The two part QName mechanism for naming types is flexible, conforms to the
XML Schema mechanism for naming types and is consistent with XML itself.
We need to name a basic set of predefined types.
The simple/atomic types are named by XML Schema e.g
xsd:integer xsd:string xsd:boolean
which correspond to:
QName(http://www.w3.org/2001/XMLSchema, integer) etc.
We may choose to name types given the XQuery Formalism e.g.
{http://www.w3.org/TR/query-semantics/, AnyComplexType}
corresponding to the current XMLResource
Given this mechanism I propose the following interface to represent
simple/atomic datatypes **as also defined by the java.lang package*:
interface SimpleTypeResource extends Resource {
Integer getInteger();
Float getFloat();
Double getDouble();
Long getLong();
Short getShort();
Boolean getBoolean();
String getString();
java.util.Date getDate();
void setInteger() ...
...
};
In order to implement _unnamed types_ e.g. those that might be specified by
a fragment of XML Schema or RELAXNG, another method is needed (such types
are not explicitly assigned a QName)
Resource getUnnamedType()
were the type specification may be returned as a DOM Node or series of SAX
events (the XML representation of the type). A reason to change the current
name:
getResourceType = getTypeName() is to eliminate confusion with a Resource
being used to specify a type (this will undoubtedly be a future issue).
So to recap, this simple type interface can be implemented on current XML:DB
implementations by replacing
getResourceType() = XMLResource with
getTypeName() = {xsd:anyType}
and
getResourceType() = BinaryType with
getTypeName() = {http://www.xmldb.org/datatypes, binary}
This is hence trivial to implement on top of current implementations, yet
provides the extensibility that will be highly valuable in future XML
database work.
Jonathan
--
Post a message: mailto:[EMAIL PROTECTED]
Unsubscribe:mailto:[EMAIL PROTECTED]
Contact administrator: mailto:[EMAIL PROTECTED]
Read archived messages: http://archive.xmldb.org/
--
_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
Post a message: mailto:[EMAIL PROTECTED]
Unsubscribe:mailto:[EMAIL PROTECTED]
Contact administrator: mailto:[EMAIL PROTECTED]
Read archived messages: http://archive.xmldb.org/
Re: Problems With Implementing XMLDB API
- Original Message - From: Jonathan Borden [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, January 11, 2002 3:05 PM Subject: Re: Problems With Implementing XMLDB API Err, so addResource on a BinaryResource is OK _from an interface point of view_ when addResource on an integer doesn't make sense? Do you really mean this? Considering that a number of native XML databases store BLOBS including Tamino and eXcelon as well as the fact that a few XML-enabled databases support storing XML as blobs such as DB2 (XMLCLOB type) and Oracle (in regular CLOBs) I don't see why it should be unreasonable to expect an API that expects to be used by XML databases not to support storing binary resources. On the other hand expecting the database to expect to know how to manage floating point numbers and booleans is ludicrous in my opinion. A collection/list/set of integers is a _perfectly_ reasonable and well understood entity. Not for storing in a XML database. What makes this different then a collection that expects a list of XML documents each of which is valid to a particular schema, or a parent XML element into which you attempt to insert a child element that would make the XML invalid? Because those are *validation* problems as opposed to *type* problems. In both cases the database knows how to support the types but they happen to be invalid in the case of booleans and integers they are not the correct type to be handled by the database -- THINGS TO DO IF I BECOME AN EVIL OVERLORD #59 I will never build a sentient computer smarter than I am. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- Post a message: mailto:[EMAIL PROTECTED] Unsubscribe:mailto:[EMAIL PROTECTED] Contact administrator: mailto:[EMAIL PROTECTED] Read archived messages: http://archive.xmldb.org/ --
Re: Problems With Implementing XMLDB API
- Original Message - From: Kimbro Staken [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, January 11, 2002 8:48 AM Subject: Re: Problems With Implementing XMLDB API You're right in many cases that won't make sense, that doesn't have to be the case though. The resource instance could easily know where it came from and in theory could also know how to store it self back where it came from when modified. It doesn't work that way right now and I don't know it it should or not, but it would be consistent and would actually be very powerful. For this reason I suggest dissasociating the results of XPath queries from resources. What did you have in mind? Either a hierarchy of XPathResults objects or a single XPathResult type that has types information obtained from static types in an interface such as is done in the java.awt.Color or DOM classes. Apache Xalan actually uses both appraches http://xml.apache.org/xalan-j/apidocs/org/apache/xpath/objects/XObject.html The benefit of the hierarchy of objects is that objects of type XPathNodeSet and XPathTreeFragment can also implement the XMLResource interface and thus have the best of both worlds. A clear differentiation in the types returned by XPath queries while the ability to treat XML returned from XPath queries as resources is preserved. Thoughts? -- THINGS TO DO IF I BECOME AN EVIL OVERLORD #59 I will never build a sentient computer smarter than I am. -- _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- Post a message: mailto:[EMAIL PROTECTED] Unsubscribe:mailto:[EMAIL PROTECTED] Contact administrator: mailto:[EMAIL PROTECTED] Read archived messages: http://archive.xmldb.org/ --
Re: Problems With Implementing XMLDB API
- Original Message - From: Kimbro Staken [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, January 10, 2002 6:06 PM Subject: Re: Problems With Implementing XMLDB API It seems that somewhere along the line whoever designed the XML:DB API decided that XPath queries should return ResourceSets which seem to map to very coarse grained database objects like XML documents and BLOBs even though XPath queries can return strings, booleans, numbers and node lists. Reconciling both these realities would involve a less than trivial amount of workarounds to what I think is fundamental flaw in the XML:DB API design. Is there any rationale behind ResourceSets and Resources being the most granular objects that can be returned by XPath queries? Yes, because a Resource is an abstraction for any kind of data that can be stored within the database. Right now the limitation is not in the fact that it returns resources but that it returns an XMLResource and an atomic value is not XML. This only affects XPath queries that return atomic values, node lists map into a list of resources. This is a known issue that I was hoping to address in the next revision of the API. We can discuss how on the API list. This isn't the W3C, there is no cost to participate and we could use the help.
Re: Problems With Implementing XMLDB API
- Original Message -
From: Jonathan Borden [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, January 11, 2002 2:38 PM
Subject: Re: Problems With Implementing XMLDB API
so? you also cannot store a book where SQL expects an int.
Now I'm confused.
What _good_ RDBMS API have you used that allows you to pass types that aren't
natively supported by the DB in update operations? Just to recap I'll rewrite
the query that Kimbro agreed didn't make sense that you are now advocating
should be a valid part of the API
String xpath = count(/movie/title='Gladiator');
XPathQueryService service =
(XPathQueryService) collection.getService(XPathQueryService, 1.0);
ResourceSet resultSet = service.query(xpath);
ResourceIterator results = resultSet.getIterator();
while (results.hasMoreResources()) {
XPathResultResource resource =
(XPathResultResource) results.nextResource();
myCollection.addResource(resource); /* THIS MAKES NO SENSE */
}
Please, explain to me why being able to do the above is a good thing.
--
THINGS TO DO IF I BECOME AN EVIL OVERLORD #59
I will never build a sentient computer smarter than I am.
_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
Post a message: mailto:[EMAIL PROTECTED]
Unsubscribe:mailto:[EMAIL PROTECTED]
Contact administrator: mailto:[EMAIL PROTECTED]
Read archived messages: http://archive.xmldb.org/
--
