As I said we'll work in different areas.
Enumerations
I'm moving more and more enumerations to the data types schema. The target is to eventually have them all there.
IDs
This is a serious step. We learnt during the host implementations that it would be easier to implement IDs, if they had the same name when they mean the same.
That was not the case in the past. There are Master_ID and Media_ID, although they mean the same. The reason we had them was that my XML Authority showed an error message, when I had the same name in different dtd. The reason was that the Attributes pane showed attributes once only even if they were used by different elements. As the element could be (and were) used in different dtd (or schemas), the application tried to save all dtd after I changed those attributes, although only the currently active one was under its control. The application could (and can) not handle include files too well. The error kept me away from using the same names in different dtd.
After some investigation the last days I learnt that the error was not more than an error message. There was no real damage. The error just showed it couldn't save the other dtd involved in the same attribute definition. But that was not a problem.
Anyhow, the new application I use (Turbo XML, which now does not only include an updated XML Authority, but a XML editor as well) is now listing every attribute separately (that means per element), even if it is the same name. Now it is clear that you can change the attributes of the currrently active schema - and now without interfering with other dtd - but no attribute of other schemas. So I am no more able to create the cause of the previous error by the redesign of the app.
That allows us to merge some attribute names:
Master_ID/Media_ID -> ID
Master_Proprietary_ID/Media_Proprietary_ID -> Proprietary_ID
Master_Name_ID/Media_Name_ID -> Name_ID
Master_CommandSequence_ID/Media_CommandSequence_ID -> CommandSequence_ID
Let me know, if I forgot any candidate.
This move will simplify some host implementation code.
Any veto?
We have another request from IBM, which is to get rid of the ID (new name) completely for further simplification of the implementation. As I mentioned earlier, we have to balance between the implementation process and the XML editing task. So far we have two kinds of identifiers. The ID is the unique identifier, while the xxx_Global_ID/Proprietary_ID is more a classifying identifier. The latter could appear more than once for different records of the same element (e.g. different media sizes could have the same global ID because of different minimum hardware margins or other reasons, but the ID must be unique). This allows simplification of interdependencies. If you'd use them smartly, you could avoid long concatenations.
With getting rid of the unique ID and demanding the global/proprietary ID to be unique, we'd save the handling with one attribute, of course. We'd have one unique and classifying attribute to identify the record, which improves not only implementation, but readability as well.
On the other side now we have to think of whether this could cause problems with the current structures. We may have to split some structures into smaller, more modular structures. A candidate is media size to be split into media size and hardware margins. Connecting these structures can be managed by either interdependencies or composite features (interdependency: if size is Letter, use margins_xxx; composite feature: create CF form, comprised of size and margins). We'd have to review the current structures for redesign requirements.
Do we want that?
I am quite open and I have to serve both sides of the development. So I'd like more input from you before I make a decision (I do not expect you to write a sample app to find out, just tell me what you think, but today).
There is some other argument behind the subject: More modular structures would ease the selection of features in a command line mode (think of Linux). It would certainly help in environments with very simple graphic user interfaces as well. And there are days when I think that the moment we'll support the user group policies we have an excellent chance to offer something for printing support in PDA/telephone and other 'hosts' with simple dialogs. Keep in mind that there are a number of communication protocols, but there is no standard to tell the host what subset a specific printing device can support, none of them care about UI strings, none about interdependencies, none support user group policies (or whatever they could call it).
This is an important decision. Let me know!
Regards
Norbert Schade
Principle Software Engineer
Host Software Group
Oak Technology, Inc.
10 Presidential Way
Woburn, MA 01801
USA
Phone: 1-781-638-7614
Fax: 1-781-638-7555
email: norbertschade@oaktech.com
This archive was generated by hypermail 2b29 : Thu Aug 23 2001 - 11:06:01 EDT