Re: [xml-dev] Generic XML Tag Closer </> (GXTC)

[<juanrgonzaleza@xxxxxxxxxxxxxxxxxxxx>]

David Carlisle said:
>
>> and that MathML defined a special fine-parallel markup
>> via id-href
> Linking between xml elements using using xlink is hardly an example of
> non-xml use.

No was i said! I simply pointed that the size often matters.

>
>> _because_ original parallel markup become non-manageable in
>> size for minimal realistic documents.
>
> But that has nothing to do with xml verbosity or tag minimisation (which
> would only give linear savings)  if you don't use the "parallel" markup
> and instead just give the complete presentation and content mathml
> version of each formula, then, if you do that all the way down the
> subexpression tree you get exponential increase in encoding size,
> whatever markup you use.

As explained above the point was that size matters and that common mantra
XML compresses well is not all one needs. The point is that often xml
folks minimize the importance of extra sizing becoming from XML
approaches.

And of course, using any other kind of parallel markup in a MathML
approach the result is oversized even 15 time more than using alternative
(non-XML approaches).

>
>> I just fail to understand how at the one hand one can claim that
>> redundancy and extra verbosity of XML is a non-issue whereas at the
>> other hand own XML folks promote non-XML alternatives.
> verbosity isn't an issue in XML

Except when SVG people says contrary and launch the SVG paths

Except when XSLT people says the contrary. If i remember correctly in

[http://www.amazon.com/gp/product/1861005946/102-1388618-0391318?v=glance&n=283155]

is said that beyond certain ratio for content/markup, XML is not a the
way, and then illustrated tecnhiques for extracting data from strings. If
i remember correctly using spaces as separators for data items. Someone
with a copy of the book could verify this point?

> (so </> doesn't gain you much)

In XHTML

<p>Trickster has never been restricted to one society. In European
countries he appears in the guise of Jester or Fool, and his roots in the
human psyche are deep. Alan Garner has collected Trickster stories from
many countries in his book The Guizer and he writes:<p>

maybe, in XQueryX

<xqx:firstOperand>
 <xqx:equalOp>
  <xqx:firstOperand>
   <xqx:pathExpr>
    <xqx:stepExpr>
     <xqx:filterExpr>
      <xqx:varRef>
       <xqx:name>b</xqx:name>
      </xqx:varRef>
     </xqx:filterExpr>
    </xqx:stepExpr>
    <xqx:stepExpr>
     <xqx:xpathAxis>child</xqx:xpathAxis>
     <xqx:nameTest>publisher</xqx:nameTest>
    </xqx:stepExpr>
   </xqx:pathExpr>
  </xqx:firstOperand>
  <xqx:secondOperand>
   <xqx:stringConstantExpr>
    <xqx:value>Addison-Wesley</xqx:value>
   </xqx:stringConstantExpr>
  </xqx:secondOperand>
 </xqx:equalOp>
</xqx:firstOperand>

i think that </> saves a lot of

>> About editing XML via special editors. If this is a satisfactory
>> solution, why so many special non-XML syntaxes in the market? XUL is
>> promoting alternative syntaxes, now MathML 3 WG will work in an
>> alternative non-XML syntax for wikis and blogs...
>
> alternative linear syntaxes serve the same function for people using
> text editors (or simple text boxes on a web page) as keyboard shortcuts
> in GUI editors: they provide a way to enter the stuff with a minimum
> amount of effort.

... and reason that special XML editor is not the panacea how pointed here.

> A wiki may allow you to type ThisLink to generate <a
> href="ThisLink.html">ThisLink</a> but it's the (x)html that's served and
> which is important, not the particular wiki syntax used in authoring.
> The same would be true of an enhanced wiki syntax that allowed you to
> type 1+2 and have it generate <mn>1</mn><mo>+</mo><mn>2</mn>

But 1+2 will generate problems due that you are splitting input syntax
from internal data representation as i explained you in the mathml list
that is reason that any infix notation for prefix LISP failed.

Instead using aN ultraverbose XML representation + lightweight input
Tex-like syntax, it would be more simple simplify the final XML
representation

<mn>1</><mo>+</><mn>2</>

is already more lightweight. Something like

<n>1</><o>+</><n>2</>

is more simple (this can be transformed via XSLT)

Of course real improvement becomes from abandoning the XML world by some
optimized data format, i like S-expr derivatives.

> David


Juan R.

Center for CANONICAL |SCIENCE)