Re: [toolbox] Extended Attributes

[Maarten S. <maa...@xs...>]

On 4 Jul 2005, at 12:23, J=E9r=F4me Laurens wrote:

> Le 3 juil. 05, =E0 02:16, Will Robertson a =E9crit :
>
>> I honestly have no problem, for now, with implementing metadata in =20=

>> the same way as emacs: in a big comment block at the very end of =20
>> the document. It would be easy to hide from the user, and is very =20
>> portable.
>
> Yes, but not all metadata data should fit there.
> And this is can be closed design.

Any design can be closed, but I have a hard time seeing an in-file =20
comment-tag, plain to see for all, and even with documentation - if =20
you pester an emacs adept long enough for it - as a closed design.

> 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 get =20=

the example you give here - since the slave-files are stored in the =20
master file, and their relative location is fixed through the \input =20
statement (or format specific alternatives). So _moving_ the master =20
is not an option, and renaming (IMHO) is a relatively rare action. =20
Inefficiency is unimportant for such cases.

> So you need to embed only a reference to the location where the =20
> master information is stored, such that the reference never =20
> changes, but the information it points to can. That way, you just =20
> have to change the master name in one location, and all the slave =20
> files will be linked to that info automatically. This is some kind =20
> of aliasing. The best policy is to put nothing in the source file.

I don't get this: how is putting the information in another file =20
solving something? The slave files need to reference something, or =20
else: how are you going to pick this reference up when someone opens =20
a random tex file - that turns out to be some slave file.

> 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 are =20=

> 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.

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 it =20
be an xml file - or something else BBEdit can handle.

>> On the other hand, if there are other standards that spring up for =20=

>> storing the encoding of the file in an extended attribute -- well, =20=

>> 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 turns =20=

>> 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 you =20
do not want to inherit from coworkers, while keeping them for your =20
own sessions: window locations come to mind (especially if you have a =20=

12" powerbook, and the colleague has a 30" display). I think you are =20
too quick in discounting the private option for (some types) of =20
metadata.

> 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 file =20=

(in some project file, which can contain the lot in a TeX wrapper - =20
however they may look*).

> 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, but =20
that is a minor remark here. It does mean that at the very least for =20
now we can store the text encoding in the file itself, and for XML =20
there are official options, also in-file.

> 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 too =20
much honour.

> If the same metadata were saved in an external location, the format =20=

> of the storage would not suffer the adoption of xml for input =20
> files, and no extra work would be necessary.

The description of where the different points are inserted - if _all_ =20=

metadata is expelled from the source files to some external storage - =20=

may very well need to change, from a line-count to a node count.

> Finally 1 -and- 2 are the only choice. Now, the problem is to =20
> define what kind of meta information should be stored and where.

I still think there is a place for 3, but you're right in stating =20
that the really interesting question is what should be stored.

loc   description
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
1,2   text encoding   (extended attribute, in-file, project file)
1     markers         (in file - easiest, most robust)
3     window location (private use only)
1,2   master file     (extended attribute, in-file, project file)
. . .

I think we can make the list way longer, and please do so. We'll =20
scratch items from this list later on, and determine precedence =20
preferences (if stored in multiple locations, which one takes =20
precedence in case of conflict?).

Maarten=