XML Standar for adding data to Notes fields of Basic Four apps.
Grant Robertson
data fields within the Notes fields of the basic four apps. This way
applications could extend the features of the basic four apps without
having to create their own external databases or, worse, ignoring the
standard app's database altogether. For instance, DateBk5 adds linking
and extra features to the calendar and todo apps by adding some text to
the note field. DateBk5 is smart enough to ignore this text when deciding
whether to display a note icon. If this is the only text in the note then
no icon is displayed. However, other apps don't know about this extra
data and just display a note icon anyway. I am just starting to use
ShadowPlan and it also adds text to the notes field of the basic four
apps. Pretty soon I am going to have some kind of text in the notes field
of almost every item I have stored in my basic four apps. The note icon
will be worthless to me. I will have to just click on it to see if there
is some human readable information there.
Now, if there were an XML standard and all of this extra data were
tagged using XML, then it might be possible to write a hack that would
cause apps to ignore text within XML tags when deciding whether to
display the note icon. They could also hide all the XML data when the
user is adding their own notes rather than just hiding their own
proprietary data like DateBk5 does now.
But that is just the beginning. Now applications could use each
other's data and add even more features. Conduits could be created to
sync the XML data within the Palm's notes fields to the appropriate
fields (or custom fields) in Microsoft Outlook. Add-In's could then be
created to extend the functionality of MS Outlook using this new data.
For instance, links created in DateBk5 from an appointment to a list of
address book entries could be turned into an attendee's list in Outlook.
The ShadowPlan desktop app could link to items within Outlook and
synchronize those links back to the Palm version or vice-versa. You would
have to be careful to avoid XML bloat by limiting the size of the tags or
the notes fields would quickly be filled up.
You could even use XML data to create outlines within the notes
fields of the Basic Four apps without even having to go to a separate app
like ShadowPlan. Not that outliners like ShadowPlan would be obsolete but
it would be handy to have a subset of it's functionality directly within
the note of a basic four item.
The ideal situation would be if Palm jumps on the bandwagon and
creates a special field just for this extra XML data. An interim step
would be if they would just cause the Basic Four apps to not display XML
data as standard note text and allow unlimited note field sizes.
Now, I'm not a programmer (yet) nor am I an expert in XML. So I wouldn't
be able to really spearhead this endeavor but I sure would like to use
the apps that could be developed using this approach. I am just writing
this to get the ball bouncing around in peoples heads.
Mike Meyer
> Now, if there were an XML standard and all of this extra data were
> tagged using XML, then it might be possible to write a hack that would
> cause apps to ignore text within XML tags when deciding whether to
> display the note icon. They could also hide all the XML data when the
> user is adding their own notes rather than just hiding their own
> proprietary data like DateBk5 does now.
Why XML? One of the beauties of the Palm is that the data files are
very small. XML has a lot of nice features, but small data isn't one
of them.
All the advantages you want would accrue to any standard that was
endorsed and published by Palm, not just XML. Hopefully, they could
come up with something more lightweight than XML.
<mike
--
Mike Meyer <m...@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
Grant Robertson
reading this and many other things Jeff has written I can tell he really
knows his way around the Palm OS and programming in general.
----------------
For the record, Shadow only adds to the Note field if you ask it
to. What is listed is the Shadow Plan filename and a summary of the
parental hierarchy leading to the item (to make it uniquely
identifiable). DateBk4 & 5
have a much higher use of the note field due to it living entirely
in those databases. Same with Agendus/AN. Not sure how many other apps
touch those fields.
XML may not be appropriate, though it is most flexible; making
something XML-like but very pared down could be do-able.. building a full
XML parser would be bloaty and uncool on older units. (XML parsing at
16MHz can be savage. Been there, done that, made me unhappy :) (Remember
"XML" implies a lot) Also note that since Palm OS is international, using
XML with a number of encodings to support multiple languages gets clumsy
fast in the Notes field. But anyway.
I think your goal needs to be clarified. One never chooses the
transport before the cargo.. choosing XML before narrowly defining the
objective is bad. Let us narrow down the exact goals, then chose an
appropriate transport mechanism. (Classic design fallacy number one :)
One does not decide what language to use to build an app, until one
decides the app and what platform, and all that. But too commonly you see
someone start hacking away with no idea..
Is the goal to make it easy for apps not to show a note attachment
icon when meta data is present? Or is it to allow interoperability? (
Very
different goals. One is simple, the other could be done via API or data
tagging or other methods..)
Something to wonder about is where Palm OS 6 is taking it.. when
the format of the databases will change (or will it?) If the database
format changes, one must hope that Palm will define an extension
mechanism
(for arbitrary extensions and extension ownership).. the existing
databases are badly designed, since obviously no expansion can be done
(and it is uncool to put extension data *after* the note, even though it
wont' break the built in applications to do so). It could be interesting
to build a key/value pair system after the note, but it is too easily
lost by the built ins since they truncate like mad.
So.. if your goal is to simply hide the note icon, then folks need
only agree on a termination character.. the note no longer exists after
some sequence of characters, say. Then agree on some way of defining a
header.. i.e.: One could make a terminator of ###Coog where ### is the
terminator and Coog is my Shadow creator-id. Then everything until a
space or another terminator would be Shadow specific. Say.
Easy.
Or if the goal is interopability, then one must be more careful to
agree on a system easily parsed.
But a goal needs be defined first :)
> Now, if there were an XML standard and all of this extra data were
> tagged using XML, then it might be possible to write a hack that would
> cause apps to ignore text within XML tags when deciding whether to
> display the note icon. They could also hide all the XML data when the
> user is adding their own notes rather than just hiding their own
> proprietary data like DateBk5 does now.
Hacks aren't supported in OS5, and a Hack doing so would likely
cause meta data loss. i.e.: If the Hack suppressed it on read, then any
update to the item would lose the meta data. If it was suppressed on
display, likely the same problem.. edit a field, the meta data hidden,
chances are it would be lost when the application reads the Field
contents
back in.
It is best for the apps to be aware instead.
> You could even use XML data to create outlines within the notes
> fields of the Basic Four apps without even having to go to a separate app
> like ShadowPlan. Not that outliners like ShadowPlan would be obsolete but
> it would be handy to have a subset of it's functionality directly within
> the note of a basic four item.
Notes are 4k limited, and data access needs to be fast. Theres a
reason the system isn't just one big long text pad with all apps dipping
into it. Using your own database has a very good set of reasons ;) You
don't have ram to blow away keeping giant parse trees in memory, so you
need to format the data for speed of read :)
> The ideal situation would be if Palm jumps on the bandwagon and
> creates a special field just for this extra XML data. An interim step
> would be if they would just cause the Basic Four apps to not display
> XML data as standard note text and allow unlimited note field sizes.
If Palm changes the format, they'll do it a lot better (I would
assume) than just adding an XML field; a generic extension mechanism is
not
hard to make. i.e.: A field "number of fields" and a field to hold a
table
identifying where the fields begin works (i.e.: a pdb), or a key/value
system or any number of methods. See RADIUS attributes for fun.. simple
and worked well for a decade or so now.
> Now, I'm not a programmer (yet) nor am I an expert in XML. So I
> wouldn't be able to really spearhead this endeavor but I sure would
> like to use the apps that could be developed using this approach. I am
> just writing this to get the ball bouncing around in peoples heads.
1) Nail down agreeable objectives
2) Decide how to fulfill those objectives
3) Sanity check.. worth doing?
4) Decide how to implement (2)
Sorry for quick thoughts; I'm on the way out the door, but thought
I'd spew out a half baked response right away. Apologies for not being
clear or going into depth,
jeff
Grant Robertson
> Grant Robertson <BO...@BOGUS.INVALID> writes:
>
> > Now, if there were an XML standard and all of this extra data were
> > tagged using XML, then it might be possible to write a hack that would
> > cause apps to ignore text within XML tags when deciding whether to
> > display the note icon. They could also hide all the XML data when the
> > user is adding their own notes rather than just hiding their own
> > proprietary data like DateBk5 does now.
>
> Why XML? One of the beauties of the Palm is that the data files are
> very small. XML has a lot of nice features, but small data isn't one
> of them.
>
> All the advantages you want would accrue to any standard that was
> endorsed and published by Palm, not just XML. Hopefully, they could
> come up with something more lightweight than XML.
XML is the only thing I could think of. It wouldn't have to be a full XML
implementation. Just something that uses plain text that could be agreed
upon by all developers.
Eric Lindsay's spam trap
>other's data and add even more features.
Although not using XML, that is the way many applications work in
Psion Epoc PDAs. You can embed objects in applications, and when
encountered, the appropriate application handles the display or
operation of the embedded object.
Epoc Word can include Sketch objects, or Sheet and Graph objects,
or Record objects for voice output, or another Word document as
an object (and so on). Epoc Jotter can contain the same four
objects, as can Epoc Data, and Epoc Agenda (the diary, PIM, todo
application). This seems to me to enormously increase the
versatility of the built in applications.
For example, you can do an invoice for printing in Epoc Word,
with your company letterhead from Sketch, a table of invoiced
items from Sheet, and a signature from Sketch. Or a Data file of
your CDs with pictures of the covers, and short music files
associated with each record. Or a Data file of say product
details with interactive Sheet objects to automatically calculate
quantity and retailer discounts for each type of item, or do do
currency conversions or whatever you like. I think it is a great
idea, and extends what each individual application can do
enormously. Sometimes I would prefer that you could also embed
some of the "stateless' applications, like say the Calculator,
although this isn't as much of a need (because you can have
dozens of applications open simultaneously), and would make
converting files to a PC even trickier.
It does make it a bit hard defining file formats, because you end
up with a stream where various bits are identified automatically
by the appropriate application. It also makes it possible to
generate a file that can't be converted. For example, if you
make a Data file with massive amounts of Sketches or photos, you
can make it as large as your Compact Flash. It will still run,
because each Data record is brought into memory only when
accessed. However if converting it on a PC to say MS Access, it
seems to act as if the entire database must fit in working
memory, so if your memory is smaller than the Compact Flash ...
--
Eric Lindsay http://www.ericlindsay.com/guff
Airlie Beach Qld Australia - Great Barrier Reef entry
Psion & Epoc site http://www.ericlindsay.com/epoc
Grant Robertson
says...
> > But that is just the beginning. Now applications could use each
> >other's data and add even more features.
>
> Although not using XML, that is the way many applications work in
> Psion Epoc PDAs. You can embed objects in applications, and when
> encountered, the appropriate application handles the display or
> operation of the embedded object.
>
> Epoc Word can include Sketch objects, or Sheet and Graph objects,
> or Record objects for voice output, or another Word document as
> an object (and so on). Epoc Jotter can contain the same four
> objects, as can Epoc Data, and Epoc Agenda (the diary, PIM, todo
> application). This seems to me to enormously increase the
> versatility of the built in applications.
I'm not really looking for embedded objects. Just a standardized way of
storing extra data within the notes fields.