Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: [SML] Re: SML ?!?
> > See http://www.xml.com/pub/1999/11/sml/index.html for an article
> describing
> > the SML idea and the controversy surrounding it.
>
> I noted with interest (and disagreement) the technical arguments against
> attributes.
>
> If XML is used for representing tree structures or property/value pairs,
> then, yes, attributes can give way to child elements.
>
> But if XML is used for *markup*, attributes make sense and should not be
> replaced by child elements.
> (I have made this point whenever attribute vs element discussions have
> arisen).
What if actualy there is a third way? I mean :
"XML is used for markup, where every 'marked' element is in fact an 'object' "
> Why? Because in *markup* there is a distinction between content and markup.
> The character data content of an element is content. The value of an
> attribute is markup. Attributes, like other markup, provide information in
> addition to the textual content.
I agree - this is very consistent. It is also consistent to say :
"we should have separate address space for code and separate
address space for data even both are just bytes".
I had a chance to write some assembly code for both
architectures ( for the architectures where code should live
separately from the data and for the architectures where
both code and data are considered to be 'the same' ).
I think anybody who had a comparable experience would
agree that 'mixed' approach is *much* more convinient
for the user. Not talking about efficiency, but only what
is less limiting.
> For example, a person thinking how to express the fact that Max is a dog
> that is black might use:
>
> <dog>
> <name>Max</name>
> <colour>black</colour>
> </dog>
>
> However, a person wanting to markup the text "Max" indicating that he is a
> black dog couldn't do the above. They might, instead, use:
>
> <dog colour="black">Max</dog>
What both things do - they are saying that in this place
of the document we actulay have an object Dog with some
properties.
To me - the only advantage of attrubutes-based notation is that
is gives some information about what attribute of that
object is 'more important'. Very misleading thing in general.
It's up to stylesheet to decide *what* is important.
( With <comment> </comment> there is also a way to
give a priorities to comments ;-) Isn't it nice and
consistent, to consider comments to be a part of
XML content ? )
<aside>
With attributes shorthands I see a design pattern here,
very similiar to descision that have been done with
XML / SAX design.
A couple of days ago I enjoyed the result of that "we
know better *what* is XML document so we know that
developer will *not* need the information about ignorable
whitespace outside the root element".... ( not talking about
the comments e t.c. ). Actualy existing SAX/XML point
of view is very contradicting. If comments are of our
interest why ignoreable whitespace outside the root
document is *not* of our interest? Why <?xml header
is not of our interest ? If we are concerned only about the
'meanful content' or 'semantics' - what is the difference
between comments and ignoreable whitespace ???
Both are not the content, right ? ;-)
Not talking about the XML itself, existing XML *framework*
is inconsistent. A bit. But sometimes it hirts.
</aside>
> So if XML is being used for marking up existing textual content, attributes
> have a definite place.
Yes, attributes is a nice shorthand, like many other kludges that
XML has. I think most of kludges come from SGML world, where
people was used to prepare most of the documents manually,
it's why we have <!-- kludge, CDATA kludge, weak macroprocessor
( kludges-based ) and weak ( useless in the real life, when it
comes to ... for example XSL FO ;-) DTD-based validation.
Because XML has different ( wider ) domain area than SGML has,
dropping all those legacy kludges may be reasonable, because
it could bye *much* more simplified and layered *framework* than
it could be done on top of XML.
There is a design pattern in every part of every 'standard'
that is built on top of XML and I think that pattern is a
death end. Of course, it would not die, but from
technical-political standpoint, XML v 2 is just an issue of time
to me. XML is hyped, but it also has a *perfect* concept that
allows you to re-think how your dataflows could be managed
in some 'different' , realy componentized way.
That concept does not equals to XML.
If *not* talking about the political issues, from technical
standpoint SML gives you comparable 'technical' benefits.
If making agreement on SML :
- elements and PCDATA
- no kludges:
use <comment> </comment>
no macroprocessing
no attributes
no weak DTD's
we'l have .... well ... it's
Some mix of elements and PCDATA.
( with maybe <BR/> shorthand. The
only stuff I like... even it causes so many
problems with <BR></BR> .... Maybe
it should be dropped also ).
Maybe it should be also UTF-something
based and there are some questions about
whitespace.
And it is still XML!
Anyway - such SML could be the perfect
level 0 of that hypotetical 'killer' framework.
Most of the existing ( too-bloated-to-fit-into-cell-phone )
layers could be replaced and there could be some
amazing software built on top of it.
XML-based XT would not fit easily into the cell phone
SML-based XT would fit with no problem.
XML-based PDOM on top of SQL could not be
created in a reasonable time.
SML-based PDOM on top of SQL is doable.
Not talking about XT, embeded into any
program, like regular expressions are
e t.c.
I think kludges should die. After 7 years of
perl development ( full of kludges, you know )
I know for sure that it is a death end ( like
PL/1 was )
If the thing is 'not-easy-embeddable' - it's bloated,
It's not a nice ground. I'm not using perl anymore -
only for some temporary hacks. After 7 years ...
It's so hard for me to explain why perl is bad,
because people are returning me the same
words I told them for 7 years ;-) It's
also very hard for me to explain why XML
is not perfect, because for last year I was an
XML evangelist ;-)
As far as I remember from the history of FOP,
at some point you have switched from perl to
Python ( it think it was because there was no
JPython at that point ;-) ).
It was very reasonable step from my point of
view. ;-)
Rgds.Paul.
xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i...
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@i... the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@i... the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
