[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [higgins-dev] Data Model: Mixed attr types or not
- From: "Jim Sermersheim" <jimse@xxxxxxxxxx>
- Date: Tue, 15 Jan 2008 08:47:23 -0700
- Delivered-to: firstname.lastname@example.org
True, I sort of jumped to the conclusion of how to fix the API based only on this thread's subject.
On #1, we should probably agree that a schema-less Context is something we want/need to provide for. I'm not sure what all the ramifications are. If we decide yes, it might make more sense to move the declaration of the attribute's data type to where the attribute gets created rather than where each value gets created.
On #2, I believe there is only one method which currently takes a value data type as well as the data as an object. I agree that for the conversion reasons you point out, it would be handy to preserve the ability to pass in some generic value and declare its type.
>>> "Daniel Sanders" <dsanders@xxxxxxxxxx> 01/14/08 5:51 PM >>>
I don't think the API discussion should center only around whether or not an attribute's values are always the same data type. The fact that a data type parameter is passed into the API does not necessarily mean that we intended to allow an attribute to have multiple values with different data types. Context providers can still enforce the rule that all values for an attribute must be the same data type. I would argue that specifying the data type in the API does no harm, and may have some benefits - as noted below.
To date the argument seems to be that since the schema knows the data type for an attribute, there is no need to specify it in the API. Here are a couple of reasons for continuing to pass data type in the API:
1. Schema-less context provider. In this case, the context provider simply allows an application to build up digital subjects as needed, no checking of schema. A schema-less context provider could easily enforce that all of an attribute's values are all of the same data type, but the first attribute value added determines the data type for the attribute. The XML file context provider currently works this way.
2. Data conversion. This is a nice convenience for applications. Instead of having to convert from the data type they use to manipulate data to the attribute data type, they can simply pass in the data type they are using and have the context provider do the appropriate conversions. This could be particularly handy where an application is interacting with multiple different context providers, each of which uses a different data type for a particular attribute. The application may not actually know what the underlying data types are for an attribute in a given context provider. Instead, it relies on the underlying context provider to perform whatever data conversion is needed, if any.
One could argue that a context provider could determine the source value's language type (using something like "instanceof" in Java) and based on that do an appropriate conversion. But not all languages have a mechanism for determining the "type" (or class) of an object at runtime (C,C++ for example). If we ever do IdAS in one of these languages, we would need to explicitly declare an object's data type in order for the context provider to do proper data conversion. Furthermore, even if an object's type can be determined using an instanceof-like mechanism, it may still be insufficient to know what kind of conversion is needed. For example, in Java "instanceof" may reveal an Object to be a "java.lang.String", but if the internal data type is Base64EncodedString, a context provider may need to know if the incoming String was Base64EncodedString or HexEncodedString or OctalEncodedString, etc., etc. - information that may not conveyed by instanceof.
>>> "Jim Sermersheim" <jimse@xxxxxxxxxx> 1/14/2008 2:25 PM >>>
This is the thread for discussing what started with http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg03722.html
So far, we have these inputs:
I understand that each of an attribute's values are always the same data type. I think in general this keeps things simple and is what's likely expected by new users. I also think that allowing mixed types will cause lots of head scratching when values are being compared for equivalence (since two equal values are not allowed on the same attribute.
Drummond assumed they would all be the same type.
Markus reports that HOWL doesn't enforce same-typed values, and that in fact, it can't.
Paul states that in the Higgins Data Model, they are all the same type, and is working to fix the HOWL.
Daniel would like to allow for different types.
Mike pointed at the ITU definition of GeneralName as an example of why we might want to allow different types. He (as well as Daniel) further notes that in solving this kind of example, it's best to retain the original type/value pairing -- otherwise you loose the original type.
The last comment was Jan 8 http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg03736.html
So, the current expectation and understanding is that values are of the same type. There is some belief that allowing different types would be a good thing.
I feel compelled to address bug #190594 in terms of the way the data model is known/understood to behave today, and make adjustments to if if/when we decide to allow values to be varied in their data types.
Does anyone disagree with that? If not, I'll fix the bug as prescribed.