Subject: Re: Some of Word's fields
From: Justin Bradford (justin@ukans.edu)
Date: Thu Jan 13 2000 - 17:03:00 CST
> If so, then the next step would be to go through on a field-by-field basis
> and XML-ify your list. Bingo. Instant spec document! :-)
I'll begin making XML versions of these (and flesh out the specifics on
the various formats/switches). Others are welcome to contribute.
> What are the switches on the Date field, and why aren't they present on the
> other fields? Are they just syntactic sugar (ie, is there a switch for Date
> which makes it synonymous with, say, CreateDate?)
There are some field type specific options, but most also support a
date/time format specification, so it is possible to have Date and Time
output the same thing. These fields are really pretty easy to describe
(and implement), and I plan to do them first.
> Will each of the following fields need a new= argument in our file format,
> or does this just indicate that you can override the contents of the field
> from the UI?
Normally, it just outputs what is in the summary info. The new argument
changes what is in the summary info. So, I imagine:
> <field type=Comments>typed in by user</field>
will work fine. When the user edits "typed in by user", it simply changes
the summary info comments, too. Or that could be a switch, so that
changing this field does not change the summary info, but instead becomes
nothing more than a field with arbitrary user text. I can't imagine why
that would be useful for someone, though. So do we need a switch, or
should these fields just be linked to the summary info all the time?
> >From a quick scan, it looks like some field instances have names or
> identifiers which allow them to be referenced by other fields (or, more
> likely, by the scripting language). Is this correct?
I believe so, but I'm not sure yet. Some of the comparison fields don't
really make sense unless they can be dynamic (ie. if user = joe "Hi, Joe"
"Who are you?")
> If so, then we should be careful to avoid argument namespace collisions in
> our file format. Our scripting implementation will be *much* cleaner if we
> can always locate unique fields by referencing, say, the "name" (presumably
> user-assigned) and/or "id" (presumably auto-generated) arguments of each
> field.
Automatic ids would probably be confusing to the scripter. I don't think
it would be a bad thing to force them to "name" any fields they want to
reference.
> I haven't delved into the details of any of these fields, but I'm guessing
> that not all instances of say "bookmark" or "name" here should share the
> same argument name.
No, they're basically argument types. You have to specific a particular
bookmark (this is what you're asking, right?)
Justin
This archive was generated by hypermail 2b25 : Thu Jan 13 2000 - 17:03:02 CST