[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
Re: [xml-dev] Generic XML Tag Closer </> (GXTC)
- From: Rick Marshall <rjm@xxxxxxxxxxx>
- To: juanrgonzaleza@xxxxxxxxxxxxxxxxxxxx
- Date: Sat, 26 Aug 2006 10:36:42 +1000
juanrgonzaleza@canonicalscience.com wrote:
>Rick Marshall said:
>
>
>>my 5c
>>
>></> is a syntax element and as long as something else understands the
>>semantics - it will do fine
>>
>>however...
>>
>></tag> is semantic which means the parser/processor does not need
>>external information to make a descision about the correctness and
>>completeness of the information.
>>
>>
>
><tag1>content1<tag2>content2</tag2></tag1>
>
>Once parsed <tag1> and <tag2> the parser finds the "</" and *wait* a
>"tag2" because consistency of the XML. The same when finds the </tag1>.
>
><tag1>content1<tag2>content2</></>
>
>Once parsed <tag1> and <tag2> the parser finds the "</" and knows/assumes
>is closing the open tag2 because consistency of XML. The same when finds
>the last </>.
>
>
assuming is not the same as knowing.
i mean lets have some real fun - like in html and allow </> to close off
all unclosed tags. saves a few more keystrokes.
<tag1>...<tag2>...</>
now that's even more compact and it's sort of what html does - but we
all know how often it gets it wrong.
you see the problem is that when the parser comes across </> it has to
ASSUME that it is closing the last declared tag. however if you
accidentally left out a close tag then it's wrong and it will take
counting opening and closing tags right to the end of the document to
know that the document is valid.
bye bye sax
rick
>No external information is needed. Differences:
>
>- With </tag-name> the closing is pre-defined in the doc. With </> it is
>*not* predefined, in the sense that the tag always closes the latter empty
>tag.
>
>- Therefore, we return to begin of this thread. In certain dinamical docs
>the value of the end tag cannot be known _a priori_ and </tag-name> is of
>no utility here. Therefore the need for the option </>.
>
>- Sometimes the end tag of XML can be of help when parsing erroneous docs.
>
>Therefore sometimes </end-tag> can be better than </>; sometimes </> can
>be better than </end-tag>.
>
>
>
>>For those who remember the programming language discussions of 20+ years
>> ago (and today?) this issue must have a strong feeling of deja vu.
>>
>>eg
>>
>>function X {.....} /* end of X */
>>
>>
>
>Today also! In fact there is still debate specially between people
>developing new PLs on what is better option LISP/C syntaxes or Pascal
>like.
>
>The inmmense popularity of C syntax
>
>function X {.....}
>
>or LISP one
>
>(function X .....)
>
>over Pascal like blocks
>
>begin function X ..... end function
>
>offers an idea on why </> is being promoted for PL applications.
>
>Your explicit quoting of comments at end of function is very interesting
>because it is the common reply to the human readability of XML end tags
>becoming from LISP/Scheme community. I also agree that something like
>
>[::section
>..."300 pages of code here"...
>#end section of line 24]
>
>is more readable than
>
><section>
>..."300 pages of code here"...
></section>
>
>About verbosity, this
>
><temperature>300</>
>
>is less verbose than
>
><temperature>300</temperature>
>
>in a large factor. Imagine a large sample from laboratory
>
>
>
>>;)
>>
>>rick
>>
>>
>>
>
>P.S. CSS does not use end tags H2 {...}
>
>
>Juan R.
>
>Center for CANONICAL |SCIENCE)
>
>
>
>
>!DSPAM:44eed359206911016417754!
>
>
>
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]