Copyright � 2001 W3C� (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use, and software licensing rules apply.
The XML standard supports logical documents composed of possibly several entities. It may be desirable to view or edit one or more of the entities or parts of entities while having no interest, need, or ability to view or edit the entire document. The problem, then, is how to provide to a recipient of such a fragment the appropriate information about the context that fragment had in the larger document that is not available to the recipient. The XML Fragment WG is chartered with defining a way to send fragments of an XML document—regardless of whether the fragments are predetermined entities or not—without having to send all of the containing document up to the part in question. This document defines Version 1.0 of the [eventual] W3C Recommendation that addresses this issue.
This specification is being put forth as a Candidate Recommendation by the XML Core Working Group. This document is a revision of the Working Draft dated 1999 June 30 which had incorporated suggestions received during last call review, comments, and further deliberations of the W3C XML Fragment Working Group. For background on this work, please see the XML Activity Statement. The Working Group believes this specification to be stable and invites implementation feedback during this period.
The duration of Candidate Recommendation is expected to last approximately three months (ending the end of April 2001). All persons are encouraged to review and implement this specification and return comments to the publicly archived mailing list<EMAIL_ADDRESS>Should this specification prove impossible to implement, the Working Group will return the document to Working Draft status and make necessary changes. Otherwise, the Working Group anticipates asking the W3C Director to advance this document to Proposed Recommendation.
This is still a draft document and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to cite a W3C Candidate Recommendation as other than "work in progress." A list of current W3C working drafts can be found at http://www.w3.org/TR.
1 Overview
2 Scope
3 Terminology
4 Fragment context information set
5 Fragment context specification
notation
5.1 Overview of the fcs
5.2 Formal notation
description
5.3 Semantics of a fragment context
specification
5.4 An fcs
example
5.4.1 The parent Docbook book document
5.4.2 The fragment body
5.4.3 The fragment context specification
document
6 Conformance
A References
A.1 Normative
References
A.2 Other
References
B Packaging and interchanging
fragments (Non-Normative)
C Examples (Non-Normative)
C.1 One element of
a transaction record as a fragment
C.2 Use of
external entities and MIME packaging
C.3 Indexes into a
large document
D Design Principles
(Non-Normative)
E Acknowledgments (Non-Normative)
F Changes from Previous Public Working
Drafts (Non-Normative)
F.1 Changes
between the March 3 and April 2 WD
F.2 Changes
between the April 2 and June 19 WD
F.3 Changes
between the June 19 WD and the CR
The XML standard supports logical documents composed of possibly several entities. It may be desirable to view or edit one or more of the entities or parts of entities while having no interest, need, or ability to view or edit the entire document. The problem, then, is how to provide to a recipient of such a fragment the appropriate information about the context that fragment had in the larger document that is not available to the recipient.
In the case of many XML documents, it is suboptimal to have to receive and parse the entire document when only a fragment of it is desired. If the user asked to look at chapter 20, one shouldn't need to parse 19 whole chapters before getting to the part of interest. The goal of this activity is to define a way to enable processing of small parts of an XML document without having to process everything up to the part in question. This can be done regardless of whether the parts are entities or not, and the parts can either be viewed immediately or accumulated for later use, assembly, or other processing.
Conceptually, the holder of the complete source document considers a fragment of that document and, using the notation to be defined by this activity, constructs a fragment context specification. The object representing the fragment removed from its source document is called the fragment body. The fragment context specification and the fragment body are transmitted to the recipient. The storage object in which the fragment body is transmitted is call the fragment entity. (In some packaging schemes, the fragment context specification may also be embedded in the fragment entity.) The recipient processes the fragment context specification to determine the proper parser state for the context at the beginning of the fragment and uses that information to enable the XML parser to parse the fragment body. (The terms “sender,” “recipient,” “transmit,” are used throughout this document to describe the process of fragment interchange. It should be noted, however, that there are many feasible and useful scenarios for fragment interchange, and in some cases, the “sender” and “recipient” may be on the same machine, node, system, or network, and may even be the same tool in different guises.)
The challenge is that an isolated element from an XML document may not contain quite enough information to be parsed correctly. The goal of this activity is to enable senders to provide the remaining information required so that systems can interchange any XML elements they choose, from books or chapters all the way down to paragraphs, tables, footnotes, book titles, and so on, without having to manage each as a separate entity or having to risk incorrect parsing due to loss of context.
To accomplish these ends, this Recommendation defines:
exact constraints on what portions of an XML document may constitute fragments to be supported by this Recommendation;
the set of information (fragment context information) that allows for successful parsing as well as for viewing or editing of a fragment in a useful and important set of cases;
the notation (i.e., language) in which this information will be described (the fragment context specification);
some mechanisms for associating this information with a fragment.
This Recommendation enables interchanging portions of XML documents while retaining the ability to parse them correctly (that is, as they would be parsed in their originating document context), and, as far as practical, to be formatted, edited, and otherwise processed in useful ways.
The goal of this activity is to define a way to send fragments of an XML document—regardless of whether the fragments are predetermined entities or not—without having to send all of the containing document up to the part in question. The delivered parts can either be viewed or edited immediately or accumulated for later use, assembly, or other processing; what the receiving application does with the information—and issues involved with the possible “return” of such a fragment to the original sender—is beyond the scope of this activity. While implementations of this Recommendation may serve as part of a larger system that allows for “fragment reuse,” the many important issues about reuse of XML text and “concurrent multiple author environments” are beyond the scope of this Recommendation.
The point of the fragment context information is to provide information that is not available in the fragment body itself but that would be available from the complete XML document. Specifically, any information not available from the XML document (which may include an external subset) as a whole (plus knowledge of the location of the fragment body within the document) is out of scope for inclusion in the fragment context information. Such information may well be useful and important metadata in a variety of applications, but there are (or need to be) other mechanisms for handling this information.
This Recommendation considers fragments of XML as defined by [XML 1.0] and [XML Namespaces]. It is explicitly noted that this version of this Recommendation does not take into account work such as that taking place in the XML Schema Working Group; insofar as such work by other currently active working groups places new requirements on a fragment interchange solution, those requirements would be input to a new version of the fragment interchange specification that may become a chartered activity at a later date.
It is also explicitly noted that this Recommendation does not consider interchange of information that is not well-formed XML; in particular, issues specific to the interchange of fragments of SGML (including HTML)—other than such SGML that is, in fact, also well-formed XML—are not within scope of this Recommendation.
This list is sorted “logically” as opposed to alphabetically. In an entry, phrases in parentheses are “optional” modifiers; whether they are used explicitly or not, we are still talking about the same thing for the purposed of this Recommendation.
defined in [XML 1.0], Well-formed XML documents
defined in [XML 1.0], production [78] extParsedEnt
A region (consecutive sequence of characters) of an XML document is said to be (well-)balanced if it matches production [43] content of [XML 1.0]. Informally this means that, if the region includes any part of the markup of any construct, it contains all of the markup of that construct (e.g., in the case of elements, all of both the start and end tag).
A general term to refer to part of an XML document, plus possibly some extra information, that may be useful to use and interchange in the absence of the rest of the XML document. See the rest of the fragment-related terms when a more precise definition is required.
The process of receiving and/or parsing of a fragment by a fragment-aware application.
A well-balanced region of an XML document being considered as (logically and/or physically) separate from the rest of the document for the purposes of defining it as a fragment. Also, that part of a fragment entity that consists solely of the well-balanced region from the complete XML document. When it is important to indicate that a reference is specifically to the version of the fragment body still physically part of the originating (parent) document, this document will use the term “fragment body in situ.”
The abstract set of information—divorced from any particular language/syntax/notation—that constitutes the “parser state” at the point when a parser processing the complete XML document encounters (but has not yet processed) the first character of (what would be) the fragment body.
(sometimes abbreviated fci) The subset of the context information that we decide will be expressible in any fragment context specification language. Also the abstract set of information represented by a particular fragment context specification.
(sometimes abbreviated fcs) A valid string in the language (notation) that this Recommendation defines that describes a set of fragment context information. Also the particular string in a fragment entity or fragment package that describes the fragment's context information.
To associate in some specified way a fragment body with a fragment context specification. This may include some way of combining both into a single XML-encoded object; combining both in some multipart MIME or archiving encoding; or linking the two via some sort of referencing, co-referencing, or third-party referencing scheme.
The storage object in which the fragment body is stored and/or transmitted during the process of fragment interchange.
The object actually transmitted during the process of fragment interchange. Though one might expect this is the same thing as a fragment entity, the terms may or may not be synonyms in all cases; one could define a packaging mechanism whereby the fragment context specification is transmitted without the fragment body (which presumably gets retrieved later) in which case the fragment package is the fragment context specification, and the fragment entity gets retrieved later.
As defined in this Recommendation, a valid fragment context specification (fcs) is a well-formed XML document. Therefore, when considered as a document, an fcs is sometimes referred to as a fragment context specification document (or fcs document). A fragment context specification document may also be a fragment package (i.e., it may be the actual object transmitted to effect fragment interchange).
In the context of this Recommendation, words such as send/receive (and sender/recipient) are used to described the general process of fragment interchange. There are many feasible and useful scenarios for fragment interchange, and in some cases, the “sender” and “recipient” may be on the same machine, node, system, or network, and may even be the same tool in different guises. The only constant assumption is that the sender has access to and knowledge of the entire (parental) document from which the fragment comes, and the recipient is in possession only of the fragment package (though nothing in this Recommendation precludes the possibility of the recipient using the information in the fragment package, if available, to attempt to fetch more information from the sender).
In this section, numbers in brackets refer to productions in [XML 1.0]. The following information shall constitute the complete fragment context information (fci) set:
A reference to the external subset (extSubset [30]), by specifying an ExternalID [75] for it.
Internal subset information using some or all of the following:
A reference to an “externalized copy” of the internal subset (presumably generated by placing the internal declarations into a storage object such as extSubset [30]), presumably by specifying an ExternalID [75] for it.
Some or all of markupdecl [29] and/or PEReference [69] allowed in an XML document's internal subset; note that PEReference implies expansion of what could be more external entities; also note that markupdecl includes comments, processing instructions, and declarations for elements, attribute lists, entities, and notations.
Ancestor information for the fragment body.
Sibling information for the fragment body.
Sibling information for any of the ancestors.
Element content (aka descendant) information for any of the ancestors or siblings.
Attribute information (attribute name and value) for:
any of the ancestors;
any of the siblings of the fragment body;
any of the siblings of any of the ancestors;
any of the descendants of any of the ancestors or siblings.
A reference to the original/parental document by specifying an ExternalID [75] for it.
A reference to the fragment body within the original/parental document by specifying an ExternalID [75].
From the above list, the following items affect proper (validating) parsing of the fragment:
External subset
Internal subset
(Preceding) Siblings of the fragment body
The following items, while they cannot affect proper parsing, are usually considered part of the basic, structural XML parse tree:
Ancestors
(Preceding) Siblings of ancestors
Following siblings of the fragment body and its ancestors
Ancestor and sibling descendants
Attributes
The following items, while not usually considered part of the basic, structural XML parse tree, are clearly definable pieces of information known or computable by any XML processor that is processing the parent document:
XML declaration information of the parent document. Note that we have defined a fragment package to be an XML document. That is, the fragment package would contain its own XMLDecl-like information as necessary, so the fci itself need not include that information.
A reference to the parent document.
A reference to the fragment body in situ.
The previous section defined the logical set of information possible in a fragment context. This section describes the notation in which to express a specific fragment context specification. All information would be optional; how much gets included in any particular fragment context specification is up to the sender and recipient, and how this gets determined is outside of the scope of this Recommendation.
Note:
While what gets included in any particular fragment context specification is outside of the scope of this Recommendation, some knowledge of the target application can help determine an appropriate level for the fcs. For example, if the target application is a user agent that will use Cascading Style Sheets (CSS) to display the fragment, the following information is necessary and sufficient given the current level of CSS selector capability: previous siblings of the fragment body, all ancestors of the fragment body, previous siblings of each of those ancestors, and all attributes on all those siblings and ancestors.
Note:
A given fragment context specification need not necessarily provide the ability to specify the complete set of fragment context information described in the previous section. In particular, because the XML 1.0 syntax for declarations is difficult to embed within an XML instance, the specific fragment context specification notation defined by this Recommendation does not allow for inline inclusion of internal subset information within the FCS. Internal subset information can only be included in the FCS via a reference to an “externalized copy” of the internal subset. Inline internal subset information may be more feasible once an instance syntax for declarations is defined, and such may be considered in future versions of the Fragment Interchange specification.
The syntax used is XML itself. In particular, a fragment context specification (fcs) is written as a single root XML element allowing up to five attributes and containing a subtree of other elements (possibly with attributes). The root element (and the element serving as the placeholder for the fragment body) comes from Fragment Interchange namespace, a specific namespace defined by this Recommendation; the contained subtree of elements comes from the namespace(s) of the document from which this fragment comes. For the purposes of exposition in this section, we assume namespace declarations such as the following are in force:
xmlns:f="http://www.w3.org/2001/02/xml-fragment" xmlns="http://www.oasis-open.org/docbook/DocbookSchema" |
That is, within this example, f
is the
local prefix referring to the Fragment Interchange namespace defined
by this Recommendation for fragment-interchange related
components, and the default namespace is that in effect
in the parent document at the beginning of the fragment
body in situ.
The element type for the single root element for the
fcs shall be f:fcs
(where f
is
whatever namespace prefix is mapped to the Fragment Interchange namespace). It
allows up to five attributes, each of whose value shall
be a URI reference [[RFC 2396]].
The attribute names and the meaning of their values are
as follows:
a URI reference to the external subset
a URI reference to the internal subset
a URI reference to the parent document
a URI reference to the fragment body in situ within the parent document
The content of the f:fcs
element shall be
a subtree of elements (possibly with attribute value
assignments) from the parent document's namespace. This
subtree shall provide all the structural context for the
fragment body including various information about
ancestor and sibling elements and attributes by mimicking
the (relevant) context within this parent document. No
data characters (mixed content) are allowed within the
f:fcs
element. The special empty element
f:fragbody
shall be used to indicate the
placement of the fragment body within the specified
context. It has one significant attribute with meaning as
follows:
a URI reference [[RFC 2396]] to the fragment body
For example, consider a fragment body that consists of
listitems
2 and 3 of an
orderedlist
(indicated to be enumerated with
arabic numbers by the numeration
attribute
on the orderedlist
element) within the
second sect1
within the first
chapter
within the first part
within the body
of a book
.
Assume that the external subset (aka “DTD”)
is in the file Docbook.dtd
on the OASIS Open
web server, the parent document is in
mybook.xml
on Acme's web server, and that
there need be no internal subset given as part of the
fcs. Then the fcs for this fragment body might look
like:
<f:fcs xmlns:f="http://www.w3.org/2001/02/xml-fragment" extref="http://www.oasis-open.org/docbook/docbook/3.0/docbook.dtd" parentref="http://www.acme.com/~me/mydocs/mybook.xml" xmlns="http://www.oasis-open.org/docbook/DocbookSchema"> <book> <part> <chapter> <sect1/> <sect1> <orderedlist numeration="arabic"> <listitem/> <f:fragbody/> </orderedlist> </sect1> </chapter> </part> </book> </f:fcs> |
A formal notation for the fcs
element
used in the examples of the previous section follows.
Therein, the following terms are defined in either the
“Extensible Markup Language (XML) 1.0” ([XML 1.0]) or “Namespaces in
XML” ([XML Namespaces])
Recommendations: NCName,
AttValue,
Eq, S, Attribute,
STag,
ETag,
EmptyElemTag,
CharData,
Reference,
CDSect, PI, Comment, prolog,
and Misc.
| [1] | FCSelement |
::= | FCSstag S? FCSelementContent
S?
FCSetag |
|
| [2] | FCSstag |
::= | '<' NCName
':fcs' ((S 'extref'
Eq
AttValue)
| (S 'intref'
Eq
AttValue)
| (S
'parentref' Eq AttValue)
| (S
'sourcelocn' Eq AttValue)
| (S Attribute))*
S?
'>' |
[Constraint: FCS Constraint: Fragment Namespace] |
| [3] | FCSelementContent |
::= | EmptyElemTag
| STag FCScontent ETag |
FCSfragbody |
[Constraint: FCS Constraint: Exactly One Fragbody] |
| [4] | FCSfragbody |
::= | '<' NCName
':fragbody' ((S
'fragbodyref' Eq AttValue)
| (S Attribute))*
S?
'/>' |
[Constraint: FCS Constraint: Same Namespace Prefix] |
| [5] | FCSetag |
::= | '</' NCName
':fcs' S?
'>' |
|
| [6] | FCScontent |
::= | (FCSelementContent | CharData
| Reference
| CDSect
| PI | Comment)* |
Constraint: FCS Constraint: Fragment Namespace
The namespace prefix represented by NCName in the production for FCSstag (and, therefore necessarily, FCSetag) must have been declared on one of the ancestors of the FCS element and must be associated with the Fragment Interchange Namespace URI defined in this Recommendation.
Constraint: FCS Constraint: Exactly One Fragbody
There must be exactly one fragbody
(FCSfragbody) element in the
fcs.
Constraint: FCS Constraint: Same Namespace Prefix
The namespace prefix (NCName) used in the production for FCSfragbody must be the same as that used in the production for FCSstag.
[Definition: The
fragment Interchange namespace shall be associated
with the following URI:
http://www.w3.org/2001/02/xml-fragment
.]
In the productions for FCSstag and FCSfragbody, there can be any number of other attribute assignments, all of which are ignored by the fragment context specification processor. Per XML 1.0 compliance, there can be at most one assignment to any given attribute including the specifically mentioned attributes. (Since there is no “and” connector in EBNF, this restriction is difficult to show directly in the EBNF, hence this restriction in prose; however, this prose restriction is normative.)
In the production for FCScontent, the fragment processor can optionally expand any References that it can expand. Then all CDSects, PIs, Comments, remaining References, and CharData (including whitespace, S) are ignored by the FCS processor.
Note:
If a Reference in FCScontent is expanded and the expansion includes element structure, that element structure is considered part of the fcs as it would if it had been included originally in its expanded form in the fcs. However, since expansion of any Reference in FCScontent is optional on the part of the fragment context specification processor, any sender for which such expansion is important should do the expansion when creating the fragment package.
| [7] | FCS |
::= | prolog
FCSelement Misc* |
[Constraint: FCS Constraint: Well-formed, namespace complete] |
Constraint: FCS Constraint: Well-formed, namespace complete
A fragment context specification shall constitute a well-formed document conforming to the “Extensible Markup Language (XML) 1.0” ([XML 1.0]) and “Namespaces in XML” ([XML Namespaces]) Recommendations. In particular, if there are entity references in the fcs, the fcs document must comply with the Entity declared well-formedness constraint per the “Extensible Markup Language (XML) 1.0” ([XML 1.0]) Recommendation. (Appropriate declarations would appear in the internal subset of the fcs document.) Furthermore, for any use of namespaces, the fcs document must comply with the Namespace declared namespace constraint per the “Namespaces in XML” ([XML Namespaces]) Recommendation.
Note:
Generally, a fragment context specification document
would be the well-formed document consisting simply of
the f:fcs
element (and its contents) with
no prolog. However, a prolog is always allowable and
might be necessary when some declarations are required
to satisfy the Entity
declared well-formedness constraint.
Note:
Since all of the components in prolog are optional, an FCSelement by itself is an allowable fragment context specification, and this Recommendation does not preclude some packaging scheme from combining an FCSelement along with a fragment body as shown in some of the examples in B Packaging and interchanging fragments and C Examples.
The previous section formally defines a fragment
context specification to be a well-formed XML document
consisting of a single f:fcs
element with
optional attributes and some content. The
f:fcs
element's content consists of optional
stuff from the parent document (from which the fragment
body is taken) plus a single f:fragbody
element with optional attributes. The f:fcs
and f:fragbody
elements come from a
namespace defined by this Recommendation and have certain
specific semantics relative to fragment interchange as
defined by this section.
While it is important to be able to package a fragment body with its fcs, it is expected that a general XML-friendly packaging mechanism will be developed by the W3C that would satisfy this requirement. Meanwhile, this Recommendation defines a simple association mechanism that doesn't rely on a packaging scheme. Applications and interchange partners may agree on any packaging mechanism to aid in fragment interchange—this is beyond the scope of this Recommendation.
The fcs document is a well-formed XML document that
(1) provides the fragment context and (2) provides a
reference to the fragment body. Because it is
well-formed, existing XML processors can be used to
process fcs documents. To support this fragment
interchange Recommendation, an application must also
understand the semantics of the f:fcs
and
f:fragbody
elements and their attributes and
process accordingly.
Specifically, the fragbodyref
attribute
on the fragbody
element is a URI reference
[[RFC 2396]] to the fragment body.
A fragment-aware processor is expected to resolve this
reference and process the referenced fragment body in the
context specified by the fcs. None of the attributes on
the fcs
element have required semantics with
respect to fragment processing; they are provided
(optionally) for the application's use at its
discretion.
Note:
For example, a browser might bring up an fcs
document, “expand” the reference to the
fragment body (i.e., put a copy of the fragment body in
place of the fragbody
element), and then
ignore (e.g., not display) the part of the document
that was originally the fcs, thereby displaying (in the
proper context) only the part of the document that was
originally the fragment body.
Note:
The fragbody
element and its
fragbodyref
attribute are in many ways
logically equivalent to an external entity reference or
an XLink reference with an “embed”
semantic.
The following example shows the complete set of
information relative to interchanging the two
listitem
s for the Docbook book mentioned in
5.1 Overview of the
fcs.
The parent document, in
~me/mydocs/mybook.xml
on Acme's web server,
is a Docbook book document whose contents is outlined in
the first subsection below. The fragment body of interest
consists of listitems
2 and 3 of the
orderedlist
(indicated to be enumerated with
arabic numbers by the numeration
attribute
on the orderedlist
element) within the
second sect1
within the first
chapter
within the first part
within the body
of this book
.
The external subset (aka “DTD”) is in the
file Docbook.dtd
on the OASIS Open web
server.
The following represents the parent document from which the fragment body in question comes.
<?xml version="1.0"?> <!DOCTYPE book SYSTEM "http://www.oasis-open.org/docbook/docbook/3.0/docbook.dtd"> <book xmlns="http://www.oasis-open.org/docbook/DocbookSchema"> <part> <chapter><title>The title for chapter one</title> <sect1><title>The title for section one in chapter one</title> <p>The first paragraph....</p> <p>....</p> </sect1> <sect1><title>The title for section two in chapter one</title> <p>An introductory paragraph preceding an ordered list.</p> <orderedlist numeration="arabic"> <listitem><para>This is the first listitem in this ordered list.</para></listitem> <listitem><para>This is the second listitem within the second sect1 of the first chapter within the first part of a Docbook <quote>book</quote> document.</para></listitem> <listitem><para>And this is the next listitem.</para></listitem> <listitem><para>This is the fourth and last listitem.</para></listitem> </orderedlist> <p>Another paragraph....</p> </sect1> </chapter> <chapter><title>More content</title> <p>More chapters, sections, paragraphs, and such....</p> </chapter> </part> </book> |
Note that the declaration of the default namespace
on the <book>
tag isn't required for
fragment interchange, but is shown for the purposes of
completeness of this example.
The following shows the fragment body in a separate
file ready for interchange. For the purposes of this
example, we are assuming that this is in the file
~me/mydocs/myfrag.xml
on Acme's web
server.
<listitem><para>This is the second listitem within the second sect1 of the first chapter within the first part of a Docbook <quote>book</quote> document.</para></listitem> <listitem><para>And this is the next listitem.</para></listitem> |
The following shows what the fcs document might look
like for the above parent document and fragment body.
If this were in the file (e.g.,
myfrag.fcs
), when this file is sent to any
recipient with a fragment-aware tool, that tool should
be able to access and process the desired fragment
body.
<f:fcs xmlns:f="http://www.w3.org/2001/02/xml-fragment" extref="http://www.oasis-open.org/docbook/docbook/3.0/docbook.dtd" parentref="http://www.acme.com/~me/mydocs/mybook.xml" xmlns="http://www.oasis-open.org/docbook/DocbookSchema"> <book> <part> <chapter> <sect1/> <sect1> <orderedlist numeration="arabic"> <listitem/> <f:fragbody fragbodyref="http://www.acme.com/~me/mydocs/myfrag.xml"/> </orderedlist> </sect1> </chapter> </part> </book> </f:fcs> |
Note that the fragbodyref
value, which
is a URI reference [[RFC 2396]],
could be a URL, a file name, a MIME content id, etc.,
depending on the MIME type of the referenced resource.
Also note that the parentref
value above
is only there for the information of the receiving
application, but is not necessary for this example's
operation. Likewise, the extref
would only
be necessary if the receiving application wanted to be
able to do validation.
A fragment conforms to this XML Fragment Interchange Recommendation if it adheres to all syntactic requirements defined in this Recommendation. A fragment is syntactically correct if all of the requirements specified in Section 5.2 are met.
Application software acting as recipient conforms to the XML Fragment Interchange Recommendation if it interprets all conforming XML fragments (as defined above) according to all required semantics prescribed by this Recommendation, and, for any optional semantics it chooses to support, supports them in the way prescribed. Specifically, conforming application software must be able to parse all conforming valid fragment context specification information whether it chooses to support its semantics or not. Application software acting as sender conforms to the XML Fragment Interchange Recommendation if it creates conforming XML fragments (as defined above) and, if including fragment context information, includes conforming fragment context information according to the requirements in section 4.
If fragment context information is included with a transmitted fragment, then it should conform according to the requirements in section 4.
It is a design goal of this Recommendation to define a fragment context specification to be a well-formed XML document. However, a fragment body itself need not be a well-formed document, but only well-balanced. While it is important to be able to package a fragment body with its fcs, it is expected that a general XML-friendly packaging mechanism—beyond the scope of this Recommendation—will be developed by the W3C that would satisfy this requirement. Meanwhile, applications and interchange partners may agree on any packaging mechanism to aid in fragment interchange. This appendix gives some non-normative examples of such possible packaging mechanisms.
The fcs
element could be packaged along
with the fragment body by combining them into a single
well-formed XML document. For the purposes of fragment
interchange packaging, one could define a simple
“document type” consisting of a
“head” part containing the fcs (and,
potentially, other) metadata followed by a
“body” part containing the fragment body
itself.
In the following template, p
is defined as
the local prefix referring to the namespace defined for the
packaging structure, and f
, as in previous
sections, is the local prefix referring to the namespace
defined by this Recommendation for fragment-interchange
related components. (Note that this template example
assumes that no explicit namespace prefixes are present in
the fragment body. If the fragment body contains explicit
namespace prefixes whose declarations are not also included
in the fragment body, then additional namespace
declarations would be necessary on the
<p:package>
or
<f:fcs>
element. If the parent document
does not use namespaces at all, then no default namespace
declaration is needed for the fcs or its package.)
The format of a complete fragment package might be outlined as follows:
<p:package xmlns:p="http://www.w3.org/2001/02/xml-package" xmlns:f="http://www.w3.org/2001/02/xml-fragment" xmlns="{the default namespace in effect at the start of the fragment body in the parent document}"> <f:fcs {the ref attributes on the fcs tag}> {the content of the fcs with no namespace prefixes necessary except that on the <f:fragbody/> element} </f:fcs> <p:body> {the fragment body with no namespace prefixes necessary} </p:body> </p:package> |
Note:
The above template includes indentation and blank
lines to help display the overall structure of the
package. However, all whitespace within the
p:body
element is significant and
is therefore part of the fragment body. Therefore, the
packaging process can introduce no whitespace (including
record ends immediately following
<p:body>
and immediately preceding
</p:body>
) within the
p:body
element.
The following examples are designed in general to address the potential reference scenarios described in [XML Fragment Requirements Document].
The user has an XML document that represents a customer's set of purchases at a bookstore, and the part of that document that represents the purchase of a particular book needs to be represented as a fragment.
Here is the original XML document for the transaction:
<?xml version="1.0"?> <transaction TID="19990207-1234"> <purchase> <book> <Author>Frank Herbert</Author> <Title>Dune</Title> <Edition>Hardcover Reissue edition (April 1984)</Edition> <ISBN>0399128964</ISBN> <Price currency="USD">18.87</Price> <Quantity>1</Quantity> </book> <book> <Author>J. R. R. Tolkien</Author> <Title>The Book of Lost Tales (The History of Middle-Earth)</Title> <Edition>Mass Market Paperback Reprint edition (June 1992)</Edition> <ISBN>0345375211</ISBN> <Price currency="USD">4.79</Price> <Quantity>1</Quantity> </book> </purchase> <refund RID="19990115-2"> <reason TID="19981220-3214">Late delivery</reason> <value currency="USD">5.00</value> </refund> <payment> <client CID="123421"/> <value currency="USD">18.66</value> <creditcard type="MasterCard"> <bank>BankBoston</bank> <owner>Joe J. Bill</owner> <serial>1234567890</serial> <expires>5/99</expires> </creditcard> <status>Waiting for approval</status> </payment> </transaction> |
Here is a fragment representing the second book
element from the above document (the
sourcelocn
attribute on the
f:fcs
element is optional and is shown
merely as an example):
<?xml version="1.0"?> <p:package xmlns:p="http://www.w3.org/2001/02/xml-package"> <p:fcs xmlns:f="http://www.w3.org/2001/02/xml-fragment" sourcelocn="http://acme.com/trans1234#root().child(1,purchase).child(2,book)"> <transaction> <purchase> <book/> <p:fragbody/> </purchase> </transaction> </p:fcs> <p:body> <book> <Author>J. R. R. Tolkien</Author> <Title>The Book of Lost Tales (The History of Middle-Earth)</Title> <Edition>Mass Market Paperback Reprint edition (June 1992)</Edition> <ISBN>0345375211</ISBN> <Price currency="USD">4.79</Price> <Quantity>1</Quantity> </book> </p:body> </p:package> |
A user has an XML document that includes several external entities, and she wants to be able to interchange a fragment that includes a reference to the entities using MIME [[MIME]] packaging. (For references, see also [RFC 2387] and [RFC 2392].)
Here is the original document:
<?xml version="1.0"?> <!DOCTYPE book SYSTEM "http://www.oasis-open.org/docbook/docbook/3.0/docbook.dtd" [ <!ENTITY title "My Book"> <!ENTITY author "me"> <!ENTITY try SYSTEM "try.cgm" NDATA CGM-BINARY> ]> <book> <part> <title>&title;</title> <introduction>This is my book ...</introduction> <author>&author;</author> <chapter type="intro"> <sect1>The introduction ...</sect1> </chapter> <chapter>...</chapter> <chapter> <p>This is a paragraph within the third chapter within the first part of a Docbook <quote>book</quote> document.</p> <p>And this is a succeeding paragraph.</p> <p>And an internal text entity reference &author;.</p> <p>And a reference to an unparsed entity (a CGM graphic): <graphic entityref="try"></graphic></p> </chapter> <chapter>...</chapter> </part> </book> |
Note that the DocBook DTD includes the following (which is therefore not included in the internal subset of this document):
<!NOTATION CGM-BINARY PUBLIC "ISO 8632/3//NOTATION Binary Encoding//EN"> |
Here is a fragment that represents the contents of the third chapter:
<?xml version="1.0"?> <f:fcs xmlns:f="http://www.w3.org/2001/02/xml-fragment" xmlns="http://www.oasis-open.org/docbook/docbook/3.0/docbook.dtd" extref="http://www.oasis-open.org/docbook/docbook/3.0/docbook.dtd" intref="mybook.decls"> <book> <part> <chapter type="intro"/> <chapter/> <chapter> <f:fragbody fragbodyref="chapter3.xml"/> </chapter> </part> </book> </f:fcs> |
Here is the corresponding fragment body:
<p>This is a paragraph within the third chapter within the first part of a Docbook <quote>book</quote> document.</p> <p>And this is a succeeding paragraph.</p> <p>And an internal text entity reference &author;.</p> <p>And a reference to an unparsed entity (a CGM graphic): <graphic entityref="try"></graphic></p> |
Here is the associated internal subset:
<!ENTITY title "My Book"> <!ENTITY author "me"> <!ENTITY try SYSTEM "try.cgm" NDATA CGM-BINARY> |
Here is the external entity (represented in Base 64 encoding, since this is really a binary entity):
ACEAABAiAAEQXwBEQyJTb3VyY2U6IEhTSSAvV01GLXRvLUNHTSBmaWx0ZXIg LyBWZXJzaW9uIDEuMzUgIiAiRGF0ZTogMTk5OS0wMS0xNyIRZgAB//8AARBi AAAQpgAAAAkAFxFGAAAA////EYQwIgAQEYogyAAAAAB//3//AAARvwC3C1RJ TUVTX1JPTUFODFRJTUVTX0lUQUxJQwpUSU1FU19CT0xEEVRJTUVTX0JPTERf SVRBTElDCUhFTFZFVElDQRFIRUxWRVRJQ0FfT0JMSVFVRQ5IRUxWRVRJQ0Ff Qk9MRBZIRUxWRVRJQ0FfQk9MRF9PQkxJUVVFB0NPVVJJRVIOQ09VUklFUl9J VEFMSUMMQ09VUklFUl9CT0xEE0NPVVJJRVJfQk9MRF9JVEFMSUMGU1lNQk9M ABHOAAABQgABAUEABAMqLToR4gABAGEAACAmAAE9NJ9IIEIAASBiAAAgggAA IKIAACDI95D0wAhqCzoAAACAQWj5cAa5/TEJikGGAogCUQGQUGIACEAo+dD/ +v7g+TpRYgACUkwAAQAEAAAAAAAAAABRgBxUggAAABkAGQAAFKCAAJAkAEg/ MoAAQlTb21lIFRleHQAoABA |
And here is an example of MIME packaging used to transmit the fragment context specification, the fragment body, the internal subset, and the external entity within a single stream such as a mail message:
Content-Type: multipart/related; boundary="/04w6evG8XlLl3ft";type="text/xml" --/04w6evG8XlLl3ft Content-Type: text/xml; charset=us-ascii Content-ID: <part1> Content-Disposition: attachment; filename="mybook.decls" <!ENTITY title "My Book"> <!ENTITY author "me"> <!ENTITY try SYSTEM "cid:part2" NDATA CGM-BINARY> --/04w6evG8XlLl3ft Content-Type: image/cgm Content-ID: <part2> Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="try.cgm" ACEAABAiAAEQXwBEQyJTb3VyY2U6IEhTSSAvV01GLXRvLUNHTSBmaWx0ZXIg LyBWZXJzaW9uIDEuMzUgIiAiRGF0ZTogMTk5OS0wMS0xNyIRZgAB//8AARBi AAAQpgAAAAkAFxFGAAAA////EYQwIgAQEYogyAAAAAB//3//AAARvwC3C1RJ TUVTX1JPTUFODFRJTUVTX0lUQUxJQwpUSU1FU19CT0xEEVRJTUVTX0JPTERf SVRBTElDCUhFTFZFVElDQRFIRUxWRVRJQ0FfT0JMSVFVRQ5IRUxWRVRJQ0Ff Qk9MRBZIRUxWRVRJQ0FfQk9MRF9PQkxJUVVFB0NPVVJJRVIOQ09VUklFUl9J VEFMSUMMQ09VUklFUl9CT0xEE0NPVVJJRVJfQk9MRF9JVEFMSUMGU1lNQk9M ABHOAAABQgABAUEABAMqLToR4gABAGEAACAmAAE9NJ9IIEIAASBiAAAgggAA IKIAACDI95D0wAhqCzoAAACAQWj5cAa5/TEJikGGAogCUQGQUGIACEAo+dD/ +v7g+TpRYgACUkwAAQAEAAAAAAAAAABRgBxUggAAABkAGQAAFKCAAJAkAEg/ MoAAQlTb21lIFRleHQAoABA --/04w6evG8XlLl3ft Content-Type: text/xml; charset=us-ascii Content-ID: <part3> Content-Disposition: attachment; filename="chapter3.xml" <p>This is a paragraph within the third chapter within the first part of a Docbook <quote>book</quote> document.</p> <p>And this is a succeeding paragraph.</p> <p>And an internal text entity reference &author;.</p> <p>And a reference to an unparsed entity (a CGM graphic): <graphic entityref="try"></graphic></p> --/04w6evG8XlLl3ft Content-Type: text/xml; charset=us-ascii <?xml version="1.0"?> <f:fcs xmlns:f="http://www.w3.org/2001/02/xml-fragment" xmlns="http://www.oasis-open.org/docbook/docbook/3.0/docbook.dtd" extref="http://www.oasis-open.org/docbook/docbook/3.0/docbook.dtd" intref="cid:part1"> <book> <part> <chapter type="intro"/> <chapter/> <chapter> <f:fragbody fragbodyref="cid:part3"/> </chapter> </part> </book> </f:fcs> --/04w6evG8XlLl3ft-- |
The user has very large XML documents, possibly a gigabyte or more in size, and wishes to be able to view portions of the document without parsing the whole document. In order to do this the user creates an “index” for each document portion (fragment) that they wish to so address. The “index” consists of a fragment context specification in combination with a packaging mechanism designed for quick access to the fragment body. This should be used to view and browse documents with a flat structure, like HTML, on devices where only a part of the document can be parsed or rendered.
<?xml version="1.0"?> <f:fcs xmlns:f="http://www.w3.org/2001/02/xml-fragment" xmlns="" fragbodyref="http://www.w3.org/TR/REC-xml.html#sec-xml-and-sgml" extref="http://www.w3.org/TR/REC-html40-971218/loose.dtd"> <html> <head> <link rel='STYLESHEET' type='text/css' href='/StyleSheets/TR/rec.css'/> </head> <body> <h1>Extensible Markup Language (XML) 1.0</h1> <h2 ID='sec-intro'>1. Introduction</h2> <h3 ID='sec-origin-goals'>1.1 Origin and Goals</h3> <h3 ID='sec-terminology'>1.2 Terminology</h3> <h2 ID='sec-documents'>2. Documents</h2> <h3 ID='sec-well-formed'>2.1 Well-Formed XML Documents</h3> <h3 ID='charsets'>2.2 Characters</h3> <h3 ID='sec-common-syn'>2.3 Common Syntactic Constructs</h3> <h3 ID='syntax'>2.4 Character Data and Markup</h3> <h3 ID='sec-comments'>2.5 Comments</h3> <h3 ID='sec-pi'>2.6 Processing Instructions</h3> <h3 ID='sec-cdata-sect'>2.7 CDATA Sections</h3> <h3 ID='sec-prolog-dtd'>2.8 Prolog and Document Type Declaration</h3> <h3 ID='sec-rmd'>2.9 Standalone Document Declaration</h3> <h3 ID='sec-white-space'>2.10 White Space Handling</h3> <h3 ID='sec-line-ends'>2.11 End-of-Line Handling</h3> <h3 ID='sec-lang-tag'>2.12 Language Identification</h3> <h2 ID='sec-logical-struct'>3. Logical Structures</h2> <h3 ID='sec-starttags'>3.1 Start-Tags, End-Tags, and Empty-Element Tags</h3> <h3 ID='elemdecls'>3.2 Element Type Declarations</h3> <h4 ID='sec-element-content'>3.2.1 Element Content</h4> <h4 ID='sec-mixed-content'>3.2.2 Mixed Content</h4> <h3 ID='attdecls'>3.3 Attribute-List Declarations</h3> <h4 ID='sec-attribute-types'>3.3.1 Attribute Types</h4> <h4 ID='sec-attr-defaults'>3.3.2 Attribute Defaults</h4> <h4 ID='AVNormalize'>3.3.3 Attribute-Value Normalization</h4> <h3 ID='sec-condition-sect'>3.4 Conditional Sections</h3> <h2 ID='sec-physical-struct'>4. Physical Structures</h2> <h3 ID='sec-references'>4.1 Character and Entity References</h3> <h3 ID='sec-entity-decl'>4.2 Entity Declarations</h3> <h4 ID='sec-internal-ent'>4.2.1 Internal Entities</h4> <h4 ID='sec-external-ent'>4.2.2 External Entities</h4> <h3 ID='TextEntities'>4.3 Parsed Entities</h3> <h4 ID='sec-TextDecl'>4.3.1 The Text Declaration</h4> <h4 ID='wf-entities'>4.3.2 Well-Formed Parsed Entities</h4> <h4 ID='charencoding'>4.3.3 Character Encoding in Entities</h4> <h3 ID='entproc'>4.4 XML Processor Treatment of Entities and References</h3> <h4 ID='not-recognized'>4.4.1 Not Recognized</h4> <h4 ID='included'>4.4.2 Included</h4> <h4 ID='include-if-valid'>4.4.3 Included If Validating</h4> <h4 ID='forbidden'>4.4.4 Forbidden</h4> <h4 ID='inliteral'>4.4.5 Included in Literal</h4> <h4 ID='notify'>4.4.6 Notify</h4> <h4 ID='bypass'>4.4.7 Bypassed</h4> <h4 ID='as-PE'>4.4.8 Included as PE</h4> <h3 ID='intern-replacement'>4.5 Construction of Internal Entity Replacement Text</h3> <h3 ID='sec-predefined-ent'>4.6 Predefined Entities</h3> <h3 ID='Notations'>4.7 Notation Declarations</h3> <h3 ID='sec-doc-entity'>4.8 Document Entity</h3> <h2 ID='sec-conformance'>5. Conformance</h2> <h3 ID='proc-types'>5.1 Validating and Non-Validating Processors</h3> <h3 ID='safe-behavior'>5.2 Using XML Processors</h3> <h2 ID='sec-notation'>6. Notation</h2> <h3>Appendices</h3>A. <A ID='sec-bibliography'>References</A> <h3 ID='sec-existing-stds'>A.1 Normative References</h3> <h3 ID='null'>A.2 Other References</h3> <h2 ID='CharClasses'>B. Character Classes</h2> <f:fragbody/> <h2 ID='sec-entexpand'>D. Expansion of Entity and Character References (Non-Normative)</h2> <h2 ID='determinism'>E. Deterministic Content Models (Non-Normative)</h2> <h2 ID='sec-guessing'>F. Autodetection of Character Encodings (Non-Normative)</h2> <h2 ID='sec-xml-wg'>G. W3C XML Working Group (Non-Normative)</h2> </body> </html> </f:fcs> |
In the design of any language, trade-offs in the solution space are necessary. To aid in making these trade-offs the follow design principles were used (the order of these principles is not necessarily significant):
XML fragment specifications should be usable over the internet.
XML fragment specifications should support the specification of context for any well-formed chunk of XML; the definition of a fragment may be broadened to allow any chunk of XML that matches XML's “content” production (production [43]). Chunks of XML that do not match XML's “content” production (i.e., that are not well-formed entities) are specifically out of scope.
XML fragment specifications should be optimized to work with simpler XML fragments (such as those conforming to the simpler XML profile being developed by the XML Syntax WG), though the language should also work with any XML (“the easy stuff should be easy, and the harder stuff should be possible”); working with SGML features not included in XML (including those, such as tag omission, allowed in HTML) is not a goal.
XML fragment specifications should be capable of being specified both in the same storage object as the fragment body itself as well as in a separate object linked in some fashion to the fragment body.
XML fragment specifications should support interaction with XML browsers, editors, repositories, and other XML applications.
SGML features and characteristics not included in XML shall not be taken into consideration in the design of our fragment context specification solution.
It is specifically not a goal that XML fragment specifications be designed in consideration of non-XML HTML browsers, parsers, or other non-XML applications.
Since interoperability is a primary goal, there should be only one language for the fragment context specification rather than multiple “features.” However, since the goal is to provide enough information to parse the fragment, and well-formed XML may not require any extra information to allow it to be parsed, no specific set of context information should be required in all context specifications. (No implementation should choke on any valid piece of context information, but no implementation should be considered non-compliant for choosing to ignore [on the receiving end]—or not include [on the sending end]—a specific piece of context information if doing so makes sense in the particular environment.)
XML fragment specifications should leverage other recommendations and standards, including XML 1.0, XML Namespace, XPointer, XML Information Set, the SGML Open TR9601:1996 on Fragment Interchange, and relevant IETF work.
XML fragment specifications should be human-readable and reasonably clear.
Terseness in XML fragment specification syntax is of minimal importance.
Issues involved with the possible “return” of any fragment to its original context and the determination of the possible validity of the “returned” fragment in its original context are beyond the scope of this activity.
The following participated in the XML Fragment WG during the authoring of this Recommendation:
Paula Angerstein, Vignette
Tim Boland, NIST
Charles Frankston, Microsoft
Paul Grosso, Arbortext
Michael Hyman, Microsoft
Joel Nava, Adobe
Conleth O'Connell, Vignette
Joakim �stman, Citec
Christina Portillo, Boeing
Shriram Revankar, Xerox
Daniel Veillard, W3C
Major changes to the previous public working draft are outlined below. Various other changes have also been made throughout the document.
Added [fragment context specification document] as a defined term.
Added a fragbodyref
attribute to the
fragbody
element ([PROD: 4]) and renamed
the fragbodyref
attribute of the fcs
element to sourcelocn
.
Added a production ([PROD: 7]) to allow an fcs to have a prolog; added a well-formed, namespace complete FCS Constraint.
Wrote a new subsection of the fcs notation chapter (5.3 Semantics of a fragment context specification) describing the Semantics of a fragment context specification.
Wrote a new subsection of the fcs notation chapter (5.4 An fcs example) giving a complete example of a fragment context specification use (without packaging).
Moved the chapter on packaging to the non-normative back matter (B Packaging and interchanging fragments).
Did major editing of the appendix of examples (C Examples).
Major changes to the previous public working draft are outlined below. Various other minor changes have also been made to the document.
The Status section was updated.
References to XPointer usage were replaced with references to “URI reference [RFC 2396].”
Some items in the fragment context information set were moved from the “affect proper parsing” list to the “cannot affect proper parsing” list.
An additional note was added at the top of the Overview of the fcs to indicate what kinds of fci is necessary and sufficient for CSS use.
The conformance section was expanded.
References to related IETF RFC's were added.
Example C.2 was modified to use content ids.


{% extends "cog/common/layout_center.html" %} {% block main %} Thank you, you have been unsubscribed. {% endblock %}


The macro directive of Triangular is key to the design and implementation of the templates that allow for the reuse of many HTML fragments stored either in the standard template library "AppBase.htm" of in the custom template section of an application such as "deps.htm".
The macro directive allows for multilevel insertion of HTML. That is, a template being inserted can use the macro facility to insert another level of HTML.
The simple 'alter' capability allows for the easy reuse of templates with the ability to modify values that must be unique or reference other components.
In addition the special $MODOBJ$ and $MODEL$ keywords allow for a convenient way to insert the current model object and model name into the inserted HTML.
Refer also to templates.


PART V. HAMAKUA COMMUNITY DEVELOPMENT DISTRICT--REPEALED
§§206E-171 to 206E-173 REPEALED. L 2002, c 208, §3.


Logout of Bloodline
Sethuram Iyer O-
+91<PHONE_NUMBER>
4:00 pm, 09/11/2017
Manipal Hospital Old Airport Road HAL 1st stage Bangalore 560007
My mother is undergoing her heart surgery. Please donate A+ blood.
SMS with OTP sent to Senthuram Iyer
You will be notified when Senthuram uses it to get 10 BLC from you


AdminSDHolder Overview
AdminSDHolder is an object located in the System Partition in Active Directory (cn=adminsdholder,cn=system,dc=domain,dc=com) and is used as a security template for objects that are members of certain privileged groups. Objects in these groupsare enumerated and any objects with security descriptors that don't match the AdminSDHolder ACL are flagged for updating. The Security Descriptor propagator (SDProp) process runs every 60 minutes on the PDC Emulator and re-stamps the object Access Control List (ACL) with security permissions set on the AdminSDHolder
Objects protected by AdminSDHolder have the attribute "AdminCount" set to 1 and security inheritance is disabled.
Note that when an object is removed from one of the protected groups, AdminCount is not set to another value. This is due to early feedback when Windows 2000 was released
Conclusion:
AdminSDHolder is a sneaky method for an attacker to persist granting the ability to modify the most privileged groups in Active Directory by leveraging a key security component. Even if the permissions are changed on a protected group or user, SDProp will change the securtiy permissions to match that of the AdminSDHolder object.


How to use umbraco.library GetMedia in XSLT
From time to time I notice a reoccurring post over at the Our Umbraco forum; how to display an image (from the Media section) in XSLT?
A quick answer can be found on the Our Umbraco wiki for the umbraco.library GetMedia method.
For most uses, the last example in the wiki works great. But I want to show you a “super safe” way of dealing with GetMedia in XSLT.
Where I find a lot of the examples go wrong is that they make the assumption that a media node (XML) is returned from the GetMedia call, e.g.
<xsl:value-of select="umbraco.library:GetMedia($currentPage/data[@alias='mediaId'], 'false')/data[@alias='umbracoFile']" />
If the ‘mediaId’ property didn’t contain either a numeric value or a valid media node id, then it would return null … meaning that the following “/data” would throw an Exception! (Displaying “Error parsing XSLT file” message on the front-end.) Not what you or your users want to see!
In order to consider any user inputs, like media IDs not being selected, or even a referenced media node is deleted in the back-office, here is the “super safe” approach:
<xsl:template match="/"> <xsl:variable name="mediaId" select="number($currentPage/data[@alias='mediaId'])" /> <xsl:if test="$mediaId > 0"> <xsl:variable name="mediaNode" select="umbraco.library:GetMedia($mediaId, 0)" /> <xsl:if test="count($mediaNode/data) > 0"> <xsl:if test="string($mediaNode/data[@alias='umbracoFile']) != ''">  <xsl:if test="string($mediaNode/data[@alias='umbracoHeight']) != ''"> <xsl:attribute name="height"> <xsl:value-of select="$mediaNode/data[@alias='umbracoHeight']" /> </xsl:attribute> </xsl:if> <xsl:if test="string($mediaNode/data[@alias='umbracoWidth']) != ''"> <xsl:attribute name="width"> <xsl:value-of select="$mediaNode/data[@alias='umbracoWidth']" /> </xsl:attribute> </xsl:if>  </xsl:if> </xsl:if> </xsl:if> </xsl:template>
Here’s what happens:
- The “mediaId” is pulled from a property of the “currentPage” and cast as a number. Optionally the “mediaId” could be passed in via a macro parameter, or somewhere else?
- The first condition checks the the “mediaId” is numeric, and greater-than zero.
- The “mediaId” is passed through to “GetMedia”, along with the false flag to only pull-back the required node (not it’s children, for Folder media items).
- We check if the media node has any child “data” elements – which contain the data about the image/media.
- Then we check if the “umbracoFile” property has any data – if not, then there is no point displaying an image.
- There are extra conditions for the “height” and “width” properties – these are optional.
Personally, I add an “altText” property to the Image media-type … and use that in the XSLT – again this is optional, but strongly recommended!
I can see how this “super safe” approach is overkill – especially compared with a single line of XSLT … but from my experience, it’s better to be safe than sorry – especially when dealing with user data-input – your assumptions and expectations of how users will use the system aren’t always correct!
Update: OK, I agree the extra “if” statements are overkill… so here’s a condensed version – assuming that the “umbracoHeight” and “umbracoWidth” properties are always there…
<xsl:template match="/"> <xsl:variable name="mediaId" select="number($currentPage/data[@alias='mediaId'])" /> <xsl:if test="$mediaId > 0"> <xsl:variable name="mediaNode" select="umbraco.library:GetMedia($mediaId, 0)" /> <xsl:if test="count($mediaNode/data) > 0 and string($mediaNode/data[@alias='umbracoFile']) != ''">  </xsl:if> </xsl:if> </xsl:template>


{%- for crumbsNode in include.nodes -%} {%- include active.html node=crumbsNode -%} {%- if active -%} {%- assign active = false -%}


flow-view
programmatic example
Nodes and edges are created via API. See code below.
The GHOST button set the ghost
attribute to few items, it makes them semi transparent. The NORMAL
button reset them.
Nodes and edges are created with the following code.
import { FlowView } from 'https://unpkg.com/flow-view';
const flowView = new FlowView({
element: document.getElementById('element')
});
const node1 = flowView.newNode({
text: 'Hello', ins:[{}, {}], outs: [{ id: 'output1' }], x: 100, y: 100
});
const node2 = flowView.newNode({
text: 'World', ins:[{ id: 'input1' }, { id: 'ghost' }], x: 250, y: 400
});
const node3 = flowView.newNode({
text: 'ciao', outs:[{ id: 'saluto' }], x: 400, y: 280
});
const edge1 = flowView.newEdge({
from: [node1.id, 'output1'],
to: [node2.id, 'input1']
});
const edge2 = flowView.newEdge({
from: [node3.id, 'saluto'],
to: [node2.id, 'ghost']
});


FIEND WITHOUT A FACE (director: Arthur Crabtree; screenwriter: Herbert J. Leder/From story by Amelia Reynolds long; cinematographer: Lionel Banes; cast: Marshall Thompson (Major Jeff Cummings), Kynaston Reeves (Professor Walgate), Stanley Maxted (Colonel Butler), Kim Parker (Barbara Griselle), James Dyrenforth (Mayor Hawkins), Robert MacKenzie (Constable Howard Gibbons), Terry Kilburn (Captain Chester), Lala Lloyd (Amelia Adams), R. Meadows White (Ben Adams), Michael Balfour (Sgt. Kasper), Gil Winfield (Dr.Warren), Peter Madden (Dr. Bradley), Shane Cordell (Nurse), 1957-UK)
Reviewed by Dennis Schwartz
This 1950s sci-fi/horror cult classic opens with a dead body found on the grounds of a secret experimental atomic test-site of a U.S. Air Force base located in the remote Winthrop-Manitoba part of Canada. The base is operated under the joint consent of Canada and the U.S., and is being used to experiment on long-range radar installation capabilities, using nuclear energy and beaming that power to boost the scanning range of the experimental planes. This stuff is all hush-hush.
There is growing resentment toward the base in the small backward town (can you blame them!), as the local residents are blaming the new base for the poor production of milk due to the noise from the passing jets disturbing the cows and they are scared of the rumors they hear about fallout from atomic radiation. The military calls these people ignorant and superstitious for not trusting them. Gee!
The attractive murder victim's sister, Barbara Griselle (Kim Parker), agrees with the town officials that an autopsy won't be necessary, but Major Jeff Cummings (Marshall Thompson), the base investigator, urges a more careful investigation of this murder. He notes the look of extreme horror on the dead man's face and surmises there is more to this death than meets the eye.
The viewer watches as invisible forces next attack a farmer's wife (Lala) and then the farmer (White), with each of them screaming, throwing their head back, and grabbing at their neck and the invisible force never letting go until the victims are dead. The local constable Gibbons (MacKenzie) is very hostile to the Air Force people investigating these crimes, he even has a fist fight with the major when he sees him over at Barbara's house (I think he's a little jealous), and refuses to co-operate in anyway. But the major finds out from the local doctor, Bradley (Madden), and the military doctor (Winfield), that all the victims had their brains sucked out of them as well as their spinal cords removed.
The major also learns that Barbara is doing secretarial work for a reclusive research professor, Walgate (Kynaston Reeves), and he notices in her possession a manuscript for a book on "thought control," which sparks his interest, thinking there might be a connection there to the recent murders. His interest is further increased by his meeting with the strange but amiable professor, as a fourth murder is committed.  And if that wasn't enough, Constable Gibbons on a search party in the woods for the killer, disappears and shows up later in state of shock, as he dies in the same manner as the others who were killed.
By this time the major and Barbara show a strong affection for each other, and a little romance is blooming without even a kiss or holding of hands taking place, though there is one scene where she comes out of the shower with just a towel on and you know that got the major's attention. Now this romance could be taken for a serious one. But the major is a busy man, so romance must take second place in this film. It seems that the major is the only one on the base who does any work. The security officer, Captain Chester (Kilburn), he's more into doing paperwork than fieldwork, and the colonel, Butler (Maxted), who is good at delegating all responsibility to the major, and is therefore left with a clear mind to make the big decisions, like ordering the major to get the killer before the locals really get mad and try to shut down the base. So, you see, the major is a very busy man.
The major begins his investigation for real by speaking to the professor without holding back that the he is under suspicion. He believes that the professor is involved with the murders, especially when he learns from his security officer, that the F.B.I. has a file on the professor doing psychic research with atomic power and one of the books he published is on cybernetics.
Lucky for the major, he borrowed Barbara's searchlight before going to the local cemetery, because when he sees someone fleeing the mayor's airtight mausoleum, he enters it and gets locked in there, and if weren't for Barbara knowing where to find him, the major would have perished that night.
It now becomes obvious that the professor is involved in this mystery, and the fun part of the film begins, or some might think the film really goes out of whack from here on. The prof comes clean and goes into detail how he created these invisible mutant creatures by tapping into the base's atomic power source and putting an electrical charge to his brain. He now urges the Air Force to destroy the nuclear plant, or else the invisible creatures can't be stopped. But things are not that simple, the atomic plant malfunctions and can't be shut down, and to my delight, the creatures become visible because of the increase in atomic power in the nuclear plant.
What's viewed on screen are brains with a spinal cord attacking everybody they see, killing all the people manning the nuclear plant. The colonel is tremendous in the crisis, he keeps popping these hopping brains with his .45 pistol and it turns out they are mortal, turning to mush when shot. There are great special effects, using stop-motion animation to show the brains moving around! Meanwhile, the colonel realizing the tight situation they are in, tells the major to single-handedly go into the nuclear plant and dynamite it. The major leaves before Barbara could talk him out of it. As some comfort, the security officer tells her, don't worry, if anyone could succeed in this impossible situation, it's Jeff. Luckily the genius professor runs out to act as a diversion for the hopping brains and gets devoured by three of them, giving Jeff a chance to complete his mission.
As entertainment value, this film should hit the right spot: it's a screamer. As anything greater, the story made little sense. This is just another mutant B- flick that is missing most of its brain. If the invisible creatures were supposed to bring with them an anti-atomic war message, the message was garbled and got lost somewhere along the way along with man's free will to resist the invisible creatures (who represent the forces in man that bring about war).
REVIEWED ON 12/4/99 GRADE: C+
Dennis Schwartz: "Ozus' World Movie Reviews"
http://www.sover.net/~ozus
<EMAIL_ADDRESS>© ALL RIGHTS RESERVED DENNIS SCHWARTZ
The review above was posted to the
rec.arts.movies.reviews newsgroup (de.rec.film.kritiken for German reviews).
The Internet Movie Database accepts no responsibility for the contents of the
review and has no editorial control. Unless stated otherwise, the copyright
belongs to the author.
Please direct comments/criticisms of the review to relevant newsgroups.
Broken URLs inthe reviews are the responsibility of the author.
The formatting of the review is likely to differ from the original due
to ASCII to HTML conversion.
Related links: index of all rec.arts.movies.reviews reviews


A Passionate, Creative, and Devoted
Low-poly generator for image and video processing.
A Web Audio library designed for Web games, with both pure JavaScript version and jQuery version.
Introduction to Three.js is an ebook to help beginners to start with Three.js, which is available on both bookshop and library.
Handian Immediate Translate Tool and ReadFree to library are two useful Chrome Extensions.
Major in Software Engineering
Graduated on Mar, 2016
Research topic related about Face Recognition and Avatar Synthesis
Sep 2012 - Feb 2013, May 2014 - Dec 2014
Related technology: Web Audio, WebGL, Three.js, WebRTC
Excellent Intern of 2014 2H
July 2015 - Sep 2015
Related technology: WebGL, Three.js
Oct 2015 - Mar 2016
ECharts heatmap and gallery
In Shanghai, From Apr 2016
Data Visualization, Canvas, WebGL, JavaScript, Node.js, and etc.


=
Software Hub
Home
(current)
Stock ROM
Flash Tools
Drivers
Other Tools
Request a Software
Report a problem
Contact us
About us
Contact us
About us
Request a software
Describe your Requirements below
Your name
Your email
Software name and description
Submit


Twelve corpses burnt as fire razes OAU morgue - Premium Times Nigeria
by Adejumo kabirAt least 12 corpses were affected in an early morning fire outbreak on Tuesday at the morgue of the Department of Anatomy, Obafemi Awolowo University, Ile Ife, Osun State.
PREMIUM TIMES gathered that the affected corpses were kept in the cabin of the morgue.
The spokesperson of the university, Abiodun Olarewaju, in a statement on Tuesday afternoon, said the incident was prevented from turning into a major fire outbreak by the combined efforts of the security and fire services units of the University.
Mr Olarewaju said the fire outbreak occurred at about 3 a.m. from an electrical surge. He said the fire affected a section of the morgue where corpses are kept.
“Out of about one hundred and two (102) bodies that are kept in the morgue, twelve (12) were affected by the fire outbreak,” the statement said.
He, however, said the department had informed “those who have kept bodies (corpses) in the morgue.
“Leading other Principal Officers to the scene of the incident, the Vice-Chancellor, Professor Eyitope Ogunbodede, assessed the level of damage and instructed immediate repairs to the affected areas.
“The Vice-Chancellor has also constituted a three-member committee to look into the immediate and remote causes of the fire outbreak. Normalcy of academic and administrative activities has since returned to the area,” the official said.


Altered Eating Research Network: Thought for food.| Rediscovering the joy of food | Research with patients and the public | Faculty of Medical Sciences, Newcastle University, UK
Visit siteFifth Sense is the charity for people affected by smell and taste disorders. We provide education, support, advice and signposting to potential treatment available to people affected by these conditions.
Visit siteThe home of NoseWell, the Covid-19 smell loss guide. AbScent is the largest online support community providing trusted information and practical resources for everyone living with smell disorders. A charity registered in England and Wales number 1183468
Visit siteVoor meer informatie over onze vereniging en lotgenotencontact klik hier
Visit sitePour obtenir des informations sur les troubles de l'odorat en France, cliquez-ici
Visit siteHungerNdThirst Foundation strives to improve quality of life for people confronted with taste alteration due to cancer treatment.
Visit siteTo check out the Smell Podcast and listen to anosmia stories, click below.
Visit site"To smell the roses and taste the spice of life." We are a patient advocacy group formed in 2020 to improve the quality-of-life for people with smell and taste disorders since we recognize that the loss of taste or smell can affect health, safety and emotional well-being. We seek to expand research, education and treatments for people living in North America who are experiencing the invisible loss of these senses.
Visit siteAre you involved with a group who aims to help improve the life of those with smell and taste disorders? Reach out to us so we can help connect others with you!


Decodable Reader Tool
Stage
1
of
2
Set up Stages
Letters in this stage
Words in this stage
Open a Letter and Word List File


Logging is handled by dk.itst.oiosaml.logging.Logger interface. The logger is initialized with a name. The name can either be a full class name (e.g. dk.itst.oiosaml.logging.LoggerFactory) or 'OIOSAML_AUDIT_LOGGER'. OIOSAML.java comes with a default implementation that uses Log4j. The default implementation creates two types of logs: The system log (all loggers starting with the name 'dk.itst.oiosaml') which logs runtime information about the processing of requests and responses, and an audit log (loggers with the name 'OIOSAML_AUDIT_LOGGER') which logs information about users.
The system log is mostly interesting when something fails. It will contain stack traces, and if set to debug level, al requests and responses will be logged.
The audit log is interesting when tracking users. It contains information about when AuthnRequests are issued, when responses are returned, and when users are logged in and out.
Logging is configured in ${oiosaml.j.home}/oiosaml-sp.log4j.xml. This file only contains logging configuration for OIOSAML.java itself - application logging should be kept outside.
By default, log events are sent to the console and a file in ${oiosaml.j.home}/logs.
It is possible to use your own logging implementation. The following two things must be done:


My name is Ryan Byrnes and I am a VCD major at Eastern Washington University. I have a love for photography and film, which are in the field that I currently trying to pursue. I have been a quote "photographer" for a couple years now and am continuing to learn different tricks and techniques to advance what I know into something even more.


Don't join the train, leave Your trail!
Wanna kill the cliche in your life? Signup and find the mentor who's just right for you or Signup as a mentor and help the person who needs you
............................
..........................
..................................


| I l@ve RuBoard |
We've learned all about modules in this chapter—how to write them and how to use them. Along the way we explored namespaces and qualification, saw how to reload modules to change running programs, peeked at a few module design issues, and studied the module-related statements and functions listed in Table 5.1. In the next chapter, we're going to move on to study Python classes. As we'll see, classes are cousins to modules; they define namespaces too, but add support for making multiple copies, specialization by inheritance, and more.
|
Operation |
Interpretation |
|---|---|
import mod |
Fetch a module as a whole |
from mod import name |
Fetch a specific name from a module |
from mod import* |
Fetch all top-level names from a module |
reload(mod) |
Force a reload of a loaded module's code |
| I l@ve RuBoard |


Active Record automatically timestamps create and update operations if the table has fields named created_at/created_on or updated_at/updated_on.
Timestamping can be turned off by setting
<tt>ActiveRecord::Base.record_timestamps = false</tt>
Timestamps are in the local timezone by default but you can use UTC by setting
<tt>ActiveRecord::Base.default_timezone = :utc</tt>
Methods
Public Instance methods
Saves the record with the updated_at/on attributes set to the current time. If the save fails because of validation errors, an ActiveRecord::RecordInvalid exception is raised. If an attribute name is passed, that attribute is used for the touch instead of the updated_at/on attributes.
Examples:
product.touch # updates updated_at product.touch(:designed_at) # updates the designed_at attribute
[ show source ]
# File vendor/rails/activerecord/lib/active_record/timestamp.rb, line 27 27: def touch(attribute = nil) 28: current_time = current_time_from_proper_timezone 29: 30: if attribute 31: write_attribute(attribute, current_time) 32: else 33: write_attribute('updated_at', current_time) if respond_to?(:updated_at) 34: write_attribute('updated_on', current_time) if respond_to?(:updated_on) 35: end 36: 37: save! 38: end


--- layout: page permalink: /about title: About - Luke Sartori - Product and User Experience Designer heading: About sub_heading: I’m a User Experience & Product Designer from Sydney, Australia. ---
Mobile has redefined the way consumers interact in our world today and the idea of a physical product existing without some kind of digital representation is becoming increasingly more rare. This is what excites me as a designer and drives me to create exciting and engaging experiences that combine these two mediums perfectly.
Before UX and digital, I worked as an Industrial Designer creating physical objects. My approach to product design, regardless of the medium, remains the same. Researching, sketching, conceptualizing and testing are the main focus in my own design process and are the keys to identifying a product’s end user but more importantly how and where they will be using it.
I believe that design led problem-solving and cross team collaboration are the keys to delivering a truly great product to market. Working with talented developers, visual designers, marketers and product owners has made me a better problem-solver, a well-rounded thinker and a more insightful designer.


Background¶
The Birth of RivGraph¶
In 2016, I walked into the postdoc office at the Saint Anthony Falls Laboratory to see deltas on display as 8.5 x 11 sheets of paper taped together with hand-drawn markings all over. My colleagues Alejandro Tejedor and Anthony Longjas were trying to whip these deltas into shape for a series of papers (1, 2) introducing a new way to think about deltas: through the lens of their channel networks. As I looked at their handiwork, I couldn’t help thinking that there must be a better way. My own research at the time had led me to develop RivMAP, a Matlab toolbox for analyzing the morphodynamics of meandering rivers using binary masks. And so RivGraph was born as a small set of Matlab scripts with very limited functionality.
I finished my PhD with RivGraph in a barely-formed state, and followed my adviser, Efi, to UC-Irvine for a short postdoc. Alex and Anthony were pushing the deltas work even further, and I kept adding scripts to RivGraph. The inevitable idea was hatched to analyze dozens of deltas worldwide, and eventually became a successful proposal. In the meantime, I took a postdoc position at Los Alamos National Laboratory with an eye toward global river morphodynamics. My arrival at LANL marked the beginning of my Python journey, and soon I had converted all the RivGraph scripts to Python. My research needs led to a fuller development of RivGraph and brought braided rivers into the mix, and sometime in 2017, RivGraph officially became RivGraph.
I cut my Python teeth while developing RivGraph, so there is a degree of inherited clunkiness and inefficiency baked in. Initially, there were also some implements (such as automatically adding artificial nodes to parallel edges) that were tailored to somewhat particular use cases. However, as the user base continues to grow, improvements and upgrades have been implemented to meet their needs. Please add your requests to the mix and report any bugs you find using Github’s issue tracker.
What’s different about RivGraph?¶
RivGraph fills a void in coding space by providing a full-featured package for working with masks of river channels. In my opinion, most of RivGraph is just a convenient collection of already-existing functionality like CRS handling, path management, etc. That said, there are three somewhat novel components of RivGraph that are not available elsewhere, or at least not available in Python.
The first of these is the walking algorithm that breaks a skeleton into its constituent links and nodes. While there is similar functionality available in GIS packages, RivGraph ensures that the resulting skeleton is parsimonious–i.e. contains as few nodes as possible while fully preserving the topology of the mask. This is achieved with help from a double-convolution, where the first convolution identifies possible branchpoints and the second reduces branchpoint clusters to a minimum-required set.
The second novelty RivGraph offers is its ability to automatically set flow directions. This is trivial for some networks (like Wax Lake Delta), but many channel networks are wild beasts. RivGraph’s solution is correspondingly complicated, but does a pretty good job. We published the method, its validation, and its implications.
The third novel component of RivGraph is its abilty to generate an along-channel mesh that approximately follows a river’s centerline while transecting the centerline approximately perpendicularly. This was a surprisingly tricky function to get right, and I’m not even sure it’s there yet. The first iteration of this appeared in RivMAP, and there have probably been 3-4 method changes before settling on the current version, which uses Dynamic Time Warping (thanks Zoltan et. al for introducing this to me, although I still contend that it’s inappropriate to use for measuring channel migration rates) to iteratively map vertices on buffered centerlines away from the original.
Is RivGraph only for channel networks?¶
While RivGraph is designed around channel networks, it contains a smattering of tools that can be useful across a broad range of analyses. For instance, the mask_to_graph.py script contains tools that will convert any binary mask to a vectorized skeleton, not just river channel networks. There are a number of image processing tools in im_utils.py that I use frequently in other projects, like a Matlab-like implementation of regionprops() for measuring blob properties of a binary image. I have personally found one of the most broadly useful tools in RivGraph is write_geotiff, which does what it says.


unknown horses EIV samples SRH vaccine equine influenza serum antibody vaccination French clinical coverage time protection horse outbreaks titers France results strains study {border-style []. number px;} threshold #ffffff;} virus (i.e., categories Figure JUN MAR born late used located yes < DIVA breeding field reported significantly strain surveillance titer use vaccinated European based disease frequency immune level measured population recombinant young (p-value ELISA analyzed cases compared countries difference immunity immunization mm; significant FEB Normandy Orne Trotters analysis available current infection months neg vaccines years Equine Influenza Results Table assay considered different epidemiological high horses, including infected information mm). negative old p-value period px; region response selected showed signs veterinary {font-family (Figure .). December Florida France, JAN Vaccination early font-size inactivated prior provide serological seropositive specific status studies test using Clade France. NP-ELISA Oise absence antibodies canarypox-based category circulating control double; epidemic induced isolated low observed obtained outbreak prevent primary recent regions tested (> (NP) .%, Europe France) However, Overall Overall, Pays bold border-color border-width carried centers circulation described detection equids evaluate explained explanation geographical hemolysis indicate involved known linked lower overall practitioners reached sale samples, sampling sera seronegative serums shedding solid; study, virological years) {font-style {font-weight (.%) (SRH) (✻) Analysis Auvergne-Rhône-Alpes Calais EIV-NP EIV-specific LABÉO Loire MAY OIE Pas Phylogenetic RESPE Samples South Status Supplementary United Val-de-Marne [], abroad benefit case clade competition courier; data diagnosis diagnostic em; epizooty explain exportation infection, lack large levels light mid- north older origin pathogen percentage populations positive potential present pt;} radial recorded reduced respectively). responses review single sport study. support taken transmission type usually vaccination. viruses weeks


Math Trainer is an easy-to-use AMC and AIME viewing interface.
All questions are loaded from the Art of Problem Solving wiki.
Behind the scenes, Math Trainer uses the following tools:
Favicon: Image from here (cropped).
Loader: made with loading.io.
This software is open source (MIT License).
Answer: {{ answer }}
Version {{ versions[0].major }}.{{ versions[0].minor }}.{{ versions[0].patch }}{{ versions[0].identifierText }}
Also:
Also:


Coronation Street fans fear for Daniel as he refuses to attend wife Sinead's funeral
Coronation Street's grief-stricken Daniel Osbourne refused to return to the Street for his wife Sinead Tinker's funeral
by Charlotte TuttonCoronation Street viewers were worried about Daniel Osbourne, claiming he looked "unwell" as he finally made contact with dad Ken Barlow.
Daniel fled to Scotland with baby son Bertie in the wake of his wife Sinead Tinker's death, following a battle with cancer.
The grieving character needed some space, as planning his wife's funeral left him overhwelmed.
His dad begged him to return back to the Street in the latest episode, as the family continued to plan the funeral without him.
But Daniel shocked his loved ones, as he revealed no plans to be back in time for his wife's send off.
Ken was in tears as he heard his devastated son breaking down on the phone, refusing to return.
He later confided in son Peter Barlow fearing Daniel would regret missing the service.
Viewers felt the same, urging Daniel to return with baby son Bertie as others admitted fearing for the character.
Taking to Twitter , one fan said: "Omg, Daniel he looks so unwell!"
Another agreed: "Poor Daniel. He looks terrible."
Others hoped Daniel would change his mind and be there for the service to say goodbye to Sinead.
A fan wrote: "Daniel you need to come home."
Another said: "Someone please help Daniel #Corrie ."
A third agreed: "Please come back for Sinead’s funeral Daniel."
Coronation Street airs Mondays, Wednesdays and Fridays at 7:30pm and 8:30pm on ITV.


Home
Sales Info
Pat's Salmon Cookies
New Fake Stores!
Name of Potential New Cookie Hustler
What is your minimum clientele?
What is your maximum clientele?
On average how many fish do you sling?
Commit your lies!


Load More
The GridControl supports dynamic loading of new data items from a data source. This feature can be useful when working with a large amount of data that should be retrieved from a remote server over the network.
To enable this functionality, set the grid's IsLoadMoreEnabled property to true. Define a command in a view model and then bind it to the grid using the LoadMoreCommand property. When an end-user scrolls to the bottom of the grid, new data records are added to the end of the grid.
Related APIs: