tauZaman DESIGN DECISIONS (Component names)
1. Related to Calendar Fields.
A Field consists of; Granularity (ies) and additional Fields in Calendar specification file.
So, basically a Field contains a Name and a Value. Name is the name of Granularity
name or additional Field name in specification file. And Value is their values in a specific time.
According to above idea, design decisions are;
1. Field class contains a Name (String) and a Value (String). (ex: name="month", value=1)
2. Fields class contains zero or more Field and zero or more Fields.
3. In Property Specification file;
<fieldValue>
element name is changed to <fieldInfo> since <fieldValue> does not
explain it,
that is to say, that element contains Field's Name and relates its Value to a variable and a table/function name.
2. Local/Global names related to Granularity names in Calendar and Calendric System Specification files.
Instead of keeping conversion tables (typically Hash Tables) from local (to a Calendar) to
global (to a Calendric System) Granularity names or vice versa, it is better to base this conversion on a
semantic that makes the distinction. Let's first state the idea and then list the advantages;
Idea:
In a Calendric System Specification file, names of imported Calendars are unique throughout
this Calendric System (It does not have to be inter Calendric Systems). We can use this fact. If there
is a conflict between Granularity names of two Calendars, and a irregular mapping should be given
in terms of one of these conflicting Granularity(ies) in Calendric System Specification file, then a
specification file writer will add the name of the corresponding Calendar to the name of the Granularity
name with a dot in between (see an example).
That clearly makes the distinction since, again, names of imported Calendars are unique throughout
Calendric System. As long as this idea is applied through out the design and implementation, we can
get a global name of a Granularity when we have a local name and Calendar name. Conversely, it is
easy to show that we can derive a local name when we have a global name of a Granularity, moreover
we can also derive the name of the Calendar name that was used.
Advantages:
We don't have to keep the conversion tables (storage reducement).
We also form a Granularity name, when we need it.
Clarity and brevity in Calendric System Specification file, since there is no need to rename and renumber elements.
3. Related to some element names in Calendar Specification file.
Element names (and their attributes' names) of Granularity declarations should be highly self-explanatory.
So, below representation might handle this;
When we declare a new Granularity, we give its name, and a Mapping. So, a declaration element
name is not solely include one or the other, but one thing is sure. That is we are declaring a Granularity.
So, the name of the element is "granularity". And then immediately question arises; What is its name?
So, name of this Granularity is immediate attribute of granularity element.
Then we may have two options; Either it has a regular or irregular mapping with other declared
Granularities with appropriate other information;
Example: Assume we have "Granularity dayHundredth is 864 second with anchor 0 second"
information in Astronomy Calendar. So, the representation is;
<granularity name = "dayHundreth" >
< regularMapping from = "second" conversionFactor = "864" anchor = "0" anchorGran = "second" />
</granularity>
How can we read this piece of xml information? Granularity dayHundreth has a regular mapping, which is;
from granularity second with conversion factor 864 with anchor 0 second.
However, also note that this decision is not valid for Calendric System Specification file, since there we
solely have a mapping between to already declared granularities. So, the only difference between above
representation and representation in Calendric System Specification files is the "name" attribute of the
"granularity" element . In the first one, it is "name", whereas, in the latter, it is "to" (because that granularity
is already declared). (see the difference in item 5.)
Example: Assume we have "Granularity month is irregular day with functions gregCastMonthToDay, gregCastDayToMonth, gregScaleMonthToDay" information in Gregorian calendar.
Obviously we have to point out urls of functions' classes. However, it may not be the case that all functions are
in the same class, or even worse, in the same url. So, we have three alternatives, on which most likely final decision
will based on an assumption;
1. < granularity name = "month" >
< irregularMapping from = "day" >
< function name = "gregCastMonthToDay" url = ".../classname.class" />
< function name = "gregCastDayToMonth" url = ".../classname.class" />
< function name = "gregScaleMonthToDay" url = ".../classname.class" />
< /irregularMapping >
< /granularity >
in which, more than one functions are in different urls.
2. < granularity name = "month" >
< irregularMapping from = "day" url = ".../">
< function name = "gregCastMonthToDay" className = "classname" />
< function name = "gregCastDayToMonth" className = "classname" />
< function name = "gregScaleMonthToDay" className = "classname" />
< /irregularMapping >
< /granularity >
in which, all of the functions are in the same url, but with different class names. Note that url contains
a directory (or a .jar file).
3. < granularity name = "month" >
< irregularMapping from = "day" url = ".../classname.class">
< function name = "gregCastMonthToDay" />
< function name = "gregCastDayToMonth" />
< function name = "gregScaleMonthToDay" />
< /irregularMapping >
< /granularity >
in which, all of the functions are in the same url and in the same class.
Final decision is; it is better to support option 2 and 3. Option 2 points to a .jar file or to a directory
containing classes, and option 3 points to a single class containing all the methods. The difference between
Calendar Specification and Calendric System Specification file is only the names of xml elements. (see the
difference in item 5.)And the reason of this difference is explained in item 3.
Here it is important to note these facts about the system;
There can be no method overloading since parameters are invariants.
"name" attribute of a "function" element should be unique through out a mapping.
These arguments also lead to another discussion on urls in xml files.
4. Related to URL fetching from different xml files. (due to rules in URLClassLoader class in Sun JDK.)
There are two branches to think about;
1. In the xml files, which represent "Field Value Functions" and Calendars' "Fields Parsing" functions.
In these, there is no need to represent the name of the methods, since they are predetermined. For example;
indexToString in "Field Value Functions", or FieldsToGranule in "Fields Parsing". So, the only thing to
represent is class name along with the url.
When we fetch a string URL from xml file, we will search for a ".class" pattern at the end. If we can't find
it we will return an error.
2. In the xml files, which represent "Irregular Mappings".
In these we may have to support two representations. First a url pointing to a directory, second a url pointing
to a specific class (see item 3). So,
When we fetch a string URL from xml file, we will search for a ".class" pattern at the end. If it exists it is ok,
otherwise it should end with either "/" or ".jar".
Just right here (seem to rather awkward, however, in fact, a very good place) we have to note that,
we do not mention anything about the parameters of all these methods in these representations. That also
means they are predetermined and we can use this fact to write ClassLoaderMethodCaller class.
5. Related to some element names in Calendric System Specification file.
Representation of mappings in Calendric System Specification file is not very different than
Calendar Specification file.
Example: Assume we have "Granularity Astronomy.second is 864 Gregorian.second with anchor 0 Gregorian.second" information in American Calendric System. So, the representation is;
<regularGranularityMappings>
<mapping from = "Astronomy.second" to = "Gregorian.second" conversionFactor = "864" anchor = "0" anchorGran = "Gregorian.second" />
...
</regularGranularityMappings>
Example: Assume we have "Granularity Timecard.year is irregular Gregorian.day with functions astroCastYearToDay, astroCastDayToYear" information in American Calendric System. And the
representation will be one of;
1.
< irregularGranularityMappings >
< mapping from = "Timecard.year" to = "Gregorian.day" url = ".../">
< function name = "astroCastYearToDay" className = "classname" />
< function name = "astroCastDayToYear" className = "classname" />
< /irregularMapping >
...
< /irregularGranularityMappings >
2.
< irregularGranularityMappings >
< mapping from = "Timecard.year" to = "Gregorian.day" url = ".../classname.class">
< function name = "astroCastYearToDay" />
< function name = "astroCastDayToYear" />
< /irregularMapping >
...
< /irregularGranularityMappings >
Or it may include both mapping ways in one "irregularGranularityMappings" element.
But having all mappings (whether it is regular or irregular) in one mapping element is more self contained and meaningful, which is;
<mappings>
<regularMapping from = "Astronomy.second" to = "Gregorian.second" conversionFactor = "864" anchor = "0" anchorGran = "Gregorian.second" />
<irregularMapping from = "Timecard.year" to = "Gregorian.day" url = ".../classname.class">
< function name = "astroCastYearToDay" />
< function name = "astroCastDayToYear" />
</irregularMapping>
<irregularMapping from = "Timecard.year" to = "Gregorian.day" url = ".../" >
< function name = "astroCastYearToDay" className = "classname" />
< function name = "astroCastDayToYear" className = "classname" />
</irregularMapping>
...
</mappings>
By this we can also utilize parsing techniques used in Calendar specification files in here.