[SML] Re: SML ?!?

[Paul Tchistopolskii]

> > 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 at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo at ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)