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] KML is very extensible ... but why?

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":


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"/>
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?



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) |

[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