Re: [xml-dev] hackable xml

[Amelia A Lewis <amyzing@talsever.com>]

On Mon, 26 Jul 2010 12:08:24 +0100, Andrew Welch wrote:
> 2. Entity refs no longer exist, other than the inbuilt ones.  There is
> no DTD.  (numeric refs remain)

If the inbuilt ones exist, why:
> 5. Lone inbuilt entites such as "&" in the lexical XML are
> automatically parsed as & and not an error (#2 above might enable
> this). Same goes for a lone "<".

And what does 'lone "<"' mean, anyway?  <element name="example">if (A < 
B) && (B > C) {...}</element

Abandoning well-formedness in the name of simplicity is almost 
certainly the wrong approach to take.

Without CDATA and entities, how do I supply an example of this syntax 
in the syntax?  <![CDATA[Encode & as &amp;]] and < as &lt;> [xml 
variant 1] == "Encode &amp; as &amp;amp; and &lt; as &amp;lt;" [xml 
variant 2] == "Encode & as &amp;amp; and < as &amp;lt;" [consequence of 
making & == &amp; in this definition?]

That's not simpler, that's more complex, and in theory more forgiving 
of "common errors".

> 3. PIs, CDATA sections gone

No stylesheets.

> 4. Encoding must be UTF-8 (or some similar rule: its to remove the
> potential mismatch between the encoding in the prolog and the actual
> encoding)

"   "

Oh, hell, let's just make 'em all use ASCII, why not?

> been involved with.  I have never, ever, seen 2 prefixes with
> different namespaces in the same document.  There is no need to map a

Heh.  I have, often enough.

> prefix to a namespace, the prefix provides all the uniqueness
> necessary within a domain, global uniqueness isn't needed.  This would

?  So, how big is the domain?

> to make it "hackable" by the masses, keeping mixed content and
> attributes, the reason why you would use xml in the first place.

Is it?

> The need is there - is there a reason why this can't be done?

Based on the above, I don't think you're going to build momentum.  What 
you want and what I want, for instance, seem to be rather different 
(I'd like to see a less baroque "namespaces in XML", and XML entity 
definition without DTDs; abandoning well-formedness constraints strikes 
me as a bad idea introducing too much ambiguity; removing choice of 
encoding is equally wrong-headed, I believe, and making XPath simpler 
won't help if the common host languages for XPath are no longer 
referenceable via standard mechanisms such as a stylesheet PI).

Amy!
-- 
Amelia A. Lewis                    amyzing {at} talsever.com
Do you ever feel like putting your fist through a window just so you
can feel something?