Robert in his original mail:
> Does anyone have an opinion on usage of an RDF/XML spec for describing the
> description of content that can be imported or exported into Plucker?
Right
Robert in his last reply:
> > Amen. An entire tree in memory would bring this laptop of
> > mine to its knees. While some of the DOM parsers certainly some have
> > nice features, can't beat expat on the performance end.
But, aren't we talking about describing how and what should be gathered and
not trying to build a big XML document of the gathered HTML? For normal
"desktop" use in Plucker Desktop this configuration/channels file can't be
so big?
Expat might be the logical choise as it is already in the Plucker Desktop.
David might need another tool if he chooses to convert his database of
Pluckable
links to this channel format...
> We should be consistant across parser commandline elements, .ini
> key/value pairs, ~/.pluckerrc keys, and the XML attributes.
> Let's flatten
> this so we don't have to re-learn it for each file we deal
> with and each
> platform it runs on. Eventually, standardizing on one file
> format, with the
> ability to export to another, is ideal.
Converting from XML to other file formats (can be another XML format) is
easy and that is what XSLT was invented for...
> What is the "usual format"? We are defining our own.
> Who cares what they think is "normal" or not. Underscores makes sense, and
> are used in _most_ places, except C++ and Java, in most cases. K&R and
> BSD style coding guidelines recommend them. Then again.. this isn't C, nor
is it HTML.
I think <thisIsNormal/>? I personally like <this-better/> as in XSLT nodes.
But I have also <seen_this/> so maybe everything/nothing is normal? Making
it look
normal is good if we excpect "other people" to read it. I think it is more
important
to keep the attributes and values named in the same way, using another word
separator
is more a question about context. (I mean that "some_attribute" and
"someAttribute" are the same but in different contexts. One in an ini-file
and the other in an XML-document).
Ok, maybe all values should follow the same naming scheme regardles of in
what file
they are...
> > Others decide on a format to set standard, Plucker format is
> > non-compliant. Or worse, 15 different standards, none compatible,
> > everyone has to write waste time making an import and
> export for every
> > format (which is the way it is now).
A standard is good, but the Plucker format should concentrate on beeing good
for
Plucker. It is better to write an export/import than having to work with a
"stupid
standard" in the parsers.
> > Hmmm. Never saw that before in any spec, but things are
> always changing
> > and I may well have missed it completely in the texts. Do
> you have a ref
> > handy by any chance?
I believe '//' and '/' are allowed inside attribute values.
<xsl:apply-templates select="//some-node"/>
Selects all the <some-node/> nodes and applies XSLT templates on them in an
XSLT transformation.
> XML is meant to be human-readable, but doesn't have to fit in an
> 80-column witdth, and as you know.. you could use the following:
>
> <images bpp="8"
> alt_maxwidth="200"
> alt_maxheight="300"
> maxwidth="100"
> maxheight="100"
> other_opt="foo"
> and_this="bar"
>
> </images>
Looks good to me. Something along the lines of keeping the attributes of one
"object" as the node attributes. This makes it more human-readable with with
the "images" object as a child of the "channel" object. It becomes more
tricky
when there are lists. From Roberts example:
<output_options>
<backup_bit>1</backup_bit>
<launchable_bit>0</launchable_bit>
<no_url_info>1</no_url_info>
<categories>
<category>News</category>
<category>Linux</category>
</categories>
<compression>zlib</compression>
<launcher:show_icon>1</launcher:show_icon>
<launcher:large_icon_file>big.bpp</launcher:large_icon_file>
<launcher:small_icon_file>small.bpp</launcher:small_icon_file>
</output_options>
With multiple categories they can't simply be added as attributes to the
<output_options/> node.
Using namespaces is a good thing if we want compatibility between different
formats and easy conversions from one format to another. Using nice aliases
is good for readability as long as everybody remebers that it is just a
shorthand for the namespace...
> It's useful for self-closing elements, like <br> and so on, but for
> things like multi-line constructs, as above, it makes sense to repeat the
> closing tag in full, since it could be 10 lines away, or nested inside
> another tag. It's easier to figure out which tags are where
> when they each have a full close tag, and not a self-closing one.
<some-node></some-node> and <some-node/> are exactly the same things and
are not necessary preserved in the form they were read in when the document
is saved.
Would it be possible for the parser to use UTF-16 internally when handling
the document? This would probably make it easier to support different
codepages (Japaneese etc.). Europeans might want to use ISO-8859-1 and
Americans might get away without specifying an encoding at all.
Including "binary" data in an XML document is not a problem as long as the
encoding allowes it. The binary characters are easily escaped. But
readability
suffers and somebody might break an icon by modifying the data by mistake.
I hope nobody objects to me taking part in the discussion!
-Jonte
--
[EMAIL PROTECTED]
