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

[Rick Marshall <rjm@zenucom.com>]

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.

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 */

;)

rick

juanrgonzaleza@canonicalscience.com wrote:

>Rick Jelliffe said:
>  
>
>>I think Juan needs to look at goal # 10 for XML "Terseness is of minimal
>> importance"
>>    
>>
>
>I think that would be "Terseness is of minimal importance but when is not"
>
>  
>
>>and also the goal that there should be as few optional features as
>>possible.
>>    
>>
>
>Well, i think that XML is very contrary to that goal.
>
>- elements vs attributes
>
>- DTD vs Schema vs other
>
>- <tag></tag> vs. </tag>
>
>- Multiple sintaxes for authoring
>
>- DTD entities vs, PI entities, vs. Schema entities vs...
>
>- XSL-FO vs CSS.
>
>- HTML link vs. Xlinx vs. Hlink
>
>- Etc.
>
>Option for </> is of "minimal importance" in this landscape of options.
>
>  
>
>>SGML still exists (and is widely used in some traditional sectors
>>(despite the hype)) and
>>he can use that to get </>.
>>    
>>
>
>And is suitable for the web?
>
>  
>
>>XML was not created to be a perfect language
>> that would suit everyone.  It was designed to be SGML deliverable over
>>the web. Of course if you have different goals you will generate a
>>different language.
>>    
>>
>
>Therefore the X of XML does not mean eXtensible to suit user needs. When
>XML was designed first time, people decided what would be in and what
>would be out. I see no problem with review this again with an eye in
>future XML.
>
>  
>
>>But its value comes from its being a standard.
>>    
>>
>
>Success in this world becomes from a sum of three main contributions:
>
>1) technical points
>
>2) Standarization
>
>3) Marketing
>
>XML benefits from the three. 2) without 1) is not succesful in the long
>run and i think that XML is succesful, not in the original goal of "SGML
>for the web" but like generic data format.
>
>  
>
>>Juan is correct that allowing </> has little effect on the complexity of
>> a parser, just as
>>allowing comments, PIs, CDATA, different literal delimiters, numeric
>>character references,
>>the built-in character references, and empty tags don't require much to
>>support. Compared to the complexity of supporting DTDs, entities,
>>multiple character sets. But what about
>>short-tags on start tags, attribute name omission, and tag-ommission? A
>>line has to be drawn somewhere, and the argument against </> isnt
>>complexity but readability. The fact that LMNL supports something says
>>exactly nothing about what XML should support.
>>    
>>
>
>Sure! but one can extend that argument and the fact that XML 1 does not
>support something says exactly nothing about what a XML 2 should support.
>
>  
>
>>As an example of an XML-size language that relaxes a lot of XML's rules
>>and accepts more of SGML, see  ECS (Editor's Concrete Syntax) which is
>>what Topologi's markup editor uses for SGML  editing.
>>  http://www.topologi.com/resources/pdfs/ECS.pdf
>>
>>It accepts </> as well, and can be quite easily converted to XML. I am
>>sure other people have similar little languages (though perhaps not
>>grounded properly in the standard like ECS is.)
>>    
>>
>
>Thanks by the link but if i understood original message opening this
>thread the point was to add extra funcionality to available XML. Since i
>know a bit the (political?) difficulties to do that i has suggested
>ConciseXML because has funcionality of XML and add extra stuff can be
>_vital_ to some.
>
>  
>
>>Cheers
>>Rick Jelliffe
>>
>>    
>>
>
>Juan R.
>
>Center for CANONICAL |SCIENCE)
>
>
>
>!DSPAM:44ed5e1a294179734571689!
>
>  
>