Re: Marketplace XML Vocabularies
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format