RE: [xml-dev] Topics of keen interest to me ... how about you?

["Len Bullard" <cbullard@hiwaay.net>]

Maybe not opposition, Peter, but dysfunctional in some cases.  What follows is not a slam on XML, company, specific-programmers or whatever.   I understand versioning problems in complex software systems.   But…

 

A specific example because I’m looking at It so arguably it’s real even if arguably the solutions vary.

 

Software:  Arbortext Styler 5.3 + Adobe Pro 9  Windows 7 Operating System

 

1. The GUI widgets that decorate the node tree for items like attribute-modified values freeze.  Cold. Go to Process Manager and kill process.
2. The Styler system export of a FOSI is of course in terms of the internal stylesheet desigh but the FOSI language is more expressive.   The known issues of complex inheritance systems are better contained that way but the language development in the XML as edited XML becomes very complex and features lost on reimport to add features become a work item.  Say billable hours.
3. Depending of features supported, this is true for ALL of the export formats.  Each is implemented to a specific subset of the possible and useful expressions.
4. An XML pipeline that includes two schema artifacts, one a DTD the other an XSD works differently with respect to other system-specific XML data used to initialize and configure the editor.
5. System language features such as XML Schema’s namespace qualifiers create conditions that must be debugged to work in the editor.  OTW, big red elements with lines through them.   Yes, fix the references.  On the other hand, a DCF is a local file, not a system resource and if the requirement is they must be in the same directory then all th the namespace locations have to be set local in which case the namespace feature is useless.

 

It isn’t that they aren’t arguably solvable, but it’s a fair question to ask if they are entirely necessary to publish books.  We pay a lot just to tag, bag and print.  We justify that by the value of the information intrinsically by saying it is mission critical given the lifecycle, but we do not always decide where and when in a lifecycle information is critical and why and if that value is itself, scalar or complex.

 

Instead we give them code for all seasons.   Data driving is seasonal and we don’t always have rational GUIs.  

 

So in the end, it is not the GUI but the data sets that expressively matter.   It was never a problem to create a VRML97 viewer if you had the chops.  The problem was to write one that could faithfully render to the full expressive power of the language.  The closer the code is to real time rendering, the less amenable it is to being open to the language and the language designers.

 

len

 

 

-----Original Message-----
From: Peter Hunsberger [mailto:peter.hunsberger@gmail.com]
Sent: Monday, August 12, 2013 9:28 AM
To: Bill Kearney
Cc: Costello, Roger L.; xml-dev OASIS
Subject: Re: [xml-dev] Topics of keen interest to me ... how about you?

 

I find it interesting that "data driven" can someone how be viewed as in opposition from giving the user a better UI.  In the end, the metadata that should be used to build user interfaces is still data and exposing that as early and directly as possible and giving the users ways to manipulate that data is the best way to build a powerful user interface.  Exposing it directly as XML is probably not part of that scenario, but XSLT on top of XML can be directly below the layer that is exposed to the user and is very flexible and powerful.

Peter Hunsberger

 

On Sun, Aug 11, 2013 at 2:48 PM, Bill Kearney <wkearney@gmail.com> wrote:

Ah, bullshit.  It's still about wrangling users and their data.  All this talk about "data driven" comes across like excuses to get out from under UI responsibilities.    Nobody like the dirty work of massaging the first/last mile (yard?) of effort that faces the users.  But failure to do so makes the rest pretty much pointless.

-----Original Message-----

  There needs to be a shift in programming:
  programming must be secondary and data
  must be primary.

 

Let's change the world.

 

_______________________________________________________________________

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