[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
RE: [xml-dev] Marketplace XML Vocabularies
- From: "G. Ken Holman" <gkholman@CraneSoftwrights.com>
- To: "'xml-dev@lists.xml.org'" <xml-dev@lists.xml.org>
- Date: Thu, 31 Dec 2009 16:22:43 -0500
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?
No.
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]