A Beta release of "Content Model-driven Fedora 3.0" has been announced
by the Fedora Commons Project developers. The CMA is described as a
powerful, new integrated structure for persisting and delivering the
essential characteristics of digital objects in Fedora while simplifying
its use. Fedora Commons is the home of the unique Fedora open source
software, a robust integrated repository-centered platform that enables
the storage, access and management of virtually any kind of digital
content. Prior implementations of the Fedora Repository utilized a set
of specialized digital objects as a functional and persistence framework.
All of these objects conform to the same basic object model. Digital
objects in CMA are conceptually similar in prior versions of Fedora
though some important implementation details have changed. Fedora still
implements a compound digital object design consisting of an XML
encapsulation (now FOXML 1.1) and a set of bitstreams identified by
the "Datastream" XML element. We can also assemble multi-object groups
of related digital objects as before using semantic technologies. In
the CMA, the "content model" is defined as a formal model that describes
the characteristics of one or more digital objects. A digital object
may be said to conform to a content model. In the CMA, the concept of
the content model is comprehensive, including all possible
characteristics which are needed to enable persistence and delivery
of the content. This can include structural, behavioral and semantic
information. It can also include a description of the permitted,
excluded, and required relationships to other digital objects or
identifiable entities. "Following the rules of Fedora identifiers, the
identifier of the CModel object can be encoded within a URI. We will
describe the rationale for this decision in a later section but this
approach provides two immediate benefits: (1) it provides a scheme
which works within the Fedora architecture with minimal impact, and (2)
it is compatible with the Web architecture, RDF and OWL. We can even
build functionality using just the knowledge of the identifier without
creating a content model. Having a uniform method for identifying a
digital object's class maximizes interoperability..."
Friday, December 28, 2007
W3C Last Call Working Drafts for SVG Print 1.2 (Language, Primer)
W3C announced that the SVG Working Group has published Last Call Working
Drafts for the "SVG Print 1.2, Part 2: Language" and "SVG Print 1.2,
Part 1: Primer" specifications. The "Language" document defines features
of the Scalable Vector Graphics (SVG) Language that are specifically for
printing environments. The "Primer" explains the technical background
and gives guidelines on how to use the SVG Print specification with SVG
1.2 Tiny and SVG 1.2 Full modules for printing; it is purely informative
and has no conformance statements. Because of its scalable, geometric
nature, SVG is inherently better suited to print than raster image formats.
The same geometry can be displayed on screen and on a printer, with
identical layout in both but taking advantage of the higher resolution
of print media. The same colors can be output, using an ICC-based color
managed workflow on the printer and an sRGB fallback approximation on
screen. This has been true since SVG 1.0, and so SVG has been used in
print workflows (for example, in combination with XSL FO) as well as on
screen. However, SVG also has dynamic, interactive features such as
declarative animation, scripting, timed elements like audio and video,
and user interaction such as event flow and link activation. None of these
are applicable to a print context. SVG 1.1 gives static and dynamic
conformance classes, but further guidance on what exactly SVG Printers
should do with such general content is helpful. The SVG Print
specification defines processing rules for handling such general purpose
content which was not designed to be printed, but which may be
encountered anyhow. It is possible to generate SVG which is exclusively
intended for print (for example, a printer which natively understands SVG).
This content might be created in an illustration program, or it might
be an output from a layout program, such as an XSL-FO renderer; or it
might be generated by an SVG Print driver. W3C's Graphics Activity has
been developing graphics specifications for over ten years: "Scalable
Vector Graphics (SVG), the current effort of the Activity, brings the
powerful combination of interactive, animated two-dimensional vector
graphics and Extensible Markup Language (XML). WebCGM 2.0 is used mainly
in industrial and defence technical documents. Earlier work was concerned
with Portable Network Graphics (PNG) and with WebCGM 1.0."
Drafts for the "SVG Print 1.2, Part 2: Language" and "SVG Print 1.2,
Part 1: Primer" specifications. The "Language" document defines features
of the Scalable Vector Graphics (SVG) Language that are specifically for
printing environments. The "Primer" explains the technical background
and gives guidelines on how to use the SVG Print specification with SVG
1.2 Tiny and SVG 1.2 Full modules for printing; it is purely informative
and has no conformance statements. Because of its scalable, geometric
nature, SVG is inherently better suited to print than raster image formats.
The same geometry can be displayed on screen and on a printer, with
identical layout in both but taking advantage of the higher resolution
of print media. The same colors can be output, using an ICC-based color
managed workflow on the printer and an sRGB fallback approximation on
screen. This has been true since SVG 1.0, and so SVG has been used in
print workflows (for example, in combination with XSL FO) as well as on
screen. However, SVG also has dynamic, interactive features such as
declarative animation, scripting, timed elements like audio and video,
and user interaction such as event flow and link activation. None of these
are applicable to a print context. SVG 1.1 gives static and dynamic
conformance classes, but further guidance on what exactly SVG Printers
should do with such general content is helpful. The SVG Print
specification defines processing rules for handling such general purpose
content which was not designed to be printed, but which may be
encountered anyhow. It is possible to generate SVG which is exclusively
intended for print (for example, a printer which natively understands SVG).
This content might be created in an illustration program, or it might
be an output from a layout program, such as an XSL-FO renderer; or it
might be generated by an SVG Print driver. W3C's Graphics Activity has
been developing graphics specifications for over ten years: "Scalable
Vector Graphics (SVG), the current effort of the Activity, brings the
powerful combination of interactive, animated two-dimensional vector
graphics and Extensible Markup Language (XML). WebCGM 2.0 is used mainly
in industrial and defence technical documents. Earlier work was concerned
with Portable Network Graphics (PNG) and with WebCGM 1.0."
Using Intelligence Community Security Markings (IC-ISM) with NIEM
NIEM (National Information Exchange Model) is a partnership of the
U.S. Department of Justice and the Department of Homeland Security.
Developers recently announced an interim solution designed to allow
users to use IC-ISM within NIEM 2.0. The IC-ISM standard is an XML
Schema described in the IC-ISM Data Element Dictionary and the
Implementation Guide. It is one of the Intelligence Community (IC)
Metadata Standards for Information Assurance and is the preferred
way to apply information security markings within XML instances. Until
recently, the schema for the Intelligence Community Information
Security Marking (IC-ISM) standard was considered for official use
only (FOUO) and could not be published. Therefore, NIEM 2.0 could not
integrate components of IC-ISM without publishing the IC-ISM schema.
Actions have now been taken to restore the ability to use IC-ISM within
NIEM 2.0 and future releases. To facilitate the preferred (future)
use of the IC-ISM standard in NIEM will require, in sequence:
(1) Completion of the NIEM versioning architecture; (2) A
forward-compatible release update to NIEM 2.0; (3) Minor change(s)
to the NIEM NDR; (4) Governance Committee review and approval.
U.S. Department of Justice and the Department of Homeland Security.
Developers recently announced an interim solution designed to allow
users to use IC-ISM within NIEM 2.0. The IC-ISM standard is an XML
Schema described in the IC-ISM Data Element Dictionary and the
Implementation Guide. It is one of the Intelligence Community (IC)
Metadata Standards for Information Assurance and is the preferred
way to apply information security markings within XML instances. Until
recently, the schema for the Intelligence Community Information
Security Marking (IC-ISM) standard was considered for official use
only (FOUO) and could not be published. Therefore, NIEM 2.0 could not
integrate components of IC-ISM without publishing the IC-ISM schema.
Actions have now been taken to restore the ability to use IC-ISM within
NIEM 2.0 and future releases. To facilitate the preferred (future)
use of the IC-ISM standard in NIEM will require, in sequence:
(1) Completion of the NIEM versioning architecture; (2) A
forward-compatible release update to NIEM 2.0; (3) Minor change(s)
to the NIEM NDR; (4) Governance Committee review and approval.
WSO2 Registry Version 0.1
On behalf of the WSO2 Registry team, Paul Fremantle announced the version
0.1 release of the WSO2 Registry. "This early release demonstrates a
completely REST-based approach to storing, searching and managing SOA
metadata. The Registry stores any kind of resource in a simple JDBC
driven store, and uses AtomPub as a web API to allow publishing and
searching. The Registry has been deliberately designed to bring social
interaction to the world of SOA metadata by including tagging, comments,
rating and a wiki-like approach to SOA registries... WSO2 Registry
enables you to store, catalog, index and manage your enterprise meta
data in a simple, scalable and easy-to-use model. It is designed around
community concepts such as tags, comments, ratings, users and roles.
Think of the registry as a structured wiki designed to help you manage
your meta-data in a simple business-friendly system. In addition, the
registry allows you to store more unstructured data such as Word
documents, Excel spreadsheets and text formats. Using these approaches,
you can build a catalog of enterprise information ranging from services,
service descriptions to employee data and on going projects. WSO2
Registry can be deployed in Application Servers and access using the
Web UI or the APP interface. It can also be used as a Java library
inside other Java programs as a resource store with all community
features and versioning."
0.1 release of the WSO2 Registry. "This early release demonstrates a
completely REST-based approach to storing, searching and managing SOA
metadata. The Registry stores any kind of resource in a simple JDBC
driven store, and uses AtomPub as a web API to allow publishing and
searching. The Registry has been deliberately designed to bring social
interaction to the world of SOA metadata by including tagging, comments,
rating and a wiki-like approach to SOA registries... WSO2 Registry
enables you to store, catalog, index and manage your enterprise meta
data in a simple, scalable and easy-to-use model. It is designed around
community concepts such as tags, comments, ratings, users and roles.
Think of the registry as a structured wiki designed to help you manage
your meta-data in a simple business-friendly system. In addition, the
registry allows you to store more unstructured data such as Word
documents, Excel spreadsheets and text formats. Using these approaches,
you can build a catalog of enterprise information ranging from services,
service descriptions to employee data and on going projects. WSO2
Registry can be deployed in Application Servers and access using the
Web UI or the APP interface. It can also be used as a Java library
inside other Java programs as a resource store with all community
features and versioning."
XML Moves to mySQL
The unification of XML and SQL relational data has taken another
significant step forward recently with the introduction of significant
new XML functionality in mySQL, the world's most popular open source
database. In versions 5.1 and 6.0, mySQL adds the ability to retrieve
tables (and JOINS) as XML results, to retrieve SQL schemas as XML files,
to both select content via a subset of XPath and to update content using
similar functions, and the like. I think the ramifications for this are
actually quite huge. I've known for some time that much of the driving
technology behind Web 2.0? is the power of SQL databases, with the bulk
of those to date being mySQL databases. While enterprise level databases
such as Oracle 10i+, IBM db2, and Microsoft SQL Server have long had XML
capabilities, they also account collectively for a surprisingly small
amount of the outward facing databases on the web, especially compared
to mySQL. However, this has also has the unfortunate effect of promoting
a relational database model as the prime one for the web, diminishing
the utility of XML there and increasing the fragility of Web 2.0
applications. With native XML support moving into mySQL, it opens up a
chance for XML developers to start working within that community, and
and also raises some significant issues with regard to how unstructured
and semi-structured data is stored, retrieved and manipulated... The XML
support for mySQL is not yet at the level where it can support XQuery,
but I think that this will come in time given the degree of support they
have for the XPath specification. Keep an eye on this development.
Related reference: Jon Stephens, "Using XML in MySQL 5.1 and 6.0." More Information See also Jon Stephens' article: Click Here
significant step forward recently with the introduction of significant
new XML functionality in mySQL, the world's most popular open source
database. In versions 5.1 and 6.0, mySQL adds the ability to retrieve
tables (and JOINS) as XML results, to retrieve SQL schemas as XML files,
to both select content via a subset of XPath and to update content using
similar functions, and the like. I think the ramifications for this are
actually quite huge. I've known for some time that much of the driving
technology behind Web 2.0? is the power of SQL databases, with the bulk
of those to date being mySQL databases. While enterprise level databases
such as Oracle 10i+, IBM db2, and Microsoft SQL Server have long had XML
capabilities, they also account collectively for a surprisingly small
amount of the outward facing databases on the web, especially compared
to mySQL. However, this has also has the unfortunate effect of promoting
a relational database model as the prime one for the web, diminishing
the utility of XML there and increasing the fragility of Web 2.0
applications. With native XML support moving into mySQL, it opens up a
chance for XML developers to start working within that community, and
and also raises some significant issues with regard to how unstructured
and semi-structured data is stored, retrieved and manipulated... The XML
support for mySQL is not yet at the level where it can support XQuery,
but I think that this will come in time given the degree of support they
have for the XPath specification. Keep an eye on this development.
Related reference: Jon Stephens, "Using XML in MySQL 5.1 and 6.0." More Information See also Jon Stephens' article: Click Here
W3C Drafts for XML Interchange (EXI): Format, Best Practices, Primer
W3C's Efficient XML Interchange (EXI) Working Group recently published
three documents. First Public Working Drafts have been issued for
"Efficient XML Interchange (EXI) Best Practice" and "Efficient XML
Interchange (EXI) Primer." An updated WD is available for the "Efficient
XML Interchange (EXI) Format 1.0" specification. Efficient XML
Interchange (EXI) is a very compact representation for the Extensible
Markup Language (XML) Information Set that is intended to simultaneously
optimize performance and the utilization of computational resources.
The EXI format uses a hybrid approach drawn from the information and
formal language theories, plus practical techniques verified by
measurements, for entropy encoding XML information. Using a relatively
simple algorithm, which is amenable to fast and compact implementation,
and a small set of data types, it reliably produces efficient encodings
of XML event streams. The event production system and format definition
of EXI are presented. The "Best Practices" document provides explanations
of format features and techniques to support interoperable information
exchanges using EXI. While intended primarily as a practical guide for
systems architects and programmers, it also presents information suitable
for the general reader interested in EXI's intended role in the expanding
Web. The "EXI Primer" a non-normative document intended to provide an
easily readable technical background on the Efficient XML Interchange
(EXI) format. It is oriented towards quickly understanding how the EXI
format can be used in practice and how options can be set to achieve
specific needs. Section 2 "Concepts" describes the structure of an EXI
document and introduces the notions of EXI header, EXI body and EXI
grammar which are fundamental to the understanding of the EXI format.
Additional details about data type representation, compression, and
their interaction with other format features are presented. Section 3
"Efficient XML Interchange by Example" provides a detailed, bit-level
description of a schema-less example. More Information See also the W3C Efficient XML Interchange Working Group: Click Here
three documents. First Public Working Drafts have been issued for
"Efficient XML Interchange (EXI) Best Practice" and "Efficient XML
Interchange (EXI) Primer." An updated WD is available for the "Efficient
XML Interchange (EXI) Format 1.0" specification. Efficient XML
Interchange (EXI) is a very compact representation for the Extensible
Markup Language (XML) Information Set that is intended to simultaneously
optimize performance and the utilization of computational resources.
The EXI format uses a hybrid approach drawn from the information and
formal language theories, plus practical techniques verified by
measurements, for entropy encoding XML information. Using a relatively
simple algorithm, which is amenable to fast and compact implementation,
and a small set of data types, it reliably produces efficient encodings
of XML event streams. The event production system and format definition
of EXI are presented. The "Best Practices" document provides explanations
of format features and techniques to support interoperable information
exchanges using EXI. While intended primarily as a practical guide for
systems architects and programmers, it also presents information suitable
for the general reader interested in EXI's intended role in the expanding
Web. The "EXI Primer" a non-normative document intended to provide an
easily readable technical background on the Efficient XML Interchange
(EXI) format. It is oriented towards quickly understanding how the EXI
format can be used in practice and how options can be set to achieve
specific needs. Section 2 "Concepts" describes the structure of an EXI
document and introduces the notions of EXI header, EXI body and EXI
grammar which are fundamental to the understanding of the EXI format.
Additional details about data type representation, compression, and
their interaction with other format features are presented. Section 3
"Efficient XML Interchange by Example" provides a detailed, bit-level
description of a schema-less example. More Information See also the W3C Efficient XML Interchange Working Group: Click Here
A Document Format for Expressing Authorization Policies to Tackle Spam
Members of the IETF SIPPING Working Group have published an updated draft
defining SPIT authorization documents that use SAML. The problem of SPAM
for Internet Telephony (SPIT) is an imminent challenge and only the
combination of several techniques can provide a framework for dealing
with unwanted communication. The responsibility for filtering or blocking
calls can belong to different elements in the call flow and may depend
on various factors. This document defines an authorization based policy
language that allows end users to upload anti-SPIT policies to
intermediaries, such as SIP proxies. These policies mitigate unwanted SIP
communications. It extends the Common Policy authorization framework with
additional conditions and actions. The new conditions match a particular
Session Initiation Protocol (SIP) communication pattern based on a number
of attributes. The range of attributes includes information provided, for
example, by SIP itself, by the SIP identity mechanism, by information
carried within SAML assertions... A SPIT authorization document is an
XML document, formatted according to the schema defined in RFC 4745.
SPIT authorization documents inherit the MIME type of common policy
documents, application/auth-policy+xml. As described in RFC 4745, this
document is composed of rules which contain three parts -- conditions,
actions, and transformations. Each action or transformation, which is
also called a permission, has the property of being a positive grant to
the authorization server to perform the resulting actions, be it allow,
block etc . As a result, there is a well-defined mechanism for combining
actions and transformations obtained from several sources. This
mechanism therefore can be used to filter connection attempts thus
leading to effective SPIT prevention... Policies are XML documents that
are stored at a Proxy Server or a dedicated device. The Rule Maker
therefore needs to use a protocol to create, modify and delete the
authorization policies defined in this document. Such a protocol is
available with the Extensible Markup Language (XML) Configuration
Access Protocol (XCAP), per RFC 4825..." More Information See also SAML references: Click Here
defining SPIT authorization documents that use SAML. The problem of SPAM
for Internet Telephony (SPIT) is an imminent challenge and only the
combination of several techniques can provide a framework for dealing
with unwanted communication. The responsibility for filtering or blocking
calls can belong to different elements in the call flow and may depend
on various factors. This document defines an authorization based policy
language that allows end users to upload anti-SPIT policies to
intermediaries, such as SIP proxies. These policies mitigate unwanted SIP
communications. It extends the Common Policy authorization framework with
additional conditions and actions. The new conditions match a particular
Session Initiation Protocol (SIP) communication pattern based on a number
of attributes. The range of attributes includes information provided, for
example, by SIP itself, by the SIP identity mechanism, by information
carried within SAML assertions... A SPIT authorization document is an
XML document, formatted according to the schema defined in RFC 4745.
SPIT authorization documents inherit the MIME type of common policy
documents, application/auth-policy+xml. As described in RFC 4745, this
document is composed of rules which contain three parts -- conditions,
actions, and transformations. Each action or transformation, which is
also called a permission, has the property of being a positive grant to
the authorization server to perform the resulting actions, be it allow,
block etc . As a result, there is a well-defined mechanism for combining
actions and transformations obtained from several sources. This
mechanism therefore can be used to filter connection attempts thus
leading to effective SPIT prevention... Policies are XML documents that
are stored at a Proxy Server or a dedicated device. The Rule Maker
therefore needs to use a protocol to create, modify and delete the
authorization policies defined in this document. Such a protocol is
available with the Extensible Markup Language (XML) Configuration
Access Protocol (XCAP), per RFC 4825..." More Information See also SAML references: Click Here
Subscribe to:
Posts (Atom)