RE: [xml-dev] "Introducing MicroXML, Part 1: Explore the basic principle

["Len Bullard" <Len.Bullard@ses-i.com>]

True.  It gets stranger: sometimes the various pieces made by the
various organizations actually don't work in combination. If you toss a
FOSI in there, it's wow time.  Even worse, there may be natural language
(eg, English specs) that govern the output by example (say images of
composed pages) that cannot be produced by the markup systems as
declared.

A bad meeting follows.

I guess we could have kept SGML inclusions. :)

len

-----Original Message-----
From: Rick Jelliffe [mailto:rjelliffe@allette.com.au] 
Sent: Friday, July 20, 2012 5:43 AM
To: xml-dev@lists.xml.org
Subject: Re: [xml-dev] "Introducing MicroXML, Part 1: Explore the basic
principles of ...

Because you are not always in the position of being able to influence
what is allowed in the Schema?

If you are in an organization where the schemas are made by one
department (in one country), the data is authored by another
department (in another country), the testing is done by another group
(in another country), the stylesheets are made by another department
(also not in your country) and the content is packaged into
applications by yet  another department, in another country,
outsourced to some other country, then then the schema business can be
a highly controlled affair, in order to reduce communication or
re-tooling costs.

Then imagine this was coupled to a company that used a data mapping
tool where you have to state every possible absolute XPath that can be
found in any document and program for that explicitly.  That is the
behaviour of at least one commonly used commercial tool, from the data
warehouse industry. If you add an extra element, you potentially may
have to deal with an explosion: so you cannot do it willy nilly.

Or imagine a production system which is written so that unknown
elements cause documents to be dropped as exceptions.  An earlier part
of the chain cannot just add an element or attribute unless they can
also remove it.

I think these kinds of scenarios are often more the case for people
working in large organizations, than being able to arbitrarily bend
the schemas: the technical difficulty in understanding schemas only
makes it worse.

One way out of this would be to provide a standard namespace that had
a semantic of "can appear anywhere, can contain anything you like,
isnt validated", which is not really possible without changing
existing schemas (and schema languages).   So I don't think elements
provide what PIs do: if elements were satisfactory, people would use
elements.

However, if MicroXML is not geared towards allowing people to hack
functional systems in the confines of large enterprises, none of that
matters. The response is not "You can use elements and attributes" but
"Use something else".

Cheers
Rick


On Sun, Jul 15, 2012 at 1:31 PM, James Clark <jjc@jclark.com> wrote:
> On Fri, Jul 13, 2012 at 10:07 PM, Len Bullard <Len.Bullard@ses-i.com>
wrote:
>>
>> If PIs are not available, this will likely eliminate MicroXML as a
>> markup language for composition intensive applications where
>> content-tagged structures such as Notes, Cautions and Warnings must
by
>> specification be bound to the same page.
>
> Why can't you use elements or attributes for this?

_______________________________________________________________________

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