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

[<juanrgonzaleza@xxxxxxxxxxxxxxxxxxxx>]

Melvin Chin said:
> All these points are very valid.  And I certainly could agree readily if
> we must all type and edit XML instances all the time.  So readability
> argument for humans wins out here.  Frankly I'm much impressed with many
> points from very different aspects of consideration from where I started
> to ask the question.  I apologise if I had generated heated discussions
> at points when it almost sound like a topic between
> the high-IQs and the lower ones.
>
> Examples where data content far exceeds total tag bytes will tend to
> show that "friction" generated from ending tag names is insignificant.
> However, it is also insignificant, therefore, to reduce the end tag to
> an optional </>.  So this might not be the most convincing argument to
> say </> is not useful, I think and with due respect to other persons'
> postings justifying why it is.  The savings of </> are not just in the
> instance storage (file, network, memory) requirements, but also
> multiplied in the processing algorithms to stack up anticipated names.
> There are also time penalties in terms of matching closing tags.
> Alright,
> counter-argument would be that it's negligible.
>
> Let me share a bit why I ask the question in the first place.  Juan
> pointed out many points for which I must nod my head vigorously in
> agreement.  He justifies it from scientific needs,

Well, ConciseXML and LMNL are two examples of markup leaving the full end
tag optional and both were not designed for specific scientific issues.
ConciseXML is more oriented to industrial programming and LMNL more
oriented to humanities communities -a field where XML appears to be not
very popular-.

> but the question
> which I raised originated more from industrial instruments and
> monitoring, where datums are short, bursty, essential, time-critical and
> due to successful marketing of XML, must be wrapped in XML.  Though
> initial experiments and prototypes managed to bring current XML1.0 into
> the system, timing needed in processing and meeting time-sensitive
> data-generating events are still a primary concern and, in particular,
> would be a critical for future scaling.
>
> Binary mapping and/or compression techniques don't quite work here,
> because from a bit of experiments (not strictly scientifically
> conducted, but quick trials) showed that the product of end-to-end
> processing time with compressed/binary storage size doesn't get
> much reduced.  In other words, roughly it means the more compact
> we manage to compress the bytes, the longer it takes to do both
> compressing the original data and decompressing the compressed
> data.
>
> The best way out is to have XML original representation, while also
> being able to choose an option (defined within XML) so that the
> lexical version is efficient.  I thought the generic tail tag </>
> might be a way out and tried to gather some views from the list.
>
> As Michael Kay and a few other people pointed out, I didn't think
> it would make much difference or sense to have spec changes to
> XML, as it would be scary to others whose very important data has
> just been converted to XML only to hear that that spec itself would be
> changed.  Further, there were good and well-founded justifications from
> original XML founders (Jon Bosak and others) to measure the
> pros and cons on this very issue.
>
> But from various discussions I hear on this thread, I also gather
> a sense that the "X" in XML ought to be extensible in meeting
> new requirements.  If XML becomes successful, which it probably
> already is, then we can expect its use to propagate further
> to other fields for which it might not have originally been
> anticipated.  I'm in no position to guess if it would make sense
> therefore for XML to evolve, but I suppose at least the discussion, even
> if repeated, is making an indication on where XML might next
> e"X"tend.
>
> cheers.

About compression of XML, i read here often that compression works fine.
Maybe in some cases it does.

It is interesting that SVG uses special non-XML syntax because verbosity
and oversize of XML and that MathML defined a special fine-parallel markup
via id-href _because_ original parallel markup become non-manageable in
size for minimal realistic documents.

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.

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...


Juan R.

Center for CANONICAL |SCIENCE)