Re: [xml-dev] Marketplace XML Vocabularies

["G. Ken Holman" <gkholman@CraneSoftwrights.com>]

At 2009-12-31 08:25 -0500, Costello, Roger L. wrote:
>Consider this: XML elements can be assigned standardized meaning and 
>standardized behavior. For example, XSLT is an XML vocabulary with 
>standardized meaning and behavior. An XSLT processor is an 
>application that behaves in accordance with the behavior described 
>by the XSLT specification.

Actually, a processor is required to produce the end result *as if* 
it had implemented the described behaviour.  It is not required to 
behave as described in the specification.  It is a subtle but 
important distinction:  the information marked up in XML as an XSLT 
stylesheet is declarative (even though template rules once selected 
are processed imperatively).  A stylesheet writer chooses to use the 
XSLT vocabulary to declare what is to be done for the 
transformation.  *How* a processor accomplishes that which the user 
wants is not specified.  If that processor doesn't produce what the 
user is expecting, then it probably won't be able to compete with a 
processor that does produce what the user is expecting.

So, I would say that XML vocabularies only describe meaning and not 
behaviour. The user of the XML vocabulary is declaring the conditions 
of what they want when their instance is processed by a processor 
implementing their expectations.  How that processor behaves is 
irrelevant if they get the end result they need.

There is a good quote from the XSL-FO specification that revealed 
this to me way back when it first was released:

http://www.w3.org/TR/2001/REC-xsl-20011015/xslspec.html#section-N639-Processing-a-Stylesheet
   The XSL processing model is intended to be conceptual only. An
   implementation is not mandated to provide these as separate
   processes. Furthermore, implementations are free to process the
   source document in any way that produces the same result as if
   it were processed using the conceptual XSL processing model. A
   diagram depicting the detailed conceptual model is shown below.

... and that quote has held me in good stead when thinking about all 
XML vocabularies that represent what people want to see as the end 
result of described processes.  Accordingly, specifications I've 
worked on have kept this in mind that what the XML represents is the 
end result, not the process itself.  Competition can then be based on 
how the end results are created, perhaps using innovative 
implementations unrelated to described processes but somehow 
producing the end result of the described processes.

>Since the publication of the XSLT specification, numerous XSLT 
>processors have entered the marketplace, with names such as SAXON, 
>XALAN, and Sabletron. Market forces drove some XSLT processors to 
>rise to the top, while others dropped out of popularity.
>
>Ditto for XML Schema.

Various reasons:  conformance, performance, product differentiations 
outside of the specification (e.g. available extensions, API's, etc.).

If a processor processes a user's instance and doesn't produce their 
expected result, the user will likely not use that processor.

>I call XSLT and XML Schema "marketplace XML vocabularies."
>
>Now consider (X)HTML. As far as I know, the (X)HTML specification 
>does not specify the behavior of each element. For example, it does 
>not specify how an application (e.g., browser) should behave upon 
>encountering, say, a <ul> element.

Oh?  How are the following two different?

   http://www.w3.org/TR/1999/REC-html401-19991224/struct/lists.html#h-10.2
   Ordered and unordered lists are rendered in an identical manner except
   that visual user agents number ordered list items. User agents may....

and:

   http://www.w3.org/TR/2007/REC-xslt20-20070123/#applying-templates
   The xsl:apply-templates instruction takes as input a sequence of nodes
   (typically nodes in a source tree), and produces as output....)

In both cases the reader of the specification is directed as to which 
XML markup to use to effect an end result of, respectively, user 
agent presentation and user agent transformation.  The XHTML 
specification doesn't say *how* the rendering is effected, only what 
it is to look like.  The XSLT specification doesn't say *how* the 
output is produced, only what output is to be produced.

>Yet, the (X)HTML vocabulary has a clear presence in the marketplace, 
>in the form of browsers such as Firefox, IE, and Opera.

Various reasons:  conformance, performance, product differentiations 
outside of the specification (e.g. user interface, API's, etc.).

But note that user agent presentation is but one use of 
XHTML.  Ostensibly, people are using XHTML to relate information to 
other information, declaring those relationships through hierarchy 
and hyperlinking.  Rendering those relationships is one use of 
XHTML.  Others might have other processes acting on those relationships.

>(X)HTML is a marketplace XML vocabulary.
>
>
>QUESTIONS
>
>1. What are the requirements for an XML vocabulary to find presence 
>in the marketplace?

Meeting a need that the market has that isn't currently being 
met.  Many XML vocabularies have been created but relatively few are 
in active use.  Some are pet projects that people throw out there for 
interest.  Others might be vendor attempts at addressing a need with 
their own colloquial vocabulary, which either gets ignored or perhaps 
gets adopted and built upon to create a standard vocabulary.

I look to my experience in OASIS specifications.  Consider the 
Universal Business Language (UBL) XML vocabulary:

   http://docs.oasis-open.org/ubl/os-UBL-2.0/UBL-2.0.html

The elements in the vocabulary don't describe behaviour but merely 
label the information found in, say, a purchase order or an invoice, 
so that different processors acting on that information behave as 
users expect the processors to behave.  XML is only being used to 
describe the information to act on, it doesn't restrict how that 
information is acted on.  Different processes will act on different 
business documents for different reasons.

Different vendors of electronic commerce software have tried to 
create their proprietary answer to business document XML vocabularies 
so that they could sell their software.  I would think that users of 
business document XML vocabularies would not want their information 
tied to a single vendor.  The xCBL creators donated their XML 
vocabulary to OASIS at the inception of UBL (it happens that since 
then the original structure of xCBL was maintained while the 
particular XML elements were not kept and have been replaced).

So standardization is important to users of XML vocabularies who 
don't want to be tied to any one vendor with a colloquial vocabulary.

But, there is even competition in standardization, that hopefully 
leads to cooperation and harmonization.  For example, in parallel to 
the development of OASIS UBL, the UN/CEFACT organization is 
developing its own XML vocabularies for electronic commerce.  In 2006 
both organizations agreed to harmonize their work, and it was agreed 
that OASIS would only maintain dot releases of UBL 2 in order to meet 
user requirements of UBL 2 users.  It was agreed there wouldn't be 
any kind of "UBL 3" because it is expected that UN/CEFACT will 
eventually produce an XML vocabulary that meets the needs of both 
UN/CEFACT users and OASIS UBL users.  Until that happens, user 
communities can adopt OASIS UBL knowing that UN/CEFACT are working 
towards meeting and exceeding those requirements in the future.

Note that the PEPPOL project is looking at deploying XML 
specifications for business documents across Europe and, accordingly, 
is creating implementations supporting those OASIS documents 
available to meet user requirements as well as those UN/CEFACT 
documents available to meet user requirements, and users can choose 
whichever one satisfies their needs:

   http://www.peppol.eu/

In the OASIS Code List Representation Technical Committee:

   http://www.oasis-open.org/committees/codelist/

... the independent work of Tony Coates was brought in to the 
committee and standardized as Genericode 1.0.  Again, an existing 
colloquial vocabulary was developed into a standardized vocabulary 
and with standardization users get the reassurances of no vendor 
lock-in.  Other standardized vocabularies are being developed within 
in the committee, such as context/value association 
(CVA).  Interestingly, the committee voted on removing any kind of 
process description or standardization out of early drafts of the CVA 
specification, reducing it solely to a declarative specification of 
relationships.  Thus, implementation of any process for CVA is up to 
users to agree on with vendors in order to meet user needs.

>Must the XML vocabulary have both standardized meaning and behavior?

I would say "definitely" for meaning and "not at all" for behaviour, 
provided that the end result of however the processor behaves 
produces the end result represented by the meaning *expected* by the user.

Back in the SGML days there were some permathreads that boiled down 
to "a marked-up instance represents anything the recipient wants it 
to represent".  If what the recipient thinks happens to match what 
the sender thinks, then the sender has achieved their objective of 
relating the information as they thought.  But a recipient of an XML 
instance is free to make entirely unexpected interpretations of the 
information and that isn't wrong.  It might be unexpected by the 
sender, but who is to say that what the recipient is doing with it is 
wrong?  If they want to do anything at all with that information, 
that doesn't make it wrong.

Consider my XSLStyle stylesheet for documenting an XSLT stylesheet:

   http://www.CraneSoftwrights.com/resources/#xslstyle

... a developer's XSLT stylesheet is being processed by the XSLStyle 
stylesheet to produce XHTML documentation, it isn't being processed 
to effect a transformation.  Writing an XSLT stylesheet produces two 
results based on the process acting on the instance:  an XSLT 
processor acting on the instance effects a transformation of some 
kind,  a stylesheet acting on the instance creates a file of XHTML 
documentation.  The instance doesn't change, yet two very different 
processes effect two very different results on the same 
instance.  The XSLT vocabulary has standardized meaning, but two 
entirely different processes are acting on an XSLT instance.

>2. What are the characteristics of an XML vocabulary that incite 
>vendors to create conforming applications and compete in the marketplace?

I would think the main characteristic is that the vendor's users find 
the vocabulary useful enough to want to work with it, and the 
vendor's software powerful enough or conformant enough that the user 
is willing to pay the vendor for that software.  Wouldn't most 
business decisions work that way?

I think early users of XML were complacent and would live with 
whatever the vendor gave them, but these days XML users are more in 
the driver's seat by having expectations of what they want from the 
tools they use and are willing to pay for.

One last comment:  standardization does not necessary guarantee 
success.  There is still an obligation of standards committees to 
meet real needs.  Tim McGrath on the UBL committee often brings up 
the important point that "traction trumps sanction".  An XML 
vocabulary that promotes adoption and gets traction from users will 
win out over an XML vocabulary that doesn't meet users' needs but is 
dictated from on high with formal sanction.

I hope this is considered helpful.

. . . . . . . . . . . . Ken


--
UBL and Code List training:      Copenhagen, Denmark 2010-02-08/10
XSLT/XQuery/XPath training after http://XMLPrague.cz 2010-03-15/19
XSLT/XQuery/XPath training:   San Carlos, California 2010-04-26/30
Vote for your XML training:   http://www.CraneSoftwrights.com/x/i/
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/x/
Training tools: Comprehensive interactive XSLT/XPath 1.0/2.0 video
Video lesson:    http://www.youtube.com/watch?v=PrNjJCh7Ppg&fmt=18
Video overview:  http://www.youtube.com/watch?v=VTiodiij6gE&fmt=18
G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
Male Cancer Awareness Nov'07  http://www.CraneSoftwrights.com/x/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal