Hi Claudio,

> the thing is: even if (for example) edge weights are supported in ALL the
> file formats of the world (which is quite plausible), the actual attribute
> will likely be called in different ways for each format: "weight", "w",
> "value" or whatever. So even a unified implementation in AbstractExporter
> should still rely on concrete implementations to discover the name of the
> attribute (see e.g. the static fields DotExporter.WEIGHT and
> DotExporter.LABEL).

OK!

> But it's still fine for me to keep at least the abstract
> common denominator.

OK sounds a reasonable compromise!

>
> Another issue I'm facing: some of the output formats depend on the actual
> type of the printed value. For example in the DOT format, Strings
> (especially those with whitespaces) should be double-quoted while numbers
> (doubles) should not, e.g.:
>
>  * 192 [label="hello world" weight=3.4]
>
> So we should also seek a unified way to keep track of attribute types when
> serializing them, so that each exporter can choose the appropriate output
> format for each of them. I saw the
> "enlistVerticesProperty"/"enlistEdgesProperty" methods in the code, are they
> supposed to help on this matter?
>

I honestly started prototyping that method because of the need of
GraphML of enlisting all properties first :S Can't you discover the
propert type simply by checking the returned object class?

Thanks for taking care of it!
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Reply via email to