[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Generic XML Tag Closer </> (GXTC)

• From: Melvin Chin <mc@xxxxxxxxxxxxxx>
• To: XML-Dev <xml-dev@xxxxxxxxxxxxx>
• Date: Wed, 30 Aug 2006 10:41:56 +0800

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


At 07:36 AM 2006-08-30 +1000, Rick Marshall wrote:
>One of things most engineers learn very early in their training is that 
>the text book examples are just that - text book examples.
>
>The real world has a way of interfering with theory - loose wires, 
>components on the edge of their tolerances, inductance in wires etc. 
>(civil and mechanical engineers must have their own list).
>
>So...
>
>When we talk about readability can we start using examples where the ratio 
>of data to tag bytes is say 100:1 rather than 1:4 or worse.
>
>Embed your tags in a single line that is 10k long or put your terminators 
>in the middle of a line 20 lines from where the opening tag occurred and 
>then discuss readability.
>
>Because 20 or 30 bytes is irrelevant on all counts in this discussion - I 
>don't care if I type 15 bytes or 20 bytes. I do care if I spend 2 hours 
>looking for a missing end tag.
>
>Rick
>
>
>Philippe Poulard wrote:
>>Melvin Chin wrote:
>>>May I seek some opinions on this topic/proposal?
>>>
>>>===================================================================
>>>To extend XML spec just a little to permit use of "</>" (GXTC)
>>>to be placed wherever it is permitted in the current XML spec
>>>to place a closing tag.  The semantics will be to effect a
>>>closing of the nearest open tag before the position of GXTC.
>>>===================================================================
>>>
>>>Any opinion is fine, useful, crazy, nonsense, should be done,
>>>must not coz it's going to break many things ...
>>>
>>>I could see some good use of it, but do note the deep potential
>>>impact it may bring.  Would like to hear from you.
>>>
>>>Thanks.
>>>
>>>cheers,
>>>mc
>>
>>my 1? :
>>
>><a>b<c>d<e>f</e></c></a>
>><a>b<c>d<e>f</></></>
>><a>b<c>d<e>f</3>
>>a little more shorter !
>>we could also reduce to <3> but it really looks like an open tag
>><a>b<c>d<e>f<3>
>
>
>

• Follow-Ups:
  • Re: Generic XML Tag Closer </> (GXTC)
    • From: juanrgonzaleza

• References:
  • Re: Generic XML Tag Closer </> (GXTC)
    • From: Philippe Poulard
  • Re: Generic XML Tag Closer </> (GXTC)
    • From: Rick Marshall