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

Re: Improving XML desing?


desing

Peter Hunsberger said:
> On 5/10/06, juanrgonzaleza@c...
> <juanrgonzaleza@c...> wrote:
>> Michael Kay said:
>> >> My interest in this list is for discussing if some of ideas
>> >> developed from the CanonML program can be implemented in a
>> >> future XML specification.
>> >>
>> >> I am not interested in debate about weakness or strengths of
>> >> the CanonML approach here.
>> >
>
> Most people here don't have time to try and guess what you want to talk
> about.

Then i wait can be understood i have not time for replying some irrelevant
messages and questions.

> If you post something to a mailing list the entire
> contents of the post become fair game for people to discuss.  They are
> not going to play by some arbitrary rules you try and impose after the
> fact.
>
>> > How can you discuss whether the ideas are suitable for incorporation
>> into XML without discussing the strengths and weaknesses of the
>> ideas?
>> >
>> > Michael Kay
>> > http://www.saxonica.com/
>>
>> "[...] for discussing if some of ideas developed from
>> the CanonML program [...]"
>>
>> is not equal to
>>
>> "[...] debate about weakness or strengths of the CanonML
>> approach [...]"
>>
>> First belong to *ideas/philosophies* about markup languages and data
>> storage. Second belong to specific *implementation* of a particular
>> language.
>>
>> For example, a general idea is one can mark either tags or the text.
>> If you choose mark tags (which is ideal for documents) you can
>> implement (this general idea) in different ways (TeX, XML, or liminal
>> implementations):
>>
>> \em{XML can be improved}
>>
>> <em> XML can be improved </em>
>>
>> [em}XML can be improved{em]
>>
>> Discussions about my specific usage of double colons or the special
>> notation for empty tags or if i use "]" instead of ")", belong to
>> criticism to the specific CanonML proposal and I will not discuss it
>> here. If anyone is interested that could be debated in Canonical
>> Science Today.
>>
>> However, questions as "XML has model for metadata, but has not model
>> for metametadata, we could implement this similar to,
>>
>> <tag a={b='metadata'}="metadata">Data<tag>"
>>
>> would be of interest (and i am interested) here.
>>
>
> So in other words you want us to focus on the ideas you have and not the
> implementation? If that's the case, you should separate the two them
> before presenting them to us.  If you want no discussion of the details
> of  the "CanonML" implementation then I'd suggest you start over with a
> new post to this list that does not even mention CanonML.  Instead ask
> only about the _ideas_ you want to discuss, for example, whether there
> is any need for including some kind of 2nd level
> metadata representation within XML.
>
> IMO, the answer to this particular question is no.

This sound "no" may kill any debate. I just wonder that others do not
agree; e.g. Jeni Tennison.

> Metadata can be
> applied recursively easily enough and the existing XML mechanisms of id
> and idref already serve to allow arbitrary graph structures
> relating multiple levels of representation (metadata, metametadata,
> metametametadata,....) without the need for some new syntax that
> imposes new levels of incompatible parsing complexity.  IE:
>
>     <foo id="123">Data</foo>
>
>     <bar idref="123">metadata</bar>

Difficult to see that "easiness" in the model you typed. This may be dut
to my lack of skill. Still the situation is poor, because i do not
understand why liminal, for example, ignores the way you propose.

Moreover, i find amazing that when minimal-simple XML was proposed, many
folks rejected the absence of attribute model for metadata. For instance,
Tim Bray wrote about metadata

<blockquote>
XML Has Both Elements and Attributes, Why? · When I first learned about
SGML, XML's predecessor (this would be in 1987) I had the same reaction,
and single-handedly coerced the markup of the Oxford English Dictionary
online text into an attribute-free style that lasted some years.

Today I observe empirically that people who write markup languages like
having elements and attributes, and I feel nervous about telling people
what they should and shouldn't like. Also, I have one argument by example
that I think is incredibly powerful, a show-stopper:

<a href="http://www.w3.org/">the W3C</a>

This just seems like an elegantly simple and expressive way to encode an
anchored one-way hyperlink, and I would resent any syntax that forced me
to write it differently.
</blockquote>

Maybe he is unaware of your proposal

 <a id="123">the W3C</a>

 <href idref="123">http://www.w3.org/</href>

This class of double attitude one often find in the XML community is
really perplexing. Is this politics or some kind of non-standard logic is
thougt in academia and i unknow?

> (or vice-versa if you have some precise syntax in mind that you want to
> argue instead of semantics,  this time around...)
>
> --
> Peter Hunsberger


Juan R.

Center for CANONICAL |SCIENCE)




PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.