OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
RE: [xml-dev] Marketplace XML Vocabularies

At 2009-12-31 14:42 -0500, Costello, Roger L. wrote:
>Awesome message Ken. Thanks!
> > Actually, a processor is required to produce the end result *as if*
> > it had implemented the described behavior.  It is not required to
> > behave as described in the specification.  It is a subtle but
> > important distinction
>I like it! A specification describes the end results of processing 
>elements, i.e., it's an effects-based description.
> > So, I would say that XML vocabularies only describe meaning and not
> > behavior.
>Shouldn't a specification of an XML vocabulary provide both meaning 
>and effect?

Not necessarily.  Only if there is an effect to be had by using the 
specification, which is not always the case.

>For example, consider this element:
>    <Author>...</Author>
>A specification could provide just the meaning of the <Author> 
>element, perhaps something like this:
>     Author: a person who writes a novel, poem, essay, etc.
>The meaning is nice, but what effect should result from an 
>application processing the <Author> element? That, it seems to me, 
>is vitally important for a specification to provide. Do you agree?

Not at all.  If I create an XML vocabulary for capturing ISBN 
information of books published by a publishing company, it will have 
an Author element as part of the vocabulary description, but it won't 
have a specification for what to do with that Author element.

Some companies may wish to use the Author element to create web pages 
summarizing all books by a given author for reference purposes.

Some companies may wish to load up their inventory and ordering 
systems with information about books and include the book author in 
that information to help their users choose which books to stock and buy.

The publisher may want to use the Author element to determine where 
the quarterly payment royalties go for books sold.

That the information describes a property is sufficiently useful to 
make standardizing the label for that information so that all users 
use and expect the same label for what they need.

Making the effort to standardize an XML vocabulary for capturing ISBN 
information will enable many processes to do what they want with the 
information.  If two trading partners want to effect the same process 
on that information, they may wish to create a standardized process 
to do so, but they didn't have to for the author information itself 
to be standardized.

>Assertion: an XML vocabulary that has aspirations of ending up in 
>the marketplace must be described by a specification that provides 
>both meaning and effect. Do you agree?


UBL describes *no* process whatsoever.  I don't know a lot about 
XBRL, but from what I do know I think XBRL doesn't either.  Both are 
quite successful in the "marketplace" because different vendors are 
embracing it *for different purposes*.  Both are standardized XML 
vocabularies that describe information and nothing else ... no 
processes, just structure and content ... processes are up to the 
users to determine.  The US Securities and Exchange Commission has an 
internal process of its own that acts on the standardized labels of 
information found in an XBRL instance.  The Government of Denmark has 
an internal process of its own that acts on the standardized labels 
of information found in a UBL instance.  The people creating XBRL and 
UBL instances don't have to know anything about any processes.  Their 
only obligation is to express the information they have using the 
standardized labels in the XML vocabularies.

Really, XML only ever describes information.  And for some XML 
vocabularies, their purpose is fulfilled by only describing 
information in a standardized set of labels.

Yes, the XSLT XML vocabulary describes information capturing the 
expected results of a standardized process, thus an XSLT instance 
describes the inputs to a documented standardized process expected to 
be implemented by an XSLT processor.  So, an XSLT processor acts on 
the XSLT instance and produces the result of a transformation.  I 
gave the example earlier of an XSLStyle stylesheet acting on an XSLT 
instance to create XHTML documentation for that stylesheet.  That is 
a different process acting on the XSLT instance assuming the same 
semantics of the XSLT specification (to know what to document how), 
yet totally ignoring the XSLT process because it isn't important to 
presenting the documentation of the stylesheet.

I think you an only assert that an XML vocabulary that has 
aspirations of ending up in the marketplace must be described by a 
specification that unambiguously and clearly documents the meaning of 
all element and attribute labels and the relationships of labeled 
information found in the instance.  A specification may also include 
unambiguous and clearly documented results of a set of processes one 
may choose to apply to an instance of the XML vocabulary.  Other 
(standardized or non-standardized) specifications may describe 
alternative processes on that same XML vocabulary.

A user community who wishes to adopt the standardized process will be 
well-served by also adopting the standardized vocabulary used that 
feeds that process.  Vendors wanting to serve that user community 
will be successful if their software implements the standardized 
processes users wish to engage with the vocabulary.

So I really cannot agree with you that *both* are required for an XML 
vocabulary to be successful.  Yes for an XML vocabulary that 
describes information used in a particular process, but not for *all* 
XML vocabularies as a general statement.

I hope this helps.

. . . . . . . . . . . . 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]

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS