| - The definition of collection seems unnecesarily obscure. Why wouldn't "set
| of pairs" work (where the "keys" in different pairs must be
Right. We don't need to have it a triplet, it is just a function.
A function can be defined a "set of pairs", but the abstraction
is really a function. Also, getting the defintion of nodeset
out of the way as a byproduct is helpful.
| - I'm uncomfortable with the definition of a scalar. How is a date a scalar?
| Perhaps if you called the propery "value string" or "stringized form" or
| something which would make it clear that the scalar isn't the string itself,
| it just needs to be able to be viewed as one (given a transfer method)?
How about "string representation"
| - Have you verified that the collection similarity works? It seems tricky.
| If collection was "set of pairs" then it seems life would have been easier
| (every pair in each collection has a similar pair in the other; two pairs
| are similar iff both keys and values are).
Right. By changing it to functoin, the wording got
cleaner. I'll incorporate this in tomorow's update.
| - 2.8 (well, 3.8) will need to be re-worked, I think...
| > 1. Trailing whitespace is not significant
| > in folded scalar...
| > (many editors strip it and you cannot
| > see it when it prints) and escaped scalar
| > can use \ to include trailing whitespace.
| Right now it is significant. It is significant in blocks anyway, so you
| aren't really solving the problem. You can always
| choose not to use it (keep it as a leading white space). I think we should
| just add a warning that the use of trailing white space "should" be avoided
| where possible.
| > 2. Can we use $ as a key, specifically for
| > XML node names (for XML conversion)
| I think what you need is a new set of keys - org.yaml.xml transfer method
| with values for a tag, for a "text node", for a processing directive, a
| CDATA section, an entity, etc. I'm not certain we need a key for "tag". One
| can always map an XML tag name to a YAML key:
| <tag attr="value">stuff</tag>
| # Each XML node has an attributes
| # map and a list/scalar "value"
| attr: value
| =: stuff
| The exact set of keys to use is an interesting problem. How about"<!>" for
| processing directive, "<&>" for entity, "<->" for comment, "<C>" for CDATA
| section, and "<>" for text node? Or "<_>" and "<>" for tag if we need it?
| Your HTML example becomes (give or take some white space issues, which one
| could easily dispense with knowing that the default for HTML is folding
| white space):
| # Note XML comments aren't safe throwaways.
| <-> : Sample HTML
| xmlns: http://www.w3.org/1999/xhtml
| title: Generic XML to YAML
| class: mycss
| leftmargin: 10
| <>: This is a converted
| id: http:\\w3.org\TR\XML
| =: XML
| b: fun
| # You get the idea...
| At any rate, I don't want the XML keys to be in the spec. I'd rather not
| even give example or XML <-> YAML mapping in the YAML-CORE spec itself. It
| seems to me to be a whole spec on its own - YAML-XML. It won't be a short
| one, and we *certainly* won't settle it this weekend :-)
| Have fun,
| Oren Ben-Kiki
| Yaml-core mailing list
Clark C. Evans Axista, Inc.
Collaborative Software for Project Management
Patriotisim means protecting core values during difficult times,
not pasting a flag on your SUV and repealing the Bill of Rights.