Copyright ©2001 W3C® (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
This is an Editors Draft of the RDF Core WG Working Draft and describes the updates to the grammar for the XML syntax of the RDF model as described in RDF Model & Syntax after amendments and clarifications from the RDF Core WG.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. The latest status of this document series is maintained at the W3C.
This is an Editors Draft of the latest version of the W3C RDF Core WG Working Draft for the RDF Core Working Group produced as part of the W3C Semantic Web Activity. It incorporates decisions made by the Working Group updating the XML syntax for RDF from the original RDF Model & Syntax document.
This document is being released for review by W3C members and other interested parties to encourage feedback and comments, especially with regard to how the changes affect existing implementations, and how the grammar can be formalized with schema languages. This is the current state of an ongoing work on the syntax and does not yet record all the related decisions or include the descriptive text from the grammar section of the original document.
This is a draft document and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use it as reference material or to cite as other than "work in progress". A list of current W3C Recommendations and other technical documents can be found at http://www.w3.org/TR/.
Comments on this document are invited and should be sent to the public mailing list www-rdf-comments@w3.org. An archive of comments is available at http://lists.w3.org/Archives/Public/www-rdf-comments/.
TOC may not represent document structure at present - FIXME
1 Introduction
2 Terminology
3 Data Model
3.1 Root Node
3.2 Element Node
3.3 End Element Node
3.4 Attribute Node
3.5 Text Node
3.6 Identifier Node
3.7 Information Set Mapping
4 Notation
4.1 Grammar Notation
4.2 Notation Forms
5 RDF/XML Grammar in Infoset Terms
6 Serialising an RDF Model to RDF/XML
7 References
A RDF Core WG Issues affecting RDF/XML Syntax (Non-Normative)
B Original Grammar (Non-Normative)
C Updated Grammar after RDF Core decisions (Non-Normative)
D Syntax Schemas (Non-Normative)
This document describes the XML syntax for RDF as originally defined in the RDF Model & Syntax W3C Recommendation. Subsequent implementations of this syntax and comparison of the resulting RDF models have shown that there was ambiguity - implementations generated different models and certain syntax forms were not widely implemented. These issues were generally made as either feedback to the www-rdf-comments@w3.org (archive) or from discussions on the RDF Interest Group list www-rdf-interest@w3.org (archive) .
The RDF Core Working Group is chartered to respond to the need for a number of fixes, clarifications and improvements to the specification of RDF's abstract model and XML syntax. The working group invites feedback from the developer community on the effects of its proposals on existing implementations and documents.
Several decisions including amendments and deletions to the grammar are refered to below. The definitive record of the decisions is the RDF Core WG issues list.
This document re-represents the original EBNF grammar in terms of the XML Information Set items which moves from the rather low-level details, such as particular forms of empty elements. This allows the grammar to be more precisely recorded and the mapping from the XML syntax to the RDF model more clearly shown. The mapping to the RDF model (a graph) is done by emitting statements in the form defined in the N-Triples section of RDF Test Cases Working Draft which creates an RDF model, that has semantics defined by RDF Model Theory Working Draft.
FIXME Hunt down that must, may thing in W3C-space. See new publishing guide.
This syntax operates on an XML document as a sequence. This section describes how RDF/XML models an XML document as a sequence of nodes in document order in the style of (a serialised) XPath Information Set Mapping. The resulting nodes are intended to be similar to the events that are produced by the SAX2 XML API. This model is conceptual only and does not mandate any particular implementation.
XML documents operated on by RDF/XML must conform to the XML Namespaces W3C Recommendation. In particular, this syntax defines no meaning for any XML elements or attributes information items with no namespaces.
This specification requires an information set as defined in XML Infoset which supports at least the following information items and properties:
This specification does not require any destructive alterations to the input information set; no items are added, removed or modified..
This section is intended to satisfy the requirements for Conformance in the XML Infoset specification.
There are six types of node defined as follows
Created from an Document Information Item and takes the following properties and their values from the element information item: document-element and children.
Created from an Element Information Item and takes the following properties and their values from the element information item: local-name, namespace-name, children, attributes and parent. When this node is created from such values, the URI property is defined with a string value of the concatenation of the value of the namespace-name property and the value of the local-name property. On creation the li-counter property is added with initial integer value 1.
The subject property may be added and takes the value of an Identifier node. This is used on elements that deal with one node in the RDF model, this generally being the subject of a statement.
The object property may be added and takes the value of an Identifier node. It is used on elements that deal with two nodes in the RDF model, this generally being the object of a statement.
Takes no properties but marks the end of the containing element in the sequence.
Created from an Attribute Information Item and takes the properties local-name, namespace-name and owner element and their values from respective element information item properties. When this node is created from such values, two properties and values are defined. Firstly the string-value property is defined with the normalized value as specified by the XML Recommendation. An attribute whose normalized value is a zero-length string is not treated specially: it results in an attribute node whose string-value is a zero-length string. Secondly the URI property is defined with a string value of the concatenation of the value of the namespace-name property and the value of the local-name property.
Created from a sequence of one or more consequtive Character Information Items. Has the single property string-value which has the value of the string made from concatenating the character code property of each of the character information items. [NOTE: Identical to XPath.]
A node for an typed identifer which can have the following three properties: identifier and identifier-type and string-value. These nodes are created by giving two values for the for the identifier and identifier-type properties. The identifier property takes a string value and the identifier-type property can take values "URI" or "nodeID".
On creation the string-value property is defined from the other properties as follows: If identifier-type is "URI" then the value is the concatenation of "<", the value of the identifier property and ">". If identifier-type is "nodeID" then the value is the concatenation of "_:" and the value of the identifier property.
To transform the Infoset into the sequence of nodes, each information item is transformed as described above to generate a tree of nodes with properties and values. Each element node is then replaced as described below to turn the tree of nodes into a sequence in document order.
The following notation is used for describing the nodes and grammar EBNF.
| Notation | Meaning |
|---|---|
| property=value | A node property with a given value |
| root(prop1=value1, prop2=value2, ...) |
A root node with properties |
| start_element(prop1=value1, prop2=value2, ...) children end_element() |
A sequence of element node with properties, a possibly empty list of nodes as element content and an end element node |
| attribute(prop1=value1, prop2=value2, ...) |
An attribute node with properties |
| identifier(prop1=value1, prop2=value2, ...) |
An identifier node with properties |
| text() | A text node |
| list(item1, item2, ...); list() | An ordered list of items in document order; an empty list |
| set(item1, item2, ...); set() | An unordered set of items; an empty set |
| * | Zero or more of preceding term |
| ? | Zero or one of preceding term |
| + | One or more of preceding term |
| A | B | ... | The A, B, ... terms are alternatives. |
| A - B | The term A but not the term B |
| "ABC" | A string of characters A, B, C in order. |
| concat(A, B, ..) | A string created by concatenating the terms in order. |
| anyURI | Any legal URI. |
| rdf:X | The URI formed by concatenating the two strings "http://www.w3.org/1999/02/22-rdf-syntax-ns#" with "X" |
The following notation forms are used to indicate
A sequence of lines of N-Triples output from a grammar production adding to an RDF model.
If the RDF/XML is a standalone XML content, then the grammar starts with Root Node doc.
If the content is known to be RDF/XML by context, such as when RDF/XML is embedded inside other XML content, then the grammar can either start at Element Node RDF (only when an element is legal at that point in the XML) or at production nodeElementList (only when element content is legal, since this is a list of elements). Note that if such embedding ocurrs, the grammar may be entered several times but no state is expected to be preserved.
root(document-element=RDF,
children=list(RDF))
start_element(URI = rdf:RDF,
attributes=set())
nodeElementList
end_element()
ws* (nodeElement ws* )*
start_element(URI=anyURI,
attributes=set((idAttr | aboutAttr | aboutEachAttr)?, bagIdAttr?, propertyAttr*))
propertyEltList
end_element()
The following processing is performed before handling any propertyEltList children and in this order (FIXME: the dependencies here have not been precisely worked out).
e.subject.string-value <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <a.string-value> .
e.subject.string-value <u> <a.string-value> .
Subsequently the value of e.li-counter property is incremented by 1.
e.subject.string-value <a.URI; "a.string-value" .
e.subject.string-value <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <e.URI> .
White space as defined by XML definition White Space Rule [3] S in section Common Syntactic Constructs
ws* (propertyElt ws* ) *
start_element(URI=anyURI,
attributes=set(idAttr?))
nodeElement
end_element()
For element e, and the single contained nodeElement n the following statement is added to the model:
e.parent.subject.string-value <e.URI> n.subject.string-value; .
If the rdf:ID attribute a is given, the above statement is reified with identifier(identifier=concat("#",a.string-value), identifier-type="URI") using the reification rules in section 5.X.
start_element(URI=anyURI,
attributes=set(idAttr?))
text()
end_element()
Note: The empty literal case is defined in production emptyPropertyElt
For element e, and the text node t the following statement is added to the model:
e.parent.subject.string-value <e.URI> "t.string-value" .
If the rdf:ID attribute a is given, the above statement is reified with identifier(identifier=concat("#",a.string-value), identifier-type="URI") using the reification rules in section 5.X.
start_element(URI=anyURI,
attributes=set(idAttr?, parseLiteral))
literal
end_element()
If the element content is an empty literal then ...
test009.rdf indicates in test009.nt that the statement object value is ""
else
FIXME. Note, in future the number of values of the parseType attribute will increase, and those values will probably move to QNames.
start_element(URI=anyURI,
attributes=set(idAttr?, parseResource))
propertyEltList
end_element()
If the element content is an empty list then ...
test004.rdf indicates in test004.nt that the statement object value is a bNode
else
start_element(URI=anyURI,
attributes=set((idAttr | resourceAttr)?, bagIdAttr?, propertyAttr*))
end_element()
FIXME - improve words near test references below
test001.rdf and test002.rdf indicate in test001.nt and test002.nt that the object value is "" if no rdf:ID attribute is present, else test005.rdf indicates in test005.nt that with rdf:ID it reifys the statement with an object value of ""
test006.rdf indicates when rdf:ID and rdf:Resource are both present it generates 5 statements as shown in test006.nt
test013.rdf indicates in test013.nt that when rdf:Resource and other properties attributes are present generates 1+number of property attribute statements
test014.rdf indicates in test014.nt that when only other properties attributes are present, generates a statement with a bNode as object and those property attributes statements of that bNode with literal values
attribute(URI = rdf:ID
string-value=rdf-id)
attribute(URI = rdf:about
string-value=URI-reference)
attribute(URI = rdf:aboutEach
string-value=URI-reference)
attribute(URI = rdf:bagID
string-value=rdf-id)
attribute(URI=anyURI - ( rdf:ID | rdf:about | rdf:aboutEach | rdf:bagID | rdf:parseType | rdf:resource ),
string-value=CDATA)
attribute(URI = rdf:resource
string-value=URI-reference)
attribute(URI = rdf:parseType
string-value="Literal")
attribute(URI = rdf:parseType
string-value="Resource")
CDATA interpreted as a URI reference defined in RFC2396 BNF production URI-reference.
ISSUE: is this the best way to specify this?
Any XML element content that is allowed according to XML definition Content of Elements Rule [43] content. in section 3.1 Start-Tags, End-Tags, and Empty-Element Tags
The URI http://www.w3.org/1999/02/22-rdf-syntax-ns#
ISSUE: Should this be changed from any legal XML Nmtoken to be the same as that for XML IDs? In XML 1.0 (Second Edition) XML IDs must match Validity constraint: ID which requires the identifiers to match the Name production - a more restricted identifier than Nmtoken.
For a statement with terms s, p and o corresponding to the N-Triples:
s p o .
add the following statements to the model using the given Identifier Node r:
r.string-value <http://www.w3.org/1999/02/22-rdf-syntax-ns#subject> s .
r.string-value <http://www.w3.org/1999/02/22-rdf-syntax-ns#predicate> p .
r.string-value <http://www.w3.org/1999/02/22-rdf-syntax-ns#object> o .
r.string-value <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://www.w3.org/1999/02/22-rdf-syntax-ns#Statement> .
FIXME. Explanation of possible methods. See cwm, ARP.
FIXME. It is not possible for all models that can be expressed in the RDF Model Theory to be encoded in this syntax. If you do a round trip from RDF/XML to RDF graph model and then back to RDF/XML the meaning will be the same but don't expect the RDF/XML that comes out to be exactly the same.
The decided issues that changed the grammar are recorded here but this is not the definitive list or description - see the RDF Core WG issues list. There are other decided issues that did not affect the EBNF grammar but do affect the syntax by amending the descriptive text in the original grammar. These issues are not recorded here at this time. Decided issues may also have associated test cases which can be found in the RDF Test Cases document (work in progess at this date).
On 25th May 2001, the WG decided that ALL attributes must be namespace qualified. There is a description of the decision, including detail on the grammar productions affected and a collection of test cases
Action: Removal of original grammar productions 6.6, 6.7, 6.8, 6.9, 6.11, 6.18, 6.32, 6.33
On 1st June 2001, the WG decided that aboutEachPrefix would be removed from the RDF Model and Syntax Recommendation on the grounds that there is a lack of implementation experience, and it therefore should not be in the recommendation. A future version of RDF may consider support for this feature.
Action: Removal of original grammar production 6.8
On 29th June 2001, the WG decided that containers will match the typed node production in the grammar (production 6.13) and that the container specific productions (productions 6.25 to 6.31) and any references to them be removed from the grammar. rdf:li elements will be translated to rdf:_nnn elements when they are found matching either a propertyElt (production 6.12) or a a typedNode (production 6.13). The decision includes a set of test cases.
Action: Removal of original grammar productions 6.25, 6.26, 6.27, 6.28, 6.29, 6.30, 6.31
On 8th June 2001 the WG decided how empty property elements should be interpreted. The decision is fully represented by the test cases.
Action: Inserted pointers to the the test cases into the grammar at the places where empty property elements are recognised.
On 29th June 2001, the WG decided that rdf:aboutEach attributes are not allowed on an rdf:Description (or typed node) element which is the object of a statement.
Action: ?
The language describing the syntax is unclear [in section 6]
Action: A new formalism of the syntax is being developed to describe the syntax more clearly and the detailed questions about what propertElt productions generate will be answered by test cases for each alternative with further explanation in the primer.
The syntax needs a more convenient way to express the reification of a statement.
Action: Will not be addressed in the current RDF/XML syntax since any easier way to do reification would require probably extensive changes to the syntax.
What triples are generated for nested description elements with bagIDs?
Action: Nested description elements with bagIDs generate the same triples as top-level description elements with bagIDs. Specifically triples generated as a result of the parent propertyElt element do not get reified and included in the bag.
The RDF XML syntax cannot represent all possible Property URI's.
Action: Will not be addressed in the current RDF/XML syntax since it would require changes to the syntax that would not be backwards compatible. New XML syntaxes will likely include such a feature.
Action: This will not be changed in the syntax but the usage of the rdf:value property will be described in the RDF primer and/or Model Theory.
Action: ?
Action: Has been considered and a more formal approach has been developed in Section 4 and the syntax document will include some schemas for XML validation in Appendix D.
Action: ?
The mapping of QNames to URI's generates incorrect URI's.
Action: The algorithm to generate URIs for RDF concepts cannot be changed in the current syntax without breaking existing applications. To address the specific example in the issue of XML Schemas, RDF applications can use the namespace URI http://www.w3.org/2000/10/XMLSchema# in RDF/XML to generate the correct XML Schema concept URIs for properties and classes etc. This approach has been successfully with the DAML+OIL using RDF, RDFS and DAML terms along with XML schema data types.
Suggestion that Qnames should be allowed as values for attributes such as rdf:about.
Action: Will not be addressed in the current RDF/XML syntax since it would require changes to the syntax that would not be backwards compatible. New XML syntaxes will likely include such a feature.
Action: Will not be addressed in the current RDF/XML syntax since it is likely to require changes that would not be backwards compatible. Some help with validation can be found with the schemas for XML validation in Appendix D.
Action: ?
The RDF/XML syntax can't represent an an arbritary graph structure.
Action: Not all RDF graphs can be serialized in RDF's XML syntax. For example, graphs with cycles composed of nodes with no URIs (blank nodes in the graph), or property names that don't end in XML name characters. This is a known limitation of this syntax that can only be fully addressed by changes to it or a totally new syntax.
Action: This document [will] defines the syntax for Internet Media Type (or MIME Type) for application/rdf+xml and the registration of this type will be done when this document is stable. NOTE: This is an unregistered type at this time and should not be used in applications. See also the Draft for RDF Media Type registration by Aaron Swartz.
processing rdf:aboutEach requires a processing of sub-property relations.
Action: rdf:aboutEach is a purely syntactic construction with file scope which is resolved with respect to all rdf:_NNN triples generated by whatever syntactic means while processing the file. Hence triples generated from rdf:_NNN property elements, rdf:li property elements, rdf:bagID constructions are considered. rdf:aboutEach does not apply recursively. The document is ill-formed if during rdf:aboutEach processing rdf:_NNN triples would be constructed that would need to be considered during rdf:aboutEach processing. FIXME: clarify and provide provide test cases.
MUST a parser created bags of reified statements for all Description elements?
Action: No, only those which are explicitly reified using an rdf:ID on a propertyElt or by an rdf:bagID on the description.
Illegal or unusual use of names from the RDF namespace
Action: The grammar has[will be] been updated to define explicit lists of legal terms that are allowed at each point, along with their mapping to triples in the rdf model. Unknown or unusual use of rdf: (or rdfs:) namespace terms such as rdf:Description, which is only a syntax concept, or rdf:MadeUp, which has no mention, may add information to the RDF model but these will have no interoperability or practical use since they have no meaning in the Model Theory. They are thus not recommended. FIXME: Take a hard line here - illegal, don't do it?
The propertyElt production 6.12 of the grammar does not allow both an ID attribute and a resource attribute to be specified.
Action: Action: The grammar has[will be] been modified to forbid the use of an rdf:ID attribute on an empty property element. This is consistent with using rdf:ID="attr" as an abbreviation for rdf:about="#attr" and removes the suggestion that it reifys a statement, which it never did in the original grammar form.
What is the difference between using and ID attribute to 'create' a new resource and an about attribute to refer to it?
Action: rdf:ID="attr" is an abbreviation for rdf:about="#attr" and the handling of rdf:ID has been[will be] updated to show this.
This section contains the EBNF grammar of the RDF/XML syntax from RDF Model & Syntax Formal Grammar for RDF section. The only changes made here were to make it legal XHTML via tidy and to change the links to the productions to point to those in the original document.
[6.1] RDF ::= ['<rdf:RDF>'] obj* ['</rdf:RDF>']
[6.2] obj ::= description | container
[6.3] description ::= '<rdf:Description' idAboutAttr? bagIdAttr? propAttr* '/>'
| '<rdf:Description' idAboutAttr? bagIdAttr? propAttr* '>'
propertyElt* '</rdf:Description>'
| typedNode
[6.4] container ::= sequence | bag | alternative
[6.5] idAboutAttr ::= idAttr | aboutAttr | aboutEachAttr
[6.6] idAttr ::= ' ID="' IDsymbol '"'
[6.7] aboutAttr ::= ' about="' URI-reference '"'
[6.8] aboutEachAttr ::= ' aboutEach="' URI-reference '"'
| ' aboutEachPrefix="' string '"'
[6.9] bagIdAttr ::= ' bagID="' IDsymbol '"'
[6.10] propAttr ::= typeAttr
| propName '="' string '"' (with embedded quotes escaped)
[6.11] typeAttr ::= ' type="' URI-reference '"'
[6.12] propertyElt ::= '<' propName idAttr? '>' value '</' propName '>'
| '<' propName idAttr? parseLiteral '>'
literal '</' propName '>'
| '<' propName idAttr? parseResource '>'
propertyElt* '</' propName '>'
| '<' propName idRefAttr? bagIdAttr? propAttr* '/>'
[6.13] typedNode ::= '<' typeName idAboutAttr? bagIdAttr? propAttr* '/>'
| '<' typeName idAboutAttr? bagIdAttr? propAttr* '>'
propertyElt* '</' typeName '>'
[6.14] propName ::= Qname
[6.15] typeName ::= Qname
[6.16] idRefAttr ::= idAttr | resourceAttr
[6.17] value ::= obj | string
[6.18] resourceAttr ::= ' resource="' URI-reference '"'
[6.19] Qname ::= [ NSprefix ':' ] name
[6.20] URI-reference ::= string, interpreted per [URI]
[6.21] IDsymbol ::= (any legal XML name symbol)
[6.22] name ::= (any legal XML name symbol)
[6.23] NSprefix ::= (any legal XML namespace prefix)
[6.24] string ::= (any XML text, with "<", ">", and "&" escaped)
[6.25] sequence ::= '<rdf:Seq' idAttr? '>' member* '</rdf:Seq>'
| '<rdf:Seq' idAttr? memberAttr* '/>'
[6.26] bag ::= '<rdf:Bag' idAttr? '>' member* '</rdf:Bag>'
| '<rdf:Bag' idAttr? memberAttr* '/>'
[6.27] alternative ::= '<rdf:Alt' idAttr? '>' member+ '</rdf:Alt>'
| '<rdf:Alt' idAttr? memberAttr? '/>'
[6.28] member ::= referencedItem | inlineItem
[6.29] referencedItem ::= '<rdf:li' resourceAttr '/>'
[6.30] inlineItem ::= '<rdf:li' '>' value </rdf:li>'
| '<rdf:li' parseLiteral '>' literal </rdf:li>'
| '<rdf:li' parseResource '>' propertyElt* </rdf:li>'
[6.31] memberAttr ::= ' rdf:_n="' string '"' (where n is an integer)
[6.32] parseLiteral ::= ' parseType="Literal"'
[6.33] parseResource ::= ' parseType="Resource"'
[6.34] literal ::= (any well-formed XML)
(Note: there are EBNF bugs in the 6.30 production where the </rdf:li> tags are not fully enclosed in quotes as '</rdf:li>')
This section updates the original grammar in Section 2 by amending and deleting various productions according to the recorded RDF Core WG decisions. Some productions are also removed since they are no longer needed, once the above changes are made.
Key:
This text should be added If it is not, your
browser will not display this section properly.
This text should be deleted. If it is not, your
browser will not display this section properly.
| Production Number |
Production Name |
Definition |
|---|---|---|
| 6.1 | RDF | "<rdf:RDF>" | description |
| 6.3 | description | "<rdf:Description" idAboutAttr? bagIdAttr? propAttr* "/>" | "<rdf:Description" idAboutAttr? bagIdAttr? propAttr* ">" propertyElt* "</rdf:Description>" | typedNode |
| 6.5 | idAboutAttr | idAttr | aboutAttr | aboutEachAttr |
| 6.6 | idAttr | " rdf:ID=\"" IDsymbol "\"" |
| 6.7 | aboutAttr | " rdf:about=\"" URI-reference "\"" |
| 6.8 | aboutEachAttr | " rdf:aboutEach=\"" URI-reference "\"" |
| 6.9 | bagIdAttr | " rdf:bagID=\"" IDsymbol "\"" |
| 6.10 | propAttr | typeAttr | propName "=\"" string "\"" (with embedded quotes escaped) |
| 6.11 | typeAttr | " rdf:type=\"" URI-reference "\"" |
| 6.12 | propertyElt | "<" propName idAttr? ">" value "</" propName ">" | "<" propName idAttr? parseLiteral ">" literal "</" propName ">" | "<" propName idAttr? parseResource ">" propertyElt* "</" propName ">" | "<" propName idRefAttr? bagIdAttr? propAttr* "/>" |
| 6.13 | typedNode | "<" typeName idAboutAttr? bagIdAttr? propAttr* "/>" | "<" typeName idAboutAttr? bagIdAttr? propAttr* ">" propertyElt* "</" typeName ">" |
| 6.14 | propName | Qname |
| 6.15 | typeName | Qname |
| 6.16 | idRefAttr | idAttr | resourceAttr |
| 6.17 | value | |
| 6.18 | resourceAttr | " rdf:resource=\"" URI-reference "\"" |
| 6.19 | Qname | |
| 6.20 | URI-reference | string, interpreted per [URI] |
| 6.21 | IDsymbol | any legal XML name symbol |
| 6.22 | name | any legal XML name symbol |
| 6.23 | NSprefix | any legal XML namespace prefix |
| 6.24 | string | any XML text, with "<", ">", and "&" escaped |
| "<rdf:Seq" idAttr? memberAttr* "/>" |
||
| "<rdf:Bag" idAttr? memberAttr* "/>" |
||
| "<rdf:Alt" idAttr? memberAttr? "/>" |
||
| "<rdf:li" parseLiteral ">" literal </rdf:li>" | "<rdf:li" parseResource ">" propertyElt* </rdf:li>" |
||
| 6.32 | parseLiteral | " rdf:parseType=\"Literal\"" |
| 6.33 | parseResource | " rdf:parseType=\"Resource\"" |
| 6.34 | literal | any well-formed XML |
Two schema language authors submitted schemas for RDF/XML based on the new grammar in the previous version of this draft. We include pointers to these schemas for information purposes; they are not part of this specification.