[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
Re: [xml-dev] Generic XML Tag Closer </> (GXTC)
- From: <juanrgonzaleza@xxxxxxxxxxxxxxxxxxxx>
- To: <xml-dev@xxxxxxxxxxxxx>
- Date: Tue, 29 Aug 2006 03:56:23 -0700 (PDT)
Rick Jelliffe said:
> juanrgonzaleza@canonicalscience.com wrote:
>> Rick Jelliffe said:
>>
>>> 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.
The original query was to introduce </> as generic closer. I pointed out
that in ConciseXML –an extension of XML- you can write this
<title>XML is great</title>
OR this
<title>XML is great</>
and your reply was that the goal was that there would be as few optional
features as in XML. However, is that a limitation today to generalize XML?
>> - elements vs attributes
>>
> Elements and attributes are not optional in XML 1.0. You are confusing
> optionality with
> syntactic sugar.
Sure are not optional but if you do an effort to understand i wrote you
can see that the </title> vs. </> encoding is the same that options
<book>
<title>XML is great</title>
<author>XMLover</author>
</book>
OR
<book title ="XML is great">
<author>XMLover</author>
</book>
any author of XML finds during design phase. I said not that attributes
are optional i said that often you have two options to encode data,
somewhat as you have two options for final tag in ConciseXML
>> - DTD vs Schema vs other
>>
> Schemas are not part of XML 1.0
Sure, but again the same. You can validate your XML via DTD OR Schema (OR
any other way). Again authors may manage options and tools would be able
to exploit both validations.
>> - <tag></tag> vs. </tag>
>>
> Support for these is not optional in XML 1.0
Again the same. Authors can encode
<book title ="XML is great"></book>
OR
<book title ="XML is great"/>
>> - Multiple sintaxes for authoring
>>
> What does that mean?
What since XML is difficult and verbose to be edited by hand either you
may invent your own input sintax or using some of available. Again i said
not that was an optional feature of XML spec. I said is that it is an
option for authors.
>> - DTD entities vs, PI entities, vs. Schema entities vs...
>>
> Support for parameter entities is optional, in the sense that a
> non-validating parser that finds a
> document with standalone="yes" does not need to process the external
> subset of the prolog.
Same misunderstanding about "optionality" than above.
> There is no such thing as a PI entity (even in SGML). There is no such
> thing as a Schema entity.
From a formal point of view i agree with you, for instance entities are
not defined as entities in Scheme spec but as author I can chose between
using a DTD entity <!ENTITY oacute "ó">
<parrafo>El tren se detuvo en la estación</parrafo>
OR using a PI entity (e.g. XPathscript)
<body>
<% $oacute = ó %>
<parrafo>El tren se detuvo en la estaci<%= $oacute %>n</parrafo>
</body>
OR using a Schema entity <xsd:element name="oacute" type="xsd:token"
fixed="ó"/>
<parrafo>El tren se detuvo en la estaci<oacute/>n</parrafo>
>> - XSL-FO vs CSS.
>>
> These are not part of XML 1.0
Sure but again you fail to see that i mean that you can use CSS OR XSL-FO
for styling. A browser would be able to understand both CSS and XSL-FO
even if i know none XSL-FO capable browser today.
>> - HTML link vs. Xlinx vs. Hlink
>>
> These are not part of XML 1.0
Sure but XHTML is a XML application and when linking you doc you can chose
between <a> of (X)HTML 1.x, the Xlink (via compound doc) OR the new Hlink
of XHTML 2.
Therefore, i summarize my view:
claiming that leaving </> as optional instead the full </final-tag> is
contrary to original goal on XML "should be as few optional features as
possible" is not supported by current usage of XML in real world.
The option to write
<title>XML is great</title>
OR
<title>XML is great</>
adds virtually zero complexity to the current status of XML world (both
for tools and authors) when compared with multiple OR arising in any
minimal XML project.
>>> 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.
>>
> If you go to Wimbledon, it is useless to sit at a court where the match
> has finished and
> demand a rematch to the empty stadium. You have to go to the court where
> a game is
> still being played. In XML's case, the games being played at the moment
> are the fast
> infoset and the XML pipelining work.
Not problem for defining an "extended Winbledon" letting people to use
they want. Concise XML leaves the </> as option but if you do not use any
of the extension opened by ConciseXML then your doc will be exactly
standard XML 1.0. Therefore people who need strict compatibility will use
the subset of ConciseXML compatible with standard XML 1.0 whereas people
needing of the new feature will use them sure.
It is so difficult to learn this?
Of course, XML community can, if they want, to decide that XML 1.0 will be
static for decades with no new features, but do not wait to people who
need new features to remain static...
>> 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.
>>
>>
> How ridiculous.
Hum, no better argument?
> If there is an XML 2, it will be a consolidation of the existing pending
> fiddles that are
> floating so fecklessly about at W3C, in the light of a stronger
> processing model that
> gives some meaning to them: XML 1.1 - DTD + namespaces + xml:base +
> xml:include
> + xml:whatever + processing model.
Sorry i cannot predict future still.
> There will be that XML 1.0, XML 2.0 as above, plus a binary version,
> plus JSON, as the dominant players, AFAIKS.
>
> Cheers
> Rick Jelliffe
Juan R.
Center for CANONICAL |SCIENCE)
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
