Neil Watkiss wrote:
> Some nits:
>
> 4.3.5
> http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd$^html
> is a 404. Did you mean '#', not '$'?
Nope. This warrants some explanation...
This is an example of how XML namespaces may be used iif one desires to
"translate" XML to YAML. Exactly how such a feat may be accomplished isn't
quite trivial and deserves a paper of its own.
I can wish we _could_ use '#' - that would be very clean. However, it seems
the XML namespace spec wasn't very clearly worded on the URI point (the
namespace spec is full of hidden mines), and therefore some people read it
as allowing a 'fragment' - scheme:something#fragment - to be a namespace
URI.
Regardless of my personal opinion of such people (and the XML namespace spec
in general), when we define a method of using XML namespaces we are forced
to take them into account. Using namespace$tag solves the problem, since '$'
is allowed both in a URI and in a fragment identifier, and it is not valid
in an XML tag name. Since the tag name will *always* be there (in a YAML
document, the type family is the combination of the XML namespace _and_ the
XML tag name), there's no ambiguity - anything from the last '$' to the end
of the type family URI is the XML tag name.
If you point out that this means we've just defined URIs in domains we have
no claim to (e.g., http://www.w3c.org), you'd be right. It is just we don't see a
good alternative.
As for the resulting URI not pointing to anything, well, URIs don't *locate*
things, they *identify* them (that's why they are called URIs and not URLs).
The distinction is subtle and again a cause for much confusing in XML
namespaces. In YAML the definition is clear - the type family URI is a URI,
period.
We have considered defining a new URI scheme for type families: something
like yaml:perl/Foo::Bar. This would have driven the above point home -
nobody would have typed _that_ into a browser. However, we gave it up as too
complex (registering a new top-level URI isn't that easy). Besides, it
wouldn't have solved the XML namespaces problem, because these are already
URLs... We'll just have to put this in the FAQ, I'm afraid - with a pointer
to the yet-to-be-written "Converting between XML and YAML" document.
> Actually, that's all I can spot right now. It looks really very good!
I'm just reviewing the spc myself and I found a few nits. Specifically,
production 46 should be:
comment_line_break ::= ( line_space+
throwaway_comment? ) ?
any_line_break
And not as written. There may be other little traps like this in the
productions... I did refactor them mercilessly (especially the nodes
productions). Time will tell.
The wording can also be improved at places (minor stuff). For example,
format and style are the only non-native-model elements that are not
explicitly mentioned as such (the text for aliases, comments and directives
contains an explicit warning about this).
There are probably other such small issues. The examples in the syntax
section probably need work. And so on.
> [Of course, this is just nits in the _spec_. I haven't worked through
> the structural changes themselves.]
Right. I hope the spec accurately reflects the consensus we reached in the
last debate, and I agree that first priority is to agree that it does. If we
agree on that we can announce it as a "release candidate" and happily polish
it to within an inch of its life so it would become a worthy "released
spec". I know Clark is itching to work on the first set of examples, for
example...
Have fun,
Oren Ben-Kiki
|