[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Transactional Validation and Restricted Profiles
There is a lot of interest in a version of the key components (interval, gluon, vavailability) that is restricted to be simple, concise, and predictable for use in transaction processing. While researching approaches to this, I came across this interesting document defined profiling in GML. http://portal.opengeospatial.org/files/?artifact_id=11266 found on this page http://www.ogcnetwork.net/gml-sf This paragraph in particular caught my eye… Clause 8 describes a rigid coding pattern for GML application schemas. The main motivation behind this pattern is to limit the set of XML-Schema and GML features that may be used to code a GML application schema. This in turn should simplify the task of building clients that can ingest schema documents that conform to this coding pattern and understand the structure of the feature types defined within. The schema is implemented in http://schemas.opengis.net/gml/3.1.1/profiles/gmlsfProfile/1.0.0/gmlsf.xsd Which appears to be similar to our icalendar.xsd in purpose, i.e., a pointer to the underlying vals and properties. If we followed this, we could have a fully declared and specified restriction set on WS-Calendar that uses the alternate icalendar-transaction,xsd [sic] to define objects that are compliant with the standard icalendar.xsd, but have the optionality severely restricted. tc “The single biggest problem in communication is the illusion that it has taken place.”
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]