Oh, OIDs have been around this block,
Brian. We understand them.
It’s separation of concerns.
OIDs are easily layered in as application constraints. They don’t
have to change XML as currently spec’d as a syntax. The case
to be made is do they change the advantages of using as John said, a
specialized XML processor and/or as Amelia noted, declare a namespace, set
rules and implement them.
len
-----Original Message-----
From: Brian Aberle
[mailto:xmlboss@live.com]
Sent: Sunday, March 23, 2014 11:05
PM
To: Len Bullard
Cc: xml-dev@lists.xml.org
Subject: RE: [xml-dev] XML For The
Average Monkey
len
I don't mean to belittle the joys of basic data plumbing. We all have
different sized data. If recognition of a small "oid" keyword
was in XML, then the basic plumbing will scale beautifully for big
pipes needed to run lots of shit for the whole city. If that stuff backs
up and starts spilling down main street the whole city will stink. It
would be outside the scope of basic plumbing except that many
plumbing implementations have dreams of processing massive datasets if
their Technology plans come to pass. Even the Average Monkey dreams
to be The Man. Small document are small documents, but many
many many many many small documents is another case all together. The
Beauty of XML is how it works for everything, all situations, it's one hammer
that pounds all kinds of nails. XML is so beautiful it
interconnects all kinds of apps. XML should make provisions for the
big nails too. Where will the world be in 20 years? 1 XML? It's
just something to think on.
Brian
> From: cbullard@hiwaay.net
> To: xml-dev@lists.xml.org
> Date: Sun, 23 Mar 2014 21:39:00 -0500
> Subject: [xml-dev] XML For The Average Monkey
>
> The years and archives are littered with the theory of parsing, direct and
> indirect addressing and the scree of what and how are semantic and
identity
> best related.
>
> The Average Code Monkey sees stringbuilder, textwriter, textreader,
doc.load
> XPath find, and the validator callback among others. We speculate the deep
> mysteries but day to day work is learning and scripting in a framework. MS
> blows it in XML by not understanding it as a composable format so
relegates
> it to the limits of the code editor. Pobrecito. The utility of XML is
> standing up project publishing systems that deliver complex data in final
> fixed formats. From XML to PDF, it's a smooth breeze.
>
> I don't mean to belittle the joys of character catching, but the beauty of
> XML is just how easy it is to build complex linked documents. Work out a
> namespace that you data editors either create correct by construction or
> validate and both, get your gridviews and treeviews chatting and leaving
> stuff on your editors, lay in some scripts for common tasks like batch
file
> validation and hand it off to the renderer and it just works.
>
> I don't mean to belittle the joys of character catching, but the beauty of
> XML is just how easy it is to build complex linked documents.>
Complexity of speculation exceeds necessary complexity of implementation for
> what is basic data plumbing.
>
> len
>
>
> _______________________________________________________________________
>
> 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
|
