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

RE: What is declarative XML? (And what's not)

• From: "Len Bullard" <cbullard@hiwaay.net>
• To: "'Rick Jelliffe'" <rjelliffe@allette.com.au>, <xml-dev@l...>
• Date: Mon, 1 Jun 2009 18:13:21 -0500

The information conveyed is the same.  The apriori reliabilities of the
processors shift feet.

A Warning is a label which in SGML terms was just a name.
A Warning is a name the human reader interprets easily but the program must
be written specifically for the name.

A Div is a signal to the formatting engine to id a box.  It is still just a
name but used by all because despite superstitions, a document is a
formatted object/article/page/blah in most frequent use, the sense of
practice.

The combination enables the user to attach semantics to the name and the
label.  The combination makes the system use more reliable.

Ultimately, it's still just Shannon.  You are fixing probabilities.

That is why Dan Brickley's point is taken because the implication is the
winner trades off machine and human effort but increase order as the means
of making the trade.

But it would be interesting to see an ordering-based cost metric for the
current languages such as RDF vs HTML vs etc.  I think we've discussed it in
the past.

len

-----Original Message-----
From: Rick Jelliffe [mailto:rjelliffe@allette.com.au] 
Sent: Monday, June 01, 2009 1:45 AM
To: 'xml-dev@lists.xml.org'
Subject: Re:  What is declarative XML? (And what's not)

Costello, Roger L. wrote:
> I assert that documents that have no inherent processing semantics have
substantial benefits in terms of reusing them and mining them and mashing
them up.
>   
This is the old SGML idea of taking out *all* processing semantics and 
then having another layer to add them back again. Even if you didn't 
need to.

In the particular case of rich text, this approach has just about lost. 
Consider five ways of marking up a warning section:

 <warning>...

 <warning render="section">...

  <div class="warning">...
 
  <section> ...

  <br />...

It is the middle one that has won, in effect. 

I think the principle is that where there is a mass technology or 
well-accepted public vocabulary which represents the base or default 
semantic (i.e. the semantic which any reasonable use would establish) it 
is better to subclass this. There is also a simplicity principle 
involved too, that you don't strip out what you must immediately add 
again, I think. What is easy to process is an important consideration 
that swings both ways: if the data is textual then subclassing HTML may 
be the simplest to process, but if the data is very rich and structured, 
then marking it up as HTML might increase the difficulty of processing 
it. (Insert GRDDL story here.)

Let look at the case of definition lists. You could reformat them as two 
column tables. But it does no harm to mark them up as lists.

One of the benefits of pure descriptive markup is that, if it is 
complete enough, it prevents the user from having different ways to do 
the same thing: the constraint "Does every address have a postcode?" can 
be checked more easily in pure descriptive markup.  (Though this is 
because grammar-based schema languages are terrible at checking 
"architectural" structures such as those marked up using html:*/@class.)

Cheers
Rick Jelliffe

_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
subscribe: xml-dev-subscribe@lists.xml.org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php

• Follow-Ups:
  • RE: What is declarative XML? (And what's not)
    • From: "Len Bullard" <cbullard@hiwaay.net>

• References:
  • Re: What is declarative XML? (And what's not)
    • From: Rick Jelliffe <rjelliffe@allette.com.au>