Copyright © @@@@ W3C ® ( MIT , ERCIM , Keio ), All Rights Reserved. W3C liability , trademark and document use rules apply.
This
specification
defines
the
interchange
format
for
Service
Modeling
Language,
Version
1.1
(SML)
models.
Markup
is
defined
to
identify
This
format
identifies
the
model
being
interchanged,
to
distinguish
distinguishes
between
model
definition
documents
and
model
instance
documents,
and
to
bind
defines
the
binding
of
rule
documents
with
other
documents
in
the
interchange
set.
This document is an editors' copy that has no official standing.
Copyright holders will not be liable for any direct, indirect, special or consequential damages arising out of any use of the software or documentation.
1.
Introduction
(Non-Normative)
2.
Notations
and
Terminology
2.1
Notational
Conventions
2.2
Terminology
3.
Dependencies
on
Other
Specifications
4.
Informal
Description
(Non-Normative)
4.1
Packaging
4.2
URI
References
4.3
Rule
Bindings
4.4
Schema
Bindings
4.5
Interoperability
of
SML
Models
5.
SML
Interchange
Format
Definition
5.1
Conformance
Criteria
5.2
SML-IF
Documents
5.2.1
Embedded
Documents
5.2.2
Referenced
Documents
5.2.3
Schema
Completeness
5.2.4
SML-IF
Document
Version
5.3
URI
References
5.3.1
URI
equality
5.3.2
Document
Aliases
5.3.3
URI
Reference
Processing
5.4
Rule
Document
Bindings
5.4.1
URI
prefix
matching
Prefix
Matching
5.4.2
Rule
Bindings
defined
5.5
5.4.3
Schema
Bindings
6.
References
6.1
Normative
6.2
Non-Normative
A.
SML-IF
Schema
B.
Localization
of
IF
Identity
Sample
(Non-Normative)
As defined in the Service Modeling Language, Version 1.1 (SML) Specification [ SML 1.1 ] an SML model is a collection of XML documents that may be used to describe complex services and systems such as a set of IT resources, services and their interrelations.
In
every
SML
model
there
are
two
distinguished
subsets
of
the
model's
documents,
the
definition
documents
and
the
instance
documents.
The
model's
definition
documents
describe
the
abstract
structure
of
the
model,
and
provide
much
of
the
information
a
model
validator
needs
to
decide
whether
the
model
model,
as
a
whole
whole,
is
valid.
The
model's
instance
documents
describe
or
support
the
description
of
the
individual
resources
that
the
model
portrays.
The SML Specification identifies two categories of model definition documents that participate in SML model validation: Schema documents and rule documents. Schema documents in a model are XML documents that conform to the [ SML 1.1 ] defined extensions to XML Schema [ XML Schema Structures , XML Schema Datatypes ]. Rule documents in a model include XML documents that conform to the [ SML 1.1 ] defined extensions of Schematron [ ISO/IEC 19757-3 ].
To ensure accurate and convenient interchange of the documents that make up an SML model or a portion of an SML model, it is useful to define both an implementation-neutral interchange format that preserves the content and interrelationships among the documents and a constrained form of SML model validation. For this purpose, this specification defines a standard format called the SML Interchange Format (SML-IF) and a process called interchange set validation.
The specification consists of two parts. The first part is an informal description of SML-IF to set the context. This is followed by SML-IF's normative definition.
The keywords " MUST ", " MUST NOT ", " REQUIRED ", " SHALL ", " SHALL NOT ", " SHOULD ", " SHOULD NOT ", " RECOMMENDED ", " MAY ", and " OPTIONAL " in this document are to be interpreted as described in RFC 2119 [ IETF RFC 2119 ].
The content of this specification is normative except for sections, notes, or texts that are explicitly marked as non-normative. If a section is marked as non-normative, then all contained sub-sections are non-normative, even if they are not explicitly marked as such.
The following terms are used in this specification. They are listed here in alphabetical order. This specification also uses terms defined in the [ SML 1.1 ] specification.
An alias is a temporary name assigned to a model document [ SML 1.1 ] within the context of an interchange set .
The interchange set is the set of documents that constitute the SML model [ SML 1.1 ] to be interchanged.
Interchange set validation is the process of assessing the validity of the SML model [ SML 1.1 ] represented by the interchange set while maintaining all assertions and interrelationships among the documents in the interchange set as defined by this specification.
A schema binding is an association of a namespace with a set of schema documents in the interchange set and the instance documents [ SML 1.1 ] that should be validated against this set of schema documents.
Other specifications on which this one depends are listed in [ Normative_References ].
Conforming implementations of this specification MUST support SML 1.1 [ SML 1.1 ], XML 1.0 [ XML ] and XML Schema 1.0 [ XML Schema Structures , XML Schema Datatypes ]. Conforming implementations MAY additionally support later versions of the XML or XML Schema specifications.
Note:
This note is non-normative. Although SML 1.1 and SML-IF allow conforming implementations to support newer versions of dependent specifications, there are interoperability implications to be considered when documents based on those versions are interchanged using SML-IF. When an SML-IF document interchanges data built using newer versions of the SML and SML-IF dependent specifications, consumers of the SML-IF document not supporting these versions may be unable to interpret some of the data exchanged by this document.
To represent an SML model in a standard way for interchange, the following topics need to be addressed.
Packaging: The collection of XML documents that make up a model (or model portion) to be interchanged need to be gathered together. In doing so, the model definition and model instance documents need to be distinguished from one another since they play distinct roles in the model.
Explicit
references:
The
documents
to
be
interchanged
may
explicitly
refer
to
one
another
and
to
documents
that
are
not
packaged
with
the
documents
being
interchanged.
[
SML
1.1
]
SML
references
among
SML
model
instance
documents
are
an
obvious
example.
Less
obvious
are
such
references
as
certain
schemaLocation
attributes
in
schema
documents
and
xsi:schemaLocation
attributes
in
instance
documents.
Section
4.4
Schema
Bindings
defines
how
schemaLocation
is
processed
in
these
cases.
Rule bindings and schema bindings: [ SML 1.1 ] permits models in which rule documents apply to all, none, or subsets of the model's documents. SML-IF specifies how to describe which rule documents apply to which of the model's documents.
Consistent model validation: The process of SML model validation defined in [ SML 1.1 ] contains points of variability that, left unconstrained, would make it difficult for SML-IF to ensure interoperability of independent implementations in any practical way. Many of these sources of variability are inherited from other specifications that SML uses, e.g. URI comparison RFC 3986 ([ IETF RFC 3986 ]) and the source of Schema components ([ XML Schema Structures ]) used to validate model instance documents. SML-IF constrains these points of variability, with the goal of ensuring interoperability when specific conditions are met and of increasing the likelihood of interoperability in other cases. The enforcement of these additional constraints on SML model validation occurs during the process of interchange set validation .
An SML-IF document packages a collection of SML model documents to be interchanged as a single XML document. All SML-IF documents conform to the XML Schema defined in the normative part of this specification.
Informally, the structure of SML-IF documents, using the pseudo-schema notation from WSDL 2.0 [ WSDL 2.0 Core Language ] is as follows:
<?xml version="1.0" encoding="UTF-8"?> <model xmlns="http://www.w3.org/@@@@/@@/sml-if" xmlns:xs="http://www.w3.org/2001/XMLSchema" SMLIFVersion="xs:token Version number of the SML-IF spec used to generate the current document"> <identity> <name> xs:anyURI Namespace identifying the model </name> <version> ? xs:token <!—The version of this model. E.g., 1.2 or 0.3> </version> <displayName sml:locid= "xs:anyURI URI identifying the translation resource for the display name" ?> ? xs:string Descriptive name of model intended for display <displayName/> <description sml:locid= "xs:anyURI URI identifying the translation resource for the description" ?> ? xs:string Textual description of model for human consumption <description/> <baseURI> xs:anyURI <!-Base URI for relative references defined in the interchange set; must be an absolute reference> </baseURI> ? </identity> <ruleBindings> ? <ruleBinding> * <documentAlias="xs:anyURI"/> ? <ruleAlias="xs:anyURI"/> </ruleBinding> </ruleBindings> <schemaBindings> ? <defaultSchema> ? <namespaceBinding/> * </defaultSchema> <schemaBinding> * <namespaceBinding/> * <documentAlias/> + </schemaBinding> </schemaBindings> <definitions schemaComplete="xs:boolean"> ? <document> * <docInfo> ? <aliases> ? <primaryAlias> ? xs:anyURI <!- A URI by which other documents in the interchange set may refer to this document. If a document has a primaryAlias, then the absolute form of the primary alias will be the base URI for all relative URIs used in SML references contained by that document.> </primaryAlias> <alias> * xs:anyURI <!- A URI by which SML references from other documents may refer to this document.> </alias> </aliases> </docInfo> [ <data> xs:any <!—At most one definition document goes here> </data> | <locator> <documentURI/> ? xs:any <!—A URI or IRI that points to a definition document goes here> </locator> ] </document> </definitions> <instances> ? <document> * <docInfo> ? <aliases> ? <primaryAlias> ? xs:anyURI <!- A URI by which other documents in the interchange set may refer to this document. If a document has a primaryAlias, then the absolute form of the primary alias will be the base URI for all relative URIs used in SML references contained by that document.> </primaryAlias> <alias> * xs:anyURI <!- A URI by which SML references from other documents may refer to this document.> </alias> </aliases> </docInfo> [ <data> xs:any<!—At most one instance document goes here> </data> | <locator> <documentURI/> ? xs:any <!—A URI or IRI that points to an instance document goes here> </locator> ] </document> </instances> </model>
A
document
producer
can
specify
the
version
of
the
specification
under
which
the
current
document
was
generated,
and
with
which
conformance
is
claimed,
in
the
SMLIFVerion
attribute.
For
example,
if
this
version
of
SML-IF
is
used
as
the
basis
of
a
document,
the
value
of
this
attribute
would
be
the
value
"1.1".
The
identity
element
provides
information
applications
can
use
to
identify
and
describe
the
set
of
SML
documents
being
interchanged.
The
baseURI
child
element
is
one
way
to
specify
a
base
URI
to
be
used
by
relative
URI
references
in
the
interchange
set
.
Another
way
to
specify
a
base
URI
is
to
use
the
primaryAlias
element
as
a
child
element
of
aliases
.
The
SMLIFVersion
attribute
is
defined
on
the
model
element
and
may
be
useful
when
diagnosing
failures
encountered
while
processing
SML-IF
documents.
For
example,
if
a
document
asserts
conformance
with
version
1.1
of
the
SML-IF
specification
and
a
human
can
see
that
it
is
not
in
fact
conformant,
then
it
is
likely
that
the
problem
occurred
during
the
production
of
the
document.
If
the
same
document
appears
to
humans
to
be
conformant,
then
the
focus
of
diagnosis
might
shift
toward
the
consumer
and
its
invocation
parameters.
The
schemaComplete
attribute
is
defined
on
the
definitions
element
and
is
used
to
indicate
that
the
schemas
constructed
from
the
definition
documents
in
the
interchange
set
are
complete,
in
the
sense
that
the
validity
of
the
SML
model
represented
by
the
interchange
set
is
fully
determined
by
these
schemas.
Formally,
however,
the
schemaComplete
attribute
does
not
express
any
assertion
that
the
schemas
so
constructed
are
in
fact
complete,
or
that
interchange
set
validation
using
these
schemas
will
not
result
in
any
errors
indicating
that
some
components
are
missing
from
the
schemas.
The
only
formal
effect
of
schemaComplete
attribute
with
a
value
of
true
or
1
is
to
specify
precisely
the
schemas
with
which
interchange
set
validation
is
to
be
performed.
The
optional
ruleBindings
element
is
used
to
contain
information
that
associates
rule
documents
with
the
documents
they
apply
to.
See
4.3
Rule
Bindings
for
further
details.
Every
document
in
the
interchange
set
appears
as
content
of
a
document
element
in
either
the
definitions
or
the
instances
element,
depending
on
whether
the
document
in
question
is
a
model
definition
or
a
model
instance
document.
There
can
be
at
most
one
embedded
document
contained
by
a
document/data
element.
Both
definitions
and
instances
are
optional.
So,
for
example,
if
there
are
no
model
definition
documents
being
packaged,
the
definitions
element
must
be
omitted.
The
first
child
of
each
document
is
typically
a
docInfo
element
that
(indirectly)
contains
at
most
one
primaryAlias
element
as
well
as
a
list
of
alias
elements
whose
content
is
a
URI
with
no
fragment
component
(i.e.,
one
with
no
"#"
in
it).
Each
of
these
URIs
serves
as
a
name
that
other
documents
can
use
to
refer
to
this
document.
Examples
of
how
aliases
are
used
to
handle
URI
references
are
given
in
4.2
URI
References
.
A
document
in
the
interchange
set
can
be
represented
in
either
of
two
ways,
by
embedding
its
content,
or
by
providing
a
reference
to
it.
Which
is
being
used
is
indicated
by
the
next
child
of
the
document
element.
If
the
document
is
to
be
embedded,
a
data
element
is
used
to
contain
the
actual
content
of
the
document.
If
the
document
is
being
referenced
rather
than
embedded,
a
locator
element
is
used
to
contain
the
reference.
Syntactically,
the
The
content
of
a
locator
can
be
a
documentURI
element
defined
by
SML-IF
or
anything
else
understood
by
the
consumer.
Although it is not fully shown in the pseudo-schema above, the SML-IF schema has an "open content model." To provide extensibility, essentially every element in it can contain additional content and/or attributes from other XML namespaces.
When
processing
the
SML
model
packaged
inside
an
SML-IF
document,
certain
URI
references
(as
defined
in
RFC
3986
[
IETF
RFC
3986
])
may
need
to
be
processed
to
find
their
corresponding
target.
For
example,
in
order
to
assess
SML
validity
of
the
interchanged
model,
SML
references
using
the
URI
scheme
Reference
Scheme
[
SML
1.1
]
need
to
be
resolved;
and
resolved.
In
addition,
in
order
to
assemble
schemas
from
multiple
schema
documents
as
part
of
the
interchange
set
validity
assessment,
the
schemaLocation
attribute
on
an
xs:include
element
needs
to
be
processed
to
locate
the
schema
document
being
included.
document.
To see how these URI references are handled, consider the following SML-IF document:
<?xml version="1.0" encoding="UTF-8"?> <model xmlns="http://www.w3.org/@@@@/@@/sml-if" version="1.0"> <identity> <name>http://www.university.example.org/sml/models/Sample/InterDocReferences</name> <baseURI>http://www.university.example.org/Universities/</baseURI> </identity> <definitions> <document> <data> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:include schemaLocation="http://www.university.example.org/university/enrollmodel.xsd"/> </xs:schema> </data> </document> </definitions> <instances> <document> <data> <Student xmlns="http://www.university.example.org/ns" xmlns:sml="http://www.w3.org/2007/09/sml" xmlns:u="http://www.university.example.org/ns"> <ID>1000</ID> <Name>John Doe</Name> <EnrolledCourses> <EnrolledCourse sml:ref="true"> <!-- SML Reference to a course INside the interchange set --> <sml:uri> http://www.university.example.org/Universities/MIT/Courses.xml#smlxpath1(/u:Courses/u:Course[u:Name='PHY101']) </sml:uri> </EnrolledCourse> <EnrolledCourse sml:ref="true"> <!-- SML Reference to a course INside the interchange set --> <sml:uri> http://www.university.example.org/Universities/SFU/Courses.xml#smlxpath1(/u:Courses/u:Course[u:Name='MUSIC205']) </sml:uri> </EnrolledCourse> <EnrolledCourse sml:ref="true"> <!-- SML Reference to a course OUTside the interchange set --> <sml:uri> http://www.university.example.org/Universities/Capella/Courses.xml#smlxpath1(/u:Courses/u:Course[u:Name='LIT103']) </sml:uri> </EnrolledCourse> </EnrolledCourses> </Student> </data> </document> <document> <!-- The following primary alias matches the first course referenced above --> <docInfo> <aliases> <primaryAlias>http://www.university.example.org/Universities/MIT/Courses.xml</primaryAlias> </aliases> </docInfo> <data> <Courses xmlns="http://www.university.example.org/ns"> <Course> <Name>PHY101</Name> </Course> <Course> <Name>MAT200</Name> </Course> </Courses> </data> </document> <document> <!-- The following primary alias matches the second course referenced above. The primary alias's value is a relative URI. In this case, both smlif:baseURI and the primary alias URI will contribute to the base URI for relative references contained by this document. --> <docInfo> </aliases> <alias primaryAlias=”true">/SFU/Courses.xml</alias> </aliases> </docInfo> <data> <Courses xmlns="http://www.university.example.org/ns"> <Course> <Name>ENG106</Name> </Course> <Course> <Name>MUSIC205</Name> </Course> </Courses> </data> </document> </instances> </model>
Formal
rules
about
how
URI
references
are
processed
are
defined
in
section
5.3.3
URI
Reference
Processing
.
When
not
packaged
in
an
SML-IF
document,
certain
URI
references
(e.g.
values
of
sml:uri
elements
or
certain
schemaLocation
attributes)
are
dereferenced
to
find
their
corresponding
document.
When
these
references
are
packaged
in
an
SML-IF
document,
consumers
of
the
SML-IF
document
need
to
first
examine
whether
the
target
document
or
element
is
packaged
in
the
same
SML-IF
document.
To
determine
this,
the
fragment
component,
if
any,
is
temporarily
ignored
to
form
a
URI.
This
URI
is
then
compared
against
the
primaryAlias
or
alias
URIs
of
packaged
model
documents.
If
the
URI
is
equal
to
the
URI
in
an
alias
or
primaryAlias
element
(see
5.3.1
URI
equality
),
the
consumer
will
not
attempt
to
look
for
targets
of
this
URI
outside
of
the
SML-IF
document,
although
there
may
exist
a
document
retrievable
at
this
URI.
If
the
original
URI
reference
has
a
fragment,
the
fragment
is
applied
to
the
referenced
document
to
establish
the
reference
target(s)
according
to
the
corresponding
SML
reference
scheme
definition;
otherwise
the
SML
reference
target
is
the
root
element
of
the
referenced
document.
If
the
URI
is
not
equal
to
the
URI
in
any
alias
or
primaryAlias
element,
then
the
SML-IF
document
does
not
contain
the
corresponding
target
of
the
original
URI
reference.
The
consumer
may
or
may
not
attempt
to
look
for
targets
outside
of
the
SML-IF
document,
depending
on
the
nature
of
the
URI
reference.
Referring
now
to
Formal
rules
about
how
URI
references
are
processed
are
defined
in
section
5.3.3
URI
Reference
Processing
.
Several
examples
of
resolving
references
can
be
seen
in
the
example
SML-IF
document
shown
above,
several
examples
of
resolving
references
is
shown,
illustrating
the
use
of
both
relative
and
absolute
alias
and
primaryAlias
URI
values.
In the first example, a reference with an absolute URI, the following SML reference, must first be separated into its document URI and fragment components:
http://www.university.example.org/Universities/MIT/Courses.xml#smlxpath1(/u:Courses/u:Course[u:Name='PHY101'])
After removing the fragment, the document portion of the reference is:
http://www.university.example.org/Universities/MIT/Courses.xml
This
document
URI
is
equal
to
the
URI
listed
in
the
primaryAlias
accompanying
the
Courses
document.
So,
by
applying
the
fragment
in
the
URI
reference
to
the
Courses
document,
we
determine
that
the
reference
is
to
the
Course
element
whose
Name
element
has
"PHY101"
as
its
content.
The second example reference, using a relative URI, is processed similarly. The full reference is:
http://www.university.example.org/Universities/SFU/Courses.xml#smlxpath1(/u:Courses/u:Course[u:Name='MUSIC205'])
After removing the fragment, the document portion of the reference is:
http://www.university.example.org/Universities/SFU/Courses.xml
This
URI
is
equal
to
the
primaryAlias
defined
on
the
last
instance
document
in
the
interchange
set,
after
the
smlif:baseURI
content
is
applied
to
the
relative
URI
contained
by
the
document’s
primary
alias.
So,
by
applying
the
fragment
in
the
reference
to
the
Courses
document,
we
determine
that
the
reference
is
to
the
Course
element
whose
Name
element
has
"MUSIC205"
as
its
content.
The third example, showing an unresolved reference, is processed similarly. The full reference is:
http://www.university.example.org/Universities/Capella/Courses.xml#smlxpath1(/u:Courses/u:Course[u:Name='LIT103'])
After removing the fragment, the document portion of the reference is:
http://www.university.example.org/Universities/Capella/Courses.xml
This
document
URI
is
not
equal
to
the
URI
in
any
alias
or
primaryAlias
element.
This means that it is an unresolved SML reference.
The URI:
http://www.university.example.org/university/enrollmodel.xsd
(value
of
the
schemaLocation
attribute
on
the
include
element)
is
not
equal
to
any
alias
.
The
consumer
may
or
may
not
attempt
to
locate
a
schema
document
using
this
URI
reference.
[
SML
1.1
]
uses
Schematron
patterns
embedded
in
SML
schemas
and
in
separate
explicitly
bound
rule
documents
to
express
constraints
that
cannot
be
expressed
in
XML
Schemas.
Schematron
patterns
embedded
in
SML
Schema
documents
all
have
well
defined
targets.
[
SML
1.1
]
permits
models
in
which
rule
documents
apply
to
all,
none,
or
subsets
of
the
model's
documents.
SML-IF
uses
the
list
of
ruleBinding
elements
contained
in
the
optional
ruleBindings
element
to
associate
rule
documents
with
the
documents
in
the
interchange
set
to
which
they
apply.
Each
ruleBinding
associates
the
documents
having
an
alias
beginning
with
the
URI
prefix
given
in
the
documentAlias
with
the
rule
documents
having
an
alias
beginning
with
the
prefix
given
in
the
ruleAlias
.
So,
for
example, the ruleBinding
:
<ruleBinding> <documentAlias="http://www.university.example.org/sml/infrastructure/"/> <ruleAlias="http://www.university.example.org/sml/infrastructurerules/"/> </ruleBinding>
Would associate documents that have the aliases such as:
http://www.university.example.org/sml/infrastructure/server427.xml
and
http://www.university.example.org/sml/infrastructure/switch6E.xml
with rule documents that have aliases such as:
http://www.university.example.org/sml/infrastructurerules/assetistracked.sch
and
http://www.university.example.org/sml/infrastructurerules/managedbycorporate.sch
SML-IF
specifies
rule
bindings
among
documents
in
the
interchange
set.
It
does
not
specify
rule
bindings
that
apply
to
documents
not
in
the
interchange
set.
That
said,
it
is
often
the
case
that
the
intent
of
transferring
an
SML-IF
document
is
to
relate
its
contents
with
other
SML
documents
not
in
the
interchange
set.
For
example,
the
intent
might
be
to
merge
the
interchange
set
with
an
existing
SML
model.
In
such
cases
the
context
of
use
may
choose
to
extend
the
definition
of
ruleBinding
to
bind
documents
not
in
the
interchange
set.
For
example,
if
the
interchange
set
is
merged
into
an
existing
model,
the
merge
process
might
choose
to
extend
the
definition
of
ruleBinding
elements
to
bind
rule
documents
in
the
interchange
set
to
documents
in
the
merged
model
that
weren't
included
in
the
interchange
set.
Schema
documents
can
be
connected
with
other
schema
documents
using
composition
features
provided
by
XML
Schema.
This
includes
xs:include
,
xs:redefine
,
and
xs:import
.
A
schema
document's
validity
may
depend
on
other
schema
documents
it
includes/redefines/imports,
or
even
other
schema
documents
that
include/redefine/import
it.
When
performing
interchange
set
validation
over
the
SML
model
packaged
in
an
SML-IF
instance,
associations
between
XML
Schema
definition
documents
and
instance
documents
need
to
be
drawn,
both
to
completely
validate
XML
Schema
documents
themselves
and
to
establish
the
schema-validity
of
the
instance
documents.
The XML Schema specification provides more flexibility in constructing the schema used for assessment than is appropriate for the semantics defined by SML and SML-IF for interchange set validation.
It allows processor latitude in terms of locating schema documents (resolving namespace and schema location attributes) and composing schema documents together to form a single schema.
Schema
location
attributes
can
be
ignored
in
some
cases
(
xsi:schemaLocation
in
instance
documents
and
schemaLocation
attribute
on
xs:import
)
and
allowed
to
"fail
to
resolve"
in
others
(
schemaLocation
attribute
on
xs:include
and
xs:import
).
Multiple imports of the same namespace allow all but the first one to be ignored.
So
it
is
clear
that
As
a
result,
SML-IF
cannot
guarantee
general
case
interoperability
based
only
on
XML
Schema
given
the
constraints
above
and,
therefore,
needs
to
specify
how
to
determine
such
associations.
This
section
describes
a
method
to
achieve
this
goal.
An SML-IF document can be:
Schema-complete - All schema documents are included in the SML-IF document, either as an 5.2.1 Embedded Documents or as 5.2.2 Referenced Documents .
Schema-incomplete - Some required schema documents may not be included in the SML-IF document, either as an embedded document or a referenced document.
It
is
necessary
for
an
SML-IF
producer
to
declaratively
distinguish
between
these
two
cases
because
making
that
distinction
is
not
always
possible
for
a
consumer
based
on
the
content
alone.
SML-IF
uses
the
schemaComplete
attribute
on
the
definitions
element
to
indicate
whether
this
SML-IF
document
includes
all
necessary
schema
definition
documents.
When
this
attribute
is
specified
with
a
value
of
"true",
then
the
schema
validity
of
the
schema
definition
documents
and
instance
documents
depend
only
on
built-in
components
or
components
from
definition
documents
included
in
the
SML-IF
document.
Built-in
components
include:
four xsi: attributes (defined by XML Schema)
all schema built-in types (xs:anyType and simple types defined in XML Schema Part 2)
sml:ref attribute declaration
sml:uri element declaration
An SML model represented by a schema-incomplete SML-IF document is not necessarily invalid. However, SML-IF cannot guarantee interoperability for a schema-incomplete SML-IF document.
SML-IF
uses
a
list
of
schemaBinding
elements
contained
in
the
optional
schemaBindings
element
to
associate
a
namespace
with
a
set
of
schema
documents
in
the
interchange
set
and
the
instance
documents
that
should
be
validated
against
this
set
of
schema
documents.
Each
namespaceBinding
child
of
a
schemaBinding
element
associates
the
namespace
specified
in
its
namespace
attribute
with
the
schema
documents
whose
aliases
are
specified
in
its
aliases
attribute.
In
addition,
the
instance
documents
that
are
to
be
assessed
against
this
set
of
schemas
are
specified
in
the
documentAlias
child
element
of
the
same
schemaBinding
element.
The following example illustrates schema bindings.
<schemaBindings> <!-- Each "schemaBinding" element corresponds to a schema and model instance documents that are assessed against this schema --> <schemaBinding> <!-- all "namespaceBinding" children together build the schema --> <namespaceBinding namespace="ns1" aliases="xsd1-a xsd1-b"/> <namespaceBinding namespace="ns2" aliases="xsd2-v1"/> <!-- list all applicable instances; same as for rule bindings --> <documentAlias>doc1</documentAlias> <documentAlias>doc2-v1-a</documentAlias> <documentAlias>doc2-v1-b</documentAlias> </schemaBinding> <schemaBinding> <namespaceBinding namespace="ns1" aliases="xsd1-a xsd1-b"/> <namespaceBinding namespace="ns2" aliases="xsd2-v2"/> <documentAlias>doc1</documentAlias> <documentAlias>doc2-v2</documentAlias> </schemaBinding> </schemaBindings> <definitions schemaComplete="true"> <!-- schema documents for xsd1-a, xsd1-b, xsd2-v1, xsd2-v2 --> </definitions>
There
are
cases
where
many
instance
documents
use
the
same
schema.
In
this
case,
it
is
desirable
to
have
a
default
schema
binding
rather
than
specifying
a
schemaBinding
that
lists
all
these
instance
documents.
The
defaultSchema
can
be
used
cover
to
instance
documents
that
are
not
included
in
any otherschemaBinding
as in the following example.
<schemaBindings> <!-- The "defaultSchema" element corresponds to a schema that governs all instance documents *not* included in any "schemaBinding". --> <defaultSchema> <!-- all "namespaceBinding" children together build the schema --> <namespaceBinding namespace="ns1" aliases="ns1.xsd"/> <namespaceBinding namespace="ns2" aliases="ns2.xsd"/> </defaultSchema> </schemaBindings>
The goal of SML-IF is to enable the exchange of SML models. However, this interoperability goal is affected by several aspects of SML models.
Use of the SML URI Reference Scheme as defined in the SML specification is the only guaranteed way of achieving interoperability for all SML references in the model. Use of any other reference scheme requires that the consumer know about its use in the document and understand how to dereference it.
SML
documents
can
be
included
by
reference
using
the
locator
element
and,
therefore,
are
not
directly
embedded
in
the
SML-IF
document.
This
can
be
very
useful,
especially
when
the
SML-IF
document
is
large
or
when
the
documents
are
readily
accessible
to
the
consumer.
However,
the
locator
element
may
be
ignored
by
the
consumer,
may
not
resolve,
or
may
resolve
to
different
resources
in
different
contexts.
Because
of
these
uncertainties,
interoperability
is
not
guaranteed
when
documents
are
included
by
reference.
The SML-IF document may be schema-incomplete [ 4.4 Schema Bindings ]. An SML model represented by a schema-incomplete SML-IF document is not necessarily invalid. However, SML-IF cannot guarantee interoperability for a schema-incomplete SML-IF document.
This section normatively defines the Service Modeling Language Interchange Format (SML-IF). It defines the requirements that SML-IF documents must adhere to and how URI references contained in them are to be interpreted by consumers of SML-IF documents.
SML-IF defines two levels of conformance for SML-IF Documents:
Minimal Conformance: A minimally conforming SML-IF Document MUST adhere to all SML-IF document requirements as described in the normative sections of this specification.
Reference Conformance: A referentially conforming SML-IF Document MUST adhere to all SML-IF document requirements as described in the normative sections of this specification. In addition, each non-null SML reference in the document MUST be an instance of the SML URI Reference Scheme [ SML 1.1 ].
A conforming SML-IF Producer MUST be able to generate a referentially conforming SML-IF Document from an SML model.
A conforming SML-IF Consumer MUST process a conforming SML-IF Document using, in whole or part, semantics defined by this specification. It is OPTIONAL that a conforming SML-IF Consumer process all elements defined in this specification, but any element that is processed MUST be processed according to the requirements stated in the normative sections of this specification. In particular, if a conforming SML-IF Consumer performs interchange set validation , then that process MUST be performed as described in this specification.
The purpose of SML-IF is to package the set of documents that constitute an SML model into a standard format so that it can be exchanged in a standard way.
An SML-IF document MUST be a well-formed XML document [ XML ].
An SML-IF document MUST be valid under the XML Schema given in Appendix A.
The definition and instance documents packaged by an SML-IF document MAY form a valid SML model but it is not required to do so.
Each
document
in
the
interchange
set
MUST
be
represented
in
the
SML-IF
document
by
a
separate
document
element
as
follows:
Each
definition
document
in
the
interchange
set
MUST
appear
as
a
descendant
of
a
model/definitions/document
element.
The
order
of
the
document
children
is
not
significant.
Each
instance
document
in
the
interchange
set
MUST
appear
as
a
descendant
of
a
model/instances/document
element.
The
order
of
the
document
children
is
not
significant.
Each document in the interchange set MUST be included in the SML-IF document either as an embedded document (where the document to be included is embedded in the SML-IF document) or by including a reference to the document.
Documents that are to be embedded in the SML-IF document MUST be embedded as text or in an encoded format as follows:
If
the
document
is
embedded
as
text,
it
MUST
be
included
as
the
content
of
a
model/definitions/document/data
element
if
it
is
a
definition
document
or
a
model/instances/document/data
element
if
it
is
an
instance
document.
There
Each
model/*/document/data
element
MUST
be
contain
at
most
one
document
embedded
in
each
model/*/document/data
element.
document.
If
the
document
is
embedded
in
an
encoded
format,
then
the
octet
stream
representing
the
document
MUST
be
encoded
in
base64
format.
The
resultant
data
stream
MUST
be
embedded
as
the
content
of
a
model/definitions/document/base64Data
element
if
it
is
a
definition
document
or
a
model/instances/document/base64Data
element
if
it
is
an
instance
document.
There
Each
model/*/document/base64Data
element
MUST
be
contain
at
most
one
document
embedded
in
each
model/*/document/base64Data
element.
document.
Documents
that
contain
a
DTD
MUST
be
embedded
in
this
encoded
format.
When
extracting
an
embedded
document
that
is
contained
in
a
base64Data
element,
an
SML-IF
consumer
MUST
decode
the
content
of
the
base64Data
element
first
and
then
process
the
resulting
document
as
an
embedded
instance
document.
All
embedded
instance
documents
not
encoded
in
base64
MUST
be
processed
as
if
they
contained
the
same
DTD
as
the
one
associated
with
the
SML-IF
document.
If
the
model/*/document/data
element
has
no
child
element,
it
is
said
to
contain
a
vacuous
document.
If
the
model/*/document/base64Data
element
has
a
zero-length
sequence
of
octets
as
its
value,
it
similarly
contains
a
vacuous
document.
If
the
model/*/document/*
element
contains
only
a
vacuous
document,
then
an
SML-IF
consumer
MUST
treat
the
document
as
if
it
is
not
part
of
the
interchange
set
.
Documents that are to be referenced rather than embedded MUST be included as follows:
If
the
document
is
a
definition
document,
the
location
of
the
document
MUST
be
included
as
the
content
of
a
model/definitions/document/locator
element.
If
the
document
is
an
instance
document,
the
location
of
the
document
MUST
be
included
as
the
content
of
a
model/instances/document/locator
element.
SML-IF
specifies
one
way
that
MAY
be
used
to
provide
the
location
of
the
referenced
document,
the
documentURI
element.
An SML-IF consumer MAY choose to locate a referenced document. If an SML-IF consumer chooses not to locate a referenced document or if it attempts to locate the referenced document and this attempt fails, then the SML-IF consumer MUST treat the referenced document as if it is not part of the interchange set . If either of these conditions occurs, the SML-IF consumer SHOULD make its invoker aware of this condition.
The
smlif:schemaComplete
attribute
is
defined
on
the
definitions
element.
The
attribute
indicates
whether
or
not
all
the
definition
documents
required
for
interchange
set
validation
are
included
in
the
interchange
set
.
If
schemaComplete
has
the
value
true
or
1
,
then
schemas
used
for
interchange
set
validation
MUST
contain
only
schema
components
declared
in
built-in
components
or
in
model
definition
documents
within
the
interchange
set.
If
schemaComplete
has
the
value
false
or
0
,
then
this
specification
does
not
constrain
whether
or
not
definition
documents
required
for
interchange
set
validation
of
the
interchange
set
are
retrieved
from
outside
the
interchange
set.
An
SML-IF
producer
MAY
specify
the
version
of
the
SML-IF
specification
with
which
conformance
is
declared
by
including
the
version
number
of
the
relevant
specification
as
the
value
of
the
SMLIFVersion
attribute
in
the
document's
model
element.
This
value
MUST
be
1.1
for
documents
conforming
with
the
current
specification.
SML-IF
Consumers
MUST
attempt
to
process
an
SML-IF
document
regardless
of
the
value
of
the
SMLIFVersion
attribute.
Therefore,
That
is,
an
SML-IF
Consumer
MUST
NOT
reject
the
document
simply
on
the
basis
that
it
has
a
different
version
solely
because
of
value
of
the
specification.
SMLIFVersion
attribute.
Note:
This note is non-normative: Requiring consumers to continue processing in the face of unknown version values makes it easier to deploy documents that support future versions of this specification.
SML-IF uses URI equality extensively to handle references among documents in the interchange set. To determine whether two URIs are equal, consumers MUST perform case sensitive codepoint-by-codepoint comparison of the corresponding characters in the URI references.
In
addition
to
containing
or
referring
to
one
of
the
documents
in
the
interchange
set,
set
,
each
document
element
contains
a
set
of
zero
or
more
elements
that
are
used
to
describe
aliases
of
the
document.
Conceptually,
each
document
in
the
interchange
set
has
the
following
two
properties:
A URI reference that complies with the “absolute-URI” production as defined in RFC 3986 ([ IETF RFC 3986 ]), to serve as the base URI for relative references in this document.
A set of URI references that comply with the “absolute-URI” production as defined in RFC 3986 ([ IETF RFC 3986 ]), used to identify this document.
The
SML_IF
consumers
MUST
compute
the
value
of
{base
URI}
is
computed
as
follows:
If
the
document
has
a
docInfo/aliases/primaryAlias
element,
let
U
be
its
actual
value,
then
If
U
is
a
relative
reference,
let
B
be
the
actual
value
of
the
/model/identify/baseURI
element
(which
MUST
exist),
then
{base
URI}
is
the
result
of
transforming
U
into
an
absolute
URI,
using
B
as
the
base
URI.
Otherwise {base URI} is U .
Otherwise
if
the
/model/identify/baseURI
element
is
present,
then
{base
URI}
is
the
actual
value
of
the
/model/identify/baseURI
element.
Otherwise {base URI} has no value.
The
SML_IF
consumers
MUST
compute
the
value
of
the
content
of
{aliases}
is
computed
as
follows:
For
each
primaryAlias
or
alias
child
under
the
model
document’s
*/docInfo/aliases
,
there
is
a
corresponding
member
in
the
{aliases}
.
Let
U
be
the
actual
value
of
such
child
element:
The
word
alias
in
the
next
sections,
unless
otherwise
specified,
is
a
shorthand
for
“is
a
member
of
the
{aliases}”
.
As
a
consequence
of
the
above
property
definitions,
the
actual
value
of
/model/identify/baseURI
,
primaryAlias
or
alias
elements
MUST
NOT
contain
fragment
components.
Aliases MUST be unique. That is, there MUST NOT exist two model documents whose {aliases} properties overlap.
This specification defines two levels of base URI values to be used by relative URI references defined in documents in the interchange set:
A base URI value scoped to the interchange set, called the interchange set level .
A base URI value scoped to a single model document (definition or instance) level, called the document level .
There are several combinations of these to consider:
When the interchange set contains no relative URI references subject to SML-IF URI processing (see 5.3.3 URI Reference Processing ), both levels may be omitted.
When relative URI references subject to SML-IF URI processing exist in the interchange set and all have the same base URI value, the interchange set level is the suggested alternative.
When relative URI references subject to SML-IF URI processing exists in the interchange set and all have different base URI values, the document level is the suggested alternative.
When relative URI references subject to SML-IF URI processing exist in the interchange set and they use a mixture of base URI values, some the same and some different, both levels may be used.
If a document in the interchange set contains a relative URI reference subject to SML-IF URI processing, then it MUST NOT have a value for its {base URI} property.
When processing an SML-IF document, there are 3 categories of URI references that may need to be resolved:
schemaLocation
attributes
on
xs:include
and
xs:redefine
in
schema
documents,
when
they
are
model
definition
documents.
URI references specified in instances of SML reference schemes that use target-complete identifiers [ SML 1.1 ].
URI references specified in instances of SML reference schemes that do not use target-complete identifiers.
It
is
clear
which
references
fall
into
category
#1.
An
example
of
category
#2
is
URI
references
used
in
SML
references
that
use
the
SML
URI
reference
scheme.
When
new
references
schemes
that
use
URI
references
are
defined,
whether
they
fall
into
category
#2
or
#3
will
be
clear
from
the
reference
scheme
definitions.
Resolution
of
URI
references
in
category
#3
is
defined
in
their
respective
scheme
definitions.
It
is
also
possible
to
have
reference
schemes
that
do
not
use
URI
references.
Again,
their
Their
resolution
is
governed
by
their
scheme
definitions
and
is
not
covered
by
this
section.
To
process
a
URI
reference
UR
that
is
within
categories
#1
or
#2
above,
an
SML-IF
processor
MUST
perform
the
following
steps
are
performed:
steps:
Determine the document D that possibly contains the target:
If UR contains only a fragment component, then D is the model document that contains UR .
Otherwise
If UR has a fragment component, then let UR' be the URI reference formed by removing the fragment component; otherwise let UR' be UR .
If UR' is a relative reference, then transform UR' to form an (absolute) URI U , using the containing document’s {base URI} as the base URI, as defined in section 5 of RFC 3986 ([ IETF RFC 3986 ]); otherwise let U be UR' .
If there exists a model document with an alias URI that is equal to U ( 5.3.1 URI equality ), then D is that document; otherwise D has no value.
If D has no value, then
If
UR
is
within
category
#1
(
schemaLocation
),
then
the
SML-IF
document
does
not
contain
the
target
schema
document.
Whether
the
consumer
continues
to
dereference
UR
or
U
is
governed
by
other
sections
of
this
specification.
Otherwise ( R is within category #2, used in an SML reference) UR has no target.
If D is a schema document that is also a model definition document in the interchange set, then
If
UR
is
within
category
#1
(
schemaLocation
),
and
it
does
not
contain
a
fragment
component,
then
UR
targets
the
root
element
of
D
.
Otherwise ( UR contains a fragment component or is within category #2) UR has no target.
If D is a model instance document in the interchange set, then
If
UR
is
within
category
#1
(
schemaLocation
),
then
it
has
no
target.
If UR does not contain a fragment component, then it targets the root element of D .
Otherwise ( UR is within category #2 and contains a fragment component) the fragment component of UR is applied to the root element of D , which may result in 0, 1, or many target elements.
Otherwise ( D is another kind of document in the interchange set) UR has no target.
To associate SML rule or schema documents with the subset of documents in the model to which they apply, SML-IF uses a combination of the alias mechanism described above [ 5.3.2 Document Aliases ] and URI prefix matching.
Two URIs, one called the prefix , and one called the target participate in URI prefix matching. The target is said to match the prefix if and only if the target, truncated to the length of the prefix, is equal to the prefix as defined in section 5.3.1 URI equality .
A rule binding is an association of a set of one or more rule documents with a set of zero or more model documents. The documents associated with a given rule document are said to be "bound" to it. For a model to be valid, every document in the model must conform to the constraints defined by every rule document it is bound to. It is permissible for a rule document to have no bindings associated with it, and for a model document to be bound to zero rule documents.
The
ruleBinding
element
is
used
in
SML-IF
to
express
rule
bindings.
In
any
given
binding
the
set
of
rule
documents
is
that
subset
of
rule
documents
in
the
interchange
set
with
an
alias
that
matches
the
URI
prefix
given
by
the
content
of
the
ruleAlias
element.
The
set
of
model
documents
in
the
binding
is
that
subset
of
the
documents
in
the
interchange
set
with
an
alias
that
matches
the
URI
prefix
given
by
the
content
of
the
documentAlias
element.
If
the
documentAlias
element
is
omitted
in
a
ruleBinding
,
the
set
of
model
documents
in
the
binding
is
all
documents
in
the
interchange
set.
SML-IF
Consumers
consumers
MAY
choose
to
extend
the
sets
of
documents
involved
in
bindings
to
include
documents
not
contained
in
the
interchange
set.
For
example,
if
an
SML-IF
document
is
used
to
represent
a
model
fragment
that
is
intended
to
be
merged
with
some
other
model,
it
is
entirely
possible
that
some
or
all
of
the
bindings
may
involve
not
just
the
documents
in
the
interchange
set,
but
documents
in
the
other
model.
SML-IF
consumers
MAY
choose
to
ignore
the
schemaBindings
element
when
present
in
the
SML-IF
document,
in
which
case
the
consumer
SHOULD
make
its
invoker
aware
of
this
situation.
If
an
SML-IF
consumer
chooses
to
process
the
schemaBindings
element,
then,
as
part
of
the
interchange
set
validation
,
for
every
schema
binding
SB
in
the
model,
i.e.
every
/model/schemaBindings/schemaBinding
element,
the
SML-IF
consumer
MUST
perform
the
following
steps
for
instance
document
validation.
Compose
a
schema
using
all
documents
specified
under
all
SB
's
namespaceBinding
children.
Whenever
an
import
for
a
namespace
N
is
encountered,
perform
the
following
steps.
If
there
is
a
namespaceBinding
child
of
SB
whose
namespace
attribute
matches
N
,
then
components
from
schema
documents
listed
in
the
corresponding
aliases
attribute
are
used.
As
with
rule
bindings,
URI
prefixing
[
5.4.1
URI
prefix
matching
Prefix
Matching
]
is
used
for
matching
schema
document
aliases.
At
most
one
namespaceBinding
is
allowed
per
namespace
N
within
a
given
SB
.
If
more
than
one
namespace
binding
exists
for
the
namespace
as
part
of
a
single
schema
binding,
the
SML-IF
document
is
in
error.
If
the
set
of
aliases
for
namespace
N
is
empty,
the
namespace
has
no
schema
documents
defining
it
in
the
schema
binding.
Otherwise, if there are schema documents in the SML-IF document whose targetNamespace is N , then components from all those schema documents are used.
Otherwise,
if
this
is
a
schema-complete
SML-IF
document
(
/model/definitions/@schemaComplete
=
"true"),
then
no
component
from
N
(other
than
built-ins)
is
included
in
the
schema
being
composed.
Otherwise,
it
is
implementation-defined
whether
an
SML-IF
consumer
tries
MAY
attempt
to
retrieve
components
for
N
from
outside
the
SML-IF
document.
Whenever
an
include
or
redefine
is
encountered,
the
schemaLocation
is
used
to
match
aliases
of
schema
documents,
as
with
base
SML-IF.
If there is a schema document in the SML-IF document matching that alias, then that document is used.
Otherwise,
if
this
is
a
schema-complete
SML-IF
document,
then
the
include
or
redefine
is
unresolved
(which
is
allowed
by
XML
Schema
validity
assessment
rules).
Otherwise,
it
is
implementation-defined
whether
an
SML-IF
consumer
tries
MAY
attempt
to
resolve
include
or
redefine
to
schema
documents
outside
the
SML-IF
document.
The
An
SML-IF
consumer
MUST
validate
the
instance
documents
that
are
referenced
in
the
documentAlias
element
of
SB
MUST
be
validated
against
the
schema
constructed
in
steps
1
through
3.
sml:target*
and
SML
identity
constraints
can
now
be
checked.
Similar
to
documentAlias
under
ruleBinding
elements
[
5.4
5.4.2
Rule
Bindings
],
each
documentAlias
can
refer
to
multiple
documents
via
URI
prefixing.
If
an
SML-IF
consumer
chooses
to
process
the
schemaBindings
element
and
if
the
optional
defaultSchema
element
is
present,
then
an
SML-IF
consumer
MUST
compose
a
default
schema
from
this
element
following
rules
1
to
3
above,
replacing
SB
in
the
text
with
DS
(i.e.,
the
/model/schemaBindings/defaultSchema
element).
Otherwise,
an
SML-IF
consumers
MUST
compose
a
default
schema
using
*all*
schema
documents
included
in
the
SML-IF
document.
An
SML-IF
consumer
MUST
use
this
default
schema
to
validate
those
SML
instance
documents
that
are
not
included
in
any
schemaBinding
.
Whether
or
not
a
schemaBindings
element
is
present
or
is
ignored,
SML-IF
consumers
MUST
process
an
include
or
redefine
element
as
described
in
step
3
above.
The
common
use
case
where
match-all
namespace
matching
is
desired
can
be
achieved
by
omitting
schemaBindings
without
introducing
any
additional
complexity
into
the
SML-IF
document.
<?xml version="1.0" encoding="utf-8"?> <!-- /* * Copyright © @@@@ World Wide Web Consortium, * * (Massachusetts Institute of Technology, European Research Consortium for * Informatics and Mathematics, Keio University). All Rights Reserved. This * work is distributed under the W3C® Document License [1] in the hope that * it will be useful, but WITHOUT ANY WARRANTY; without even the implied * warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. * * [1] http://www.w3.org/Consortium/Legal/2002/copyright-documents-20021231 */ --> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:smlif="http://www.w3.org/@@@@/@@/sml-if" targetNamespace="http://www.w3.org/@@@@/@@/sml-if" elementFormDefault="qualified" blockDefault="#all" version="1.0" xml:lang="EN" finalDefault="" attributeFormDefault="unqualified"> <xs:element name="model" type="smlif:modelType"/> <xs:complexType name="modelType" mixed="false"> <xs:sequence> <xs:element name="identity" type="smlif:identityType"/> <xs:element ref="smlif:ruleBindings" minOccurs="0"/> <xs:element ref="smlif:schemaBindings" minOccurs="0"/> <xs:element name="definitions" type="smlif:documentCollectionType" minOccurs="0"/> <xs:element name="instances" type="smlif:documentCollectionType" minOccurs="0"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="SMLIFVersion" type="xs:token" use="optional"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> <!-- If there is a need for localized string values, e.g. in displayName or description, the sml:locid global attribute can be used --> <xs:complexType name="identityType" mixed="false"> <xs:sequence> <xs:element name="name" type="smlif:uriType"/> <xs:element name="version" type="smlif:tokenType" minOccurs="0"/> <xs:element name="displayName" type="smlif:displayType" minOccurs="0"/> <xs:element name="description" type="smlif:displayType" minOccurs="0"/> <xs:element name="baseURI" type="smlif:uriType" minOccurs="0" maxOccurs="1"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> <xs:complexType name="displayType" mixed="false"> <xs:simpleContent> <xs:extension base="xs:string"> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:extension> </xs:simpleContent> </xs:complexType> <xs:complexType name="tokenType" mixed="false"> <xs:simpleContent> <xs:extension base="xs:token"> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:extension> </xs:simpleContent> </xs:complexType> <xs:complexType name="uriType" mixed="false"> <xs:simpleContent> <xs:extension base="xs:anyURI"> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:extension> </xs:simpleContent> </xs:complexType> <xs:element name="ruleBindings" type="smlif:ruleBindingCollectionType"/> <xs:complexType name="ruleBindingCollectionType" mixed="false"> <xs:sequence> <xs:element ref="smlif:ruleBinding" maxOccurs="unbounded"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> <xs:element name="ruleBinding" type="smlif:ruleBindingType"/> <xs:complexType name="ruleBindingType" mixed="false"> <xs:sequence> <xs:element name="documentAlias" type="smlif:uriType" minOccurs="0"/> <xs:element name="ruleAlias" type="smlif:uriType"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> <xs:element name="schemaBindings" type="smlif:schemaBindingCollectionType"/> <xs:complexType name="schemaBindingCollectionType" mixed="false"> <xs:sequence> <xs:element ref="smlif:defaultSchema" minOccurs="0"/> <xs:element ref="smlif:schemaBinding" minOccurs="0" maxOccurs="unbounded"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> <xs:element name="schemaBinding" type="smlif:schemaBindingType"/> <xs:complexType name="schemaBindingType" mixed="false"> <xs:sequence> <xs:element ref="smlif:namespaceBinding"/> <xs:element name="documentAlias" type="smlif:uriType" minOccurs="0" maxOccurs="unbounded"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> <xs:element name="namespaceBinding" type="smlif:namespaceBindingType"/> <xs:complexType name="namespaceBindingType" mixed="false"> <xs:attribute name="namespace" type="xs:NCName" use="optional"/> <xs:attribute name="aliases" use="required"> <xs:simpleType> <xs:list itemType="xs:anyURI"/> </xs:simpleType> </xs:attribute> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> <xs:element name="defaultSchema" type="smlif:defaultSchemaType"/> <xs:complexType name="defaultSchemaType" mixed="false"> <xs:sequence> <xs:element ref="smlif:namespaceBinding" minOccurs="0" maxOccurs="unbounded"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> <xs:complexType name="documentCollectionType" mixed="false"> <xs:sequence> <xs:element ref="smlif:document" maxOccurs="unbounded"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="schemaComplete" type="xs:boolean" use="required"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> <xs:element name="document" type="smlif:documentType"/> <xs:complexType name="documentType" mixed="false"> <xs:sequence> <xs:element ref="smlif:docinfo" minOccurs="0"/> <xs:choice> <xs:element name="data" type="smlif:dataType"/> <xs:element name="base64Data" type="smlif:base64DataType"/> <xs:element name="locator" type="smlif:locatorType"/> </xs:choice> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> <xs:element name="docinfo" type="smlif:docinfoType"/> <xs:complexType name="docinfoType" mixed="false"> <xs:sequence> <xs:element ref="smlif:aliases" minOccurs="0"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> <xs:element name="aliases" type="smlif:aliasCollectionType"/> <xs:complexType name="aliasCollectionType" mixed="false"> <xs:sequence> <xs:element name="primaryAlias" type="smlif:uriType" minOccurs="0" maxOccurs="1"/> <xs:element name="alias" type="smlif:uriType" minOccurs="0" maxOccurs="unbounded"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> <xs:complexType name="dataType" mixed="false"> <xs:annotation> <xs:documentation> The wildcard with processContents "skip" matches the root element of the model document being packaged. The value of processContents is set to "skip" so that the contained element is not processed for schema validation. As a result, validity of the packaged document will not affect validity of the IF document itself. </xs:documentation> </xs:annotation> <xs:sequence> <xs:any processContents="skip" minOccurs="0" namespace="##any" maxOccurs="1"/> </xs:sequence> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> <xs:complexType name="base64DataType" mixed="false"> <xs:simpleContent> <xs:extension base="xs:base64Binary"> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:extension> </xs:simpleContent> </xs:complexType> <xs:complexType name="locatorType" mixed="false"> <xs:sequence> <xs:element name="documentURI" type="smlif:uriType" minOccurs="0"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> </xs:schema>
The
following
example
shows
how
the
sml:locid
attribute
can
be
used
to
define
the
translation
information
for
the
interchange
set identity attributes:
<model xmlns="http://www.w3.org/@@@@/@@/sml-if" version="1.0" xmlns:sml="http://www.w3.org/@@@@/@@/sml"> xmlns:lang="http://www.university.example.org/translation/core"> <identity> <name sml:locid="lang:nameID“>Univerity interchange set</name> <description sml:locid="lang:descrID"> This document contains a list of universities.</description> </identity> </model>
In
this
example,
the
{namespace
name}
URI
information
of
the
sml:locid
attribute
can
be
used
to
define
the
location
for
the
resource
containing
the
translated
text.
The
smlif:name
and
smlif:description
elements
are
using
the
same
URI
to
identify
the
resource
containing
the
translated
strings:
<xmlns:lang="http://www.university.example.org/translation/core">
The
{local
part}
information
of
the
sml:locid
attribute
can
be
used
to
define
the
id
of
the
text
being
translated.
This
information
will
be
used
to
locate
the
translation
of
the
name
and
description
texts
within
the
translation
resource.