Re: [toolbox] Extended Attributes

[<jer...@u-...>]

Le 5 juil. 05, =E0 22:39, Maarten Sneep a =E9crit :

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

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

emacs, or at leaset auctex also uses an external diretory named Auto=20
where it stores meta data.
The name Auto can be changed with an iinline comment.

>
>> For example, if you put the master file name of a tex source file at=20=

>> the end of the source file (like emacs does), it will be hard coded=20=

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

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

Gerben just gave me an example where he splitted a big book in several=20=

chapters, each one could be typeset separately.
Changing the master name allows this. If each chapter consists of one=20
file, you just change the master file name in the header, but if it=20
consists of many different files, then this is not practical.

>
>> So you need to embed only a reference to the location where the=20
>> master information is stored, such that the reference never changes,=20=

>> but the information it points to can. That way, you just have to=20
>> change the master name in one location, and all the slave files will=20=

>> be linked to that info automatically. This is some kind of aliasing.=20=

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

> random tex file - that turns out to be some slave file.

Assuming that master files are property identified (with the name,=20
\documentclass, inline comment), slave files are the ones below.

>
>> Another big problem concerning metadata in the source deals with the=20=

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

Omega, maybe some day...

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

Exactly. This is why I chose a property list for iTM.

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

>>> of an issue -- it can always be changed if a new method turns out to=20=

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

>> file, like resource forks and the TeX Wrapper Structure I presented=20=

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

>> they had a structural reason that prohibits an intense use of this=20
>> 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 own=20=

> sessions: window locations come to mind (especially if you have a 12"=20=

> powerbook, and the colleague has a 30" display). I think you are too=20=

> quick in discounting the private option for (some types) of metadata.

In the TeX Wrapper Structure I presented in EuroTeX 2005, there are=20
dedicated room for frontend specific and user specific metadata.
For frontend specific metadata, it's just a naming convention to avoid=20=

collisions, such that quite nothing needs to be changed for actual=20
editors.

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

>> informations that really need to be stored inside the source.
>
> With the marks I agree, with the collapsing region bounds, I'm not too=20=

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

marks are also personnal, they can just be used as stickies.

>
>> Moreover, in a very near future, it will not be strange to use an XML=20=

>> 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 now we can store the text=20
> encoding in the file itself, and for XML there are official options,=20=

> 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 files,=20=

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

Exactly, different locations for the metadata serve different purposes=20=

and we definitely need both.

>
>> Finally 1 -and- 2 are the only choice. Now, the problem is to define=20=

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

> the really interesting question is what should be stored.

Yes, but this is private to frontends and is not shared, so nothing to=20=

discuss.

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

Agreed except for 3.
All these are recommandations, and the frontends will do what they=20
prefer.
But my opinion is the following:
If a frontend wants to implement something, he can do whatever he=20
wants, but there might be dedicated locations for that.
Every metadata can be stored in either 1, 2 and 3.

For the window location, we can state that:
if the front end wants to store it in its private domain, he can do=20
whatever he wants.
If the front end wants to store it near the file it refers to, then=20
there is some place already reserved for this, and it should use it.
The frontend is not encouradge to embed this kind of information in the=20=

file.

The=20=