Re: [toolbox] Extended Attributes

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

Le 3 juil. 05, =E0 02:16, Will Robertson a =E9crit :

> On 3 Jul 2005, at 7:15 AM, Maarten Sneep wrote:
>> And for metadata:
>>
>> % \iffalse
>> %<*metadata>
>> %! pragma mark My marker.
>> %</metadata>
>> % \fi
>>
>> Is this a workable suggestion? Since dtx files are processed at=20
>> different levels, I think you get more room to play with and add your=20=

>> own stuff. On the other hand, Most dtx files are also pure ASCII, so=20=

>> the encoding is less important, and sectioning is already rather=20
>> clearly indicated (making markers less of an issue).
>
> Well, personally I think that
>    %! pragma mark
> is very ugly, but as a technique to mark dtx files I think you're=20
> right that it works well. (Note also that fontspec.dtx is a unicode=20
> document for example.)
>
> A mark that might be useful for editing DTX files might be
>    %! TODO:
> I don't think there's any point in surrounding the metadata with
>   %<*metadata>
> tags unless that information needs to be extracted from the dtx at=20
> some stage. And I can't really see why that would be...
>
> (On a previous note:)
>
> I honestly have no problem, for now, with implementing metadata in the=20=

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

For example, if you put the master file name of a tex source file at=20
the end of the source file (liek emacs does), it will be hard coded in=20=

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

concerned... Not very efficient.
So you need to embed only a reference to the location where the master=20=

information is stored, such that the reference never changes, but the=20
information it points to can. That way, you just have to change the=20
master name in one location, and all the slave files will be linked to=20=

that info automatically. This is some kind of aliasing. The best policy=20=

is to put nothing in the source file.

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

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

for tex comments). For more general metadata, some frontends might want=20=

to store pure binary metadata... But if the metadata are embedded,=20
those things will be forbidden.

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

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

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

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

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

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.
Moreover, in a very near future, it will not be strange to use an XML=20
input instead of the standard tex input.
If we want to store the same metadata in the source file, we will have=20=

to design another mean for that purpose.
If the same metadata were saved in an external location, the format of=20=

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

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.