Re: [xml-dev] KML is very extensible ... but why?

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

The first child element of very document element of the 81 document 
types in UBL 2.2 is <ext:UBLExtensions>.

This element can have any number of <ext:UBLExtension> elements with 
metadata about an extension, as well as the extension content 
point.  Under the content point is a single ##other as the apex of an 
XML extension in no namespace or a foreign non-UBL namespace.

Our "why" reason is two-fold:

 - there are XML vocabularies under other established governance that are
   useful to UBL users and there needs to be a home for users to add them
   to UBL without triggering a UBL schema violation (e.g. W3C DigSig, and
   someone contacted me about a W3C structure I didn't recognize but they
   wanted to include in their invoice) ... it makes no sense to try and
   mimic established foreign vocabularies using UBL document constructs
   because their governance will trigger changes that won't be kept up in
   UBL's mimic.

 - the committee's application of Pareto's 80/20 principle assumes 20% of
   UBL meets 80% of business requirements, the other 80% of UBL meets most
   of the more obscure business requirements but most people won't need
   them (so subsetting UBL is important), but that still doesn't guarantee
   that, for example, our definition of a purchase order line item isn't
   missing something important to some user community and so that user
   community can add that into their extension ... the goal being that UBL
   can be used by *all* communities because *all* of their requirements
   can find a home in the UBL structures.

The UBL committee has always felt that it would never be perfect in 
designing a one-document-model-for-everyone, and so took this 
approach to at least design a 
one-schema-expression-for-everyone.  And UBL acceptance is growing 
all the time.

I've proposed a prepared paper all about this for the Balisage 
symposium this year and if my proposal is accepted I'll talk more 
about this in Baltimore.  The symposium makes reference to 
"vocabulary ecosystems":

  http://www.balisage.net/VocabEco/index.html

So ... user communities within an ecosystem establish their 
interchange requirements that may require joint agreement on the use 
of extensions, and so the schemas should accommodate extensions to 
let them do that.  But if something comes into the ecosystem from 
outside, but still conforms to the base that all communities are 
using, there should still be enough information in that to "get paid" 
or whatever else is happening in the essence of the interchange.

I hope this is helpful.

. . . . . . Ken

At 2018-04-20 16:59 +0000, Costello, Roger L. wrote:
> Hi Folks,
>
> The format of KML 2.3 documents are specified with a W3C 1.1 XML 
> Schema. XML Schema 1.1 has a powerful feature which KML uses. At the 
> top of the KML schema is this:
>   <defaultOpenContent mode="interleave">
>       <any namespace="##other" processContents="lax"/>
>    </defaultOpenContent>
> Read as: "KML documents are open. That is, XML elements from any 
> non-KML namespace can be inserted before and after every element in 
> KML documents. Those non-KML elements do not have to validate 
> against any schema."
>
> That makes KML very extensible.
>
> But why?
>
> If I add non-KML stuff in a KML instance, who's going to understand 
> my stuff? Google Earth? No. Google Maps? No. NASA WorldWind? No.
>
> Only applications that have been custom-coded to understand my stuff 
> will be able to do anything with it. Right? Doesn't that destroy KML 
> as a global geographic annotation/visualization language since now 
> you've got all these non-interoperable dialects floating around?
>
> Thoughts?
>
> /Roger

--
Contact info, blog, articles, etc. http://www.CraneSoftwrights.com/x/ |
Check our site for free XML, XSLT, XSL-FO and UBL developer resources |
Streaming hands-on XSLT/XPath 2 training class @ US$45 (5 hours free) |