Re: [toolbox] Extended Attributes

[Maxwell, A. R <ada...@pn...>]

On Jul 5, 2005, at 13:39, Maarten Sneep wrote:

> On 4 Jul 2005, at 12:23, J=E9r=F4me Laurens wrote:
>
>
>> For example, if you put the master file name of a tex source file =20
>> at the end of the source file (like emacs does), it will be hard =20
>> coded in each slave file.
>> When you change the master file (what we are going to need for =20
>> efficiency) you will have to change that information in each slave =20=

>> file concerned... Not very efficient.
>>
>
> Why would you want to change the name of the master file? I don't =20
> get the example you give here - since the slave-files are stored in =20=

> the master file, and their relative location is fixed through the =20
> \input statement (or format specific alternatives). So _moving_ the =20=

> master is not an option, and renaming (IMHO) is a relatively rare =20
> action. Inefficiency is unimportant for such cases.

If you store aliases as data in a plist, though (BDAlias is handy for =20=

this), renaming isn't a problem for the front-end specific info.  Why =20=

put the name of the master file in the slaves if TeX doesn't need it =20
(or maybe it does...I'm not much of a TeXpert)?

>
>> Another big problem concerning metadata in the source deals with =20
>> the encoding.
>> The encoding is meant to deal with the text only, but it will =20
>> naturally apply to the metadata too.
>> People using marks would want to use utf16 because it fits their =20
>> natural language and they feel far more comfortable with that (the =20=

>> same for tex comments). For more general metadata, some frontends =20
>> might want to store pure binary metadata... But if the metadata =20
>> are embedded, those things will be forbidden.
>>
>
> Last time I checked there were no TeX engines that accepted utf-16. =20=

> Since utf-8 is a strict superset of ASCII, I don't think there is a =20=

> problem, especially since both uft versions can encode the same =20
> information.

I think XeTeX accepts either UTF-16 or UTF-8.  Also, trying to read =20
Latin 1 files in as UTF-8 will cause an error in Cocoa, and you get =20
nothing back (although this is arguably better than the corruption =20
you get when reading MacOSRoman as UTF-8 or something).

>
> And for pure binary metadata: I ran away from word to get rid of =20
> binary files, so if a special project file needs to be added, let =20
> it be an xml file - or something else BBEdit can handle.

You can archive binary data such as aliases and put it in an XML =20
file, which is how OS X apps store their "Recent Files" lists in a =20
property list.  It doesn't really matter if the file is XML or =20
binary, as long as it's an open standard.

[...]

>
>
>>> On the other hand, if there are other standards that spring up =20
>>> for storing the encoding of the file in an extended attribute -- =20
>>> well, we may as well use that as well! (too many `well's)
>>>
>>> I am more interested with the possibilities raised from a rich =20
>>> document interface, and I think WHERE the metadata is stored is =20
>>> less of an issue -- it can always be changed if a new method =20
>>> turns out to be better.
>>>
>>
>> My opinion is the following:
>>
>> We have 3 locations to save metadata attributes
>>
>> 1 - inside the source file, like emacs does
>> 2 - in an external file at a definite location relative to the =20
>> source file, like resource forks and the TeX Wrapper Structure I =20
>> presented in EuroTeX 2005
>> 3 - in an external file at a definite location, relative to the =20
>> application, like BBEdit and TextWrangler do, like unix app do in =20
>> their .cshrc and alike...
>>
>> 3 is not portable.
>> Moreover, I am wondering why BBEdit put this 15 days limit... May =20
>> be they had a structural reason that prohibits an intense use of =20
>> this design...
>>
>
> About 313 entries and counting. There are some types of metadata =20
> you do not want to inherit from coworkers, while keeping them for =20
> your own sessions: window locations come to mind (especially if you =20=

> have a 12" powerbook, and the colleague has a 30" display). I think =20=

> you are too quick in discounting the private option for (some =20
> types) of metadata.

And I don't want window settings from my work machine transferred to =20
my home machine, for the reason you mention.  This sort of =20
information belongs in user defaults or some cache file, as BBEdit =20
does.  I don't care about the window settings for the readme file =20
that I opened up 6 months ago and then trashed...

>
>
>> So only 1 and 2 remain, and no choice should be made between them: =20=

>> they are different and will serve different purposes, we need both.
>>
>> For point 1, marks and collapsing region bounds are the only kind =20
>> of informations that really need to be stored inside the source.
>>
>
> With the marks I agree, with the collapsing region bounds, I'm not =20
> too sure: they may be a personal preference, not shared between =20
> collaborators. This information can be stored outside the source =20
> file (in some project file, which can contain the lot in a TeX =20
> wrapper - however they may look*).

I think this is the sort of thing Xcode stores in it's project =20
bundles, although I haven't looked closely.  A wrapper seems like a =20
reasonable location for this since you might want the same settings =20
at all locations, but I'd expect it to be at least on a per-user basis.


>> Moreover, in a very near future, it will not be strange to use an =20
>> XML input instead of the standard tex input.
>>
>
> The engine underneath is still likely to be TeX - and for the =20
> foreseeable future that means utf-8 input, not utf-16 or utf-32, =20
> but that is a minor remark here. It does mean that at the very =20
> least for now we can store the text encoding in the file itself, =20
> and for XML there are official options, also in-file.

XeTeX might be an exception to this, as previously noted, so storing =20
encoding in the file might be  practi=13ca=13ble for a shorter time than =
=20
we realize.

>
>
>> If we want to store the same metadata in the source file, we will =20
>> have to design another mean for that purpose.
>>
>
> XML files can contain comments as well, no real need to change =20
> anything here, if at least we keep this in the back of our minds. =20
> OTOH, xml may require such a different editor because of the =20
> verbosity-level, that keeping it in hte back of our minds is way =20
> too much honour.

Not that it's relevant, but I use LaTeX at least partly because I =20
think editing XML sucks.  If Mike had chosen an XML format for =20
BibDesk's help, I'd probably conveniently forget to ever add to it.

--=20
Adam=