N/A
OASIS eXtensible Access Control Markup Language (XACML) TC
This specification is a profile of ACAL that provides ACAL extensions based on the JSONPath standard, such as JSONPath-based AttributeSelector.
When referencing this document, the following citation format should be used:
[ACAL-JSONPath-1.0] ACAL v1.0 JSONPath Profile Version 1.0. Edited by Steven Legg and Cyril Dangerville. 18 February 2026. OASIS Committee Specification Draft 01. https://docs.oasis-open.org/xacml/acal/acal/profiles/jsonpath/v1.0/csd01/acal-jsonpath-v1.0-csd01.html. Latest stage: https://docs.oasis-open.org/xacml/acal/acal/profiles/jsonpath/v1.0/csd01/acal-jsonpath-v1.0-csd01.html.
This document is related to:
Copyright © OASIS Open 2026. All Rights Reserved. For license and copyright information, and complete status, please see Annex A which contains the License, Document Status and Notices.
This ACAL profile defines concrete types of [ACAL-Core-1.0] AttributeSelector
and EntityAttributeSelector using JSONPath [RFC9535] expressions to extract attributes from
ACAL Request's Content.
Concrete representations (data formats) are to be provided as separate specifications and therefore out of scope of this document.
This document uses the following terms defined elsewhere:
See Section 2 of [ACAL-Core-1.0].
None.
None.
None.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
None.
JSON is a common format to represent structured objects that may be supplied by the PEP as subject attribute or resource attribute's Content inside the Request to the PDP, typically a JSON Web token (JWT) in the case of subject attributes (JWT is commonly used in OpenID Connect and OAuth protocols), or any JSON document as resource data. JSON is a common data exchange format used by Web APIs. For such cases, supporting JSONPath [RFC9535] expressions in ACAL is the standard way and therefore a must-have to extract the necessary values from the JSON content for policy evaluation. For instance, a common rule of a privacy policy is that a person should be allowed to read records (in JSON) for which he or she is the subject. The corresponding policy must contain a reference - JSONPath expression - to the subject identified in the information resource - JSON record - itself.
Attribute selectors (AttributeSelectorType objects)
defined by this profile use a JSONPath expression [RFC9535] over the
ContentType object of the subject (resp. resource) to
identify a particular subject (resp. resource) attribute value by its
location in the context (see Section 4.11 of [ACAL-Core-1.0] for an explanation of
context).
None. This is the first version of this profile.
This profile applies to a Content object (defined in [ACAL-Core-1.0]) in the Request if and only
if:
MediaType property is set to
application/json.Body property value is a JSON object. Note that
it is always possible to encapsulate a JSON array inside a JSON object
if a JSON array is really needed.The structures in this profile are extensions to [ACAL-Core-1.0] model and described here in abstract terms. The concrete representations of these structures are defined for a variety of syntaxes each in a separate profile.
The types AttributeSelectorType and
EntityAttributeSelectorType used in the next UML models are
defined in [ACAL-Core-1.0].
A JSONPathAttributeSelectorType object is a concrete
type of AttributeSelectorType from [ACAL-Core-1.0] that uses JSONPath (RFC9535) for Path expressions and
expects a JSON object as value of the Body property of a
RequestEntityType object's Content object.
More precisely, the returned values shall be constructed from the
node(s) selected by applying the JSONPath expression given by the
attribute selector's Path property to the JSON object in
the Body property of the Content object in the
RequestEntityType object matching the attribute selector's
Category property.
See the section 9 for details of attribute selector evaluation.
UML definition (class diagram):
In the context of this profile, the required Path
property inherited from the supertype AttributeSelectorType
SHALL be a JSONPath expression RFC9535.
A JSONPathEntityAttributeSelectorType object is a
concrete type of EntityAttributeSelectorType [ACAL-Core-1.0] that uses JSONPath RFC9535 for Path expressions and
expects a JSON object in the value returned by the attribute selector's
Expression property. In other words, the values shall be
constructed from the node(s) selected by applying the JSONPath
expression given by the entity attribute selector's Path
property to the JSON object of the Body property of the
Content object in either an attribute category in the
request context (RequestEntity) or the value of the
urn:oasis:names:tc:acal:1.0:data-type:entity data type
returned by its Expression evaluation.
See the Section 9 for details of entity attribute selector evaluation.
UML definition (class diagram):
The Path property is also defined the same as in
JSONPathAttributeSelectorType.
JSONPathAttributeSelectorType or
JSONPathEntityAttributeSelector object SHALL be evaluated
according to the following processing model.Note: It is not necessary for an implementation to exactly follow this model. It is only necessary to produce results identical to those that would be produced by following this model.
The first steps are already described in [ACAL-Core-1.0] section 9.4.7 and provided here as a reminder:
If the attribute category given by the Category
property is not found or does not have a Content property,
then the return value is either Indeterminate or an empty
bag as determined by the MustBePresent property.
If the Expression property of an
JSONPathEntityAttributeSelector object evaluates to a value
of the urn:oasis:names:tc:acal:1.0:data-type:entity data
type and that value does not have a Content property, then
the return value is either Indeterminate or an empty bag as
determined by the MustBePresent property.
If the Expression property of an
JSONPathEntityAttributeSelector object evaluates to a value
of the urn:oasis:names:tc:acal:1.0:data-type:anyURI data
type and an attribute category with that value as its
Category is not found or does not have a
Content property, then the return value is either
Indeterminate or an empty bag as determined by the
MustBePresent property.
If the designated attribute category or entity value has a
Content property, then follow the steps below:
Construct a JSON object (RFC 8259) from the value of the
Body property of the Content property. If the
content is not a valid JSON object, then the attribute selector MUST
return Indeterminate with status code
urn:oasis:names:tc:acal:1.0:status:syntax-error.
The root node of the data structure (JSON object) shall be used as context node of evaluation (JSONPath query argument).
Evaluate the JSONPath expression given in the Path
property against the context node selected in the previous step,
according to the syntax and semantics of the JSONPath standard
[RFC9535].
The result of the previous step is a nodelist that is converted
to a bag of values of the data type specified by the
DataType property. In most cases the conversion depends on
the string value of a node's JSON value, defined as follows:
The string value of a JSON string value is the sequence of Unicode characters represented by the text between the surrounding double quotes, i.e., with each escape sequence replaced with its equivalent Unicode character.
The string value of the special JSON value true,
false or null is the equivalent sequence of
Unicode characters.
The string value of a JSON number is the equivalent sequence of Unicode characters.
The string value of a JSON array is the empty string.
The string value of a JSON object is the empty string.
DataType property as follows:
urn:oasis:names:tc:acal:1.0:data-type:boolean, then convert
the string value of each node using the xs:boolean()
constructor function from [XF] Section 18.1.
urn:oasis:names:tc:acal:1.0:data-type:string, then convert
the string value of each node using the xs:string()
constructor function from [XF] Section 18.1.
urn:oasis:names:tc:acal:1.0:data-type:integer, then convert
the string value of each node using the xs:integer()
constructor function from [XF] Section 18.1.
urn:oasis:names:tc:acal:1.0:data-type:double, then convert
the string value of each node using the xs:double()
constructor function from [XF] Section 18.1.
urn:oasis:names:tc:acal:1.0:data-type:dateTime, then
convert the string value of each node using the
xs:dateTime() constructor function from [XF] Section 18.1.
urn:oasis:names:tc:acal:1.0:data-type:date, then convert
the string value of each node using the xs:date()
constructor function from [XF] Section 18.1.
urn:oasis:names:tc:acal:1.0:data-type:time, then convert
the string value of each node using the xs:time()
constructor function from [XF] Section 18.1.
urn:oasis:names:tc:acal:1.0:data-type:hexBinary, then
convert the string value of each node using the
xs:hexBinary() constructor function from [XF] Section 18.1.
urn:oasis:names:tc:acal:1.0:data-type:base64Binary, then
convert the string value of each node using the
xs:base64Binary() constructor function from [XF] Section 18.1.
urn:oasis:names:tc:acal:1.0:data-type:anyURI, then convert
the string value of each node using the xs:anyURI()
constructor function from [XF] Section 18.1.
urn:oasis:names:tc:acal:1.0:data-type:yearMonthDuration,
then convert the string value of each node using the
xs:yearMonthDuration() constructor function from [XF] Section 18.1.
urn:oasis:names:tc:acal:1.0:data-type:dayTimeDuration, then
convert the string value of each node using the
xs:dayTimeDuration() constructor function from [XF] Section 18.1.
urn:oasis:names:tc:acal:1.0:data-type:entity and the value
of every node in the nodelist is a JSON object, then convert each node
to an ACAL EntityType object. Each EntityType
object SHALL have a Content property and SHALL NOT have an
Attribute property. The Content property SHALL
have a MediaType property set to
application/json and the value of the Body
property SHALL be a copy of the JSON object.
Indeterminate with status code
urn:oasis:names:tc:acal:1.0:status:syntax-error.
Indeterminate with
status code
urn:oasis:names:tc:acal:1.0:status:syntax-error.
Indeterminate, with status code
urn:oasis:names:tc:acal:1.0:status:processing-error
Indeterminate with status code
urn:oasis:names:tc:acal:1.0:status:syntax-error, or an
empty bag, as determined by the MustBePresent property.
An implementation can be optimized to emit errors without going to
the effort of generating the string value of node values. For example,
the string value of a JSON number will never have the correct format for
a urn:oasis:names:tc:acal:1.0:data-type:dateTime ACAL
value, so this combination will always produce an error.
Refer to [ACAL-Core-1.0] section 10, and Section 4 (Security Considerations) of RFC 9535.
The specification addresses the following aspect of conformance:
The specification defines a number of functions, etc. that have somewhat special applications, therefore they are not required to be implemented in an implementation that claims to conform with to this specification.
Note: "M" means mandatory-to-implement. "O" means optional.
The implementation MUST follow Section 5, Section 6 and Annex D where they apply to implemented items in the following tables.
Many of these items are associated with versions of XACML preceding
ACAL but have been assigned new identifiers with the
urn:oasis:names:tc:acal:1.0: prefix. The older XACML
identifiers have been listed in the tables as deprecated identifiers.
Implementations MUST support a new identifier defined in this
specification but MAY recognize the corresponding deprecated identifier
as equivalent. It is RECOMMENDED that these deprecated identifiers not
be used in new policies and requests; they are planned to be removed in
a subsequent version of ACAL. Note that some items appear to be carried
over from a preceding version of XACML but do not list the XACML
identifier. This is because ACAL has redefined the item in some way that
means it is no longer identical to the original definition in XACML, and
so the identifiers can no longer be considered equivalent. Items new to
ACAL 1.0 will also not list an XACML identifier.
The implementation MUST support the object types that are marked
M.
| Object Type | M/O |
|---|---|
| JSONPathAttributeSelectorType | M |
| JSONPathEntityAttributeSelectorType | O |
(This annex forms an integral part of this Specification.)
This document was last revised or approved by the OASIS eXtensible Access Control Markup Language (XACML) TC on the above date. The level of approval is also listed above. Check the "Latest version" location noted above for possible later revisions of this document. Any other numbered Versions and other technical work produced by the Technical Committee (TC) are listed at https://groups.oasis-open.org/communities/tc-community-home2?CommunityKey=67afe552-0921-49b7-9a85-018dc7d3ef1d#technical.
TC members should send comments on this document to the TC's email list. Others should send comments to the TC's public comment list, after subscribing to it by following the instructions at the "Send A Comment" button on the TC's web page at https://www.oasis-open.org/committees/xacml/.
NOTE: any machine-readable content (Computer Language Definitions) declared Normative for this Work Product is provided in separate plain text files. In the event of a discrepancy between any such plain text file and display content in the Work Product's prose narrative document(s), the content in the separate plain text file prevails.
Copyright © OASIS Open 2026. All Rights Reserved.
All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full Policy, which governs the licensure of this document, may be found at the OASIS website: [https://www.oasis-open.org/policies-guidelines/ipr/]
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns, as provided in the OASIS IPR Policy.
This document is provided under the RF on Limited Terms IPR mode that was chosen when the project was established, as defined in the IPR Policy. For information on whether any patents have been disclosed that may be essential to implementing this document, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the project’s web page (https://www.oasis-open.org/committees/xacml/ipr.php).
This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. OASIS AND ITS MEMBERS WILL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF ANY USE OF THIS DOCUMENT OR ANY PART THEREOF.
As stated in the OASIS IPR Policy, the following three paragraphs in brackets apply to OASIS Standards Final Deliverable documents (Committee Specifications, OASIS Standards, or Approved Errata).
OASIS requests that any OASIS Party or any other party that believes it has patent claims that would necessarily be infringed by implementations of this OASIS Standards Final Deliverable, to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this deliverable.
OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of any patent claims that would necessarily be infringed by implementations of this OASIS Standards Final Deliverable by a patent holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this OASIS Standards Final Deliverable. OASIS may include such claims on its website, but disclaims any obligation to do so.
OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this OASIS Standards Final Deliverable or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS' procedures with respect to rights in any document or deliverable produced by an OASIS Technical Committee can be found on the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this OASIS Standards Final Deliverable, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any information or list of intellectual property rights will at any time be complete, or that any claims in such list are, in fact, Essential Claims.
The name "OASIS" is a trademark of OASIS, the owner and developer of this document, and should be used only to refer to the organization and its official outputs. OASIS welcomes reference to, and implementation and use of, its documents, while reserving the right to enforce its marks against misleading uses. Please see https://www.oasis-open.org/policies-guidelines/trademark/ for guidance.
(This annex forms an integral part of this Specification.)
This section contains the normative and informative references that are used in this document.
Normative references are specific (identified by date of publication and/or edition number or version number) and Informative references are either specific or non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the reference document (including any amendments) applies. While any hyperlinks included in this section were valid at the time of publication, OASIS cannot guarantee their long term validity.
The following documents are referenced in such a way that some or all of their content constitutes requirements of this document.
Attribute-Centric Authorization Language (ACAL) Version 1.0. Edited by Steven Legg and Cyril Dangerville. 18 February 2026. OASIS Committee Specification Draft 01.
Martin J. Dürst et al, eds., Character Model for the World Wide Web 1.0: Fundamentals, W3C Recommendation 15 February 2005, https://www.w3.org/TR/2005/REC-charmod-20050215/
D. Eastlake et al., XML-Signature Syntax and Processing, https://www.w3.org/TR/xmldsig-core/, World Wide Web Consortium.
J. Boyer et al, eds., Exclusive XML Canonicalization, Version 1.0, W3C Recommendation 18 July 2002, https://www.w3.org/TR/2002/REC-xml-exc-c14n-20020718/
Hancock, Polymorphic Type Checking, in Simon L. Peyton Jones, Implementation of Functional Programming Languages, Section 8, Prentice-Hall International, 1987.
XACML v3.0 Hierarchical Resource Profile Version 1.0. 11 March 2010. Committee Specification Draft 03. https://docs.oasis-open.org/xacml/3.0/xacml-3.0-hierarchical-v1-spec-cd-03-en.html
IEEE Standard for Binary Floating-Point Arithmetic 1985, ISBN 1-5593-7653-8, IEEE Product No. SH10116-TBR.
XML Information Set (Second Edition), W3C Recommendation, 4 February 2004, https://www.w3.org/TR/xml-infoset/
ISO/IEC 10181-3:1996 Information technology – Open Systems Interconnection -- Security frameworks for open systems: Access control framework.
Kudo M and Hada S, XML document security based on provisional authorization, Proceedings of the Seventh ACM Conference on Computer and Communications Security, Nov 2000, Athens, Greece, pp 87-96.
RFC 2256, A summary of the X500(96) User Schema for use with LDAPv3, Section 5, M Wahl, December 1997, https://www.ietf.org/rfc/rfc2256.txt
RFC 2798, Definition of the inetOrgPerson, M. Smith, April 2000, https://www.ietf.org/rfc/rfc2798.txt
Mathematical Markup Language (MathML), Version 2.0, W3C Recommendation, 21 October 2003, https://www.w3.org/TR/2003/REC-MathML2-20031021/
OASIS Committee Draft 03, XACML v3.0 Multiple Decision Profile Version 1.0, 11 March 2010, https://docs.oasis-open.org/xacml/3.0/xacml-3.0-multiple-v1-spec-cd-03-en.doc
Perritt, H. Knowbots, Permissions Headers and Contract Law, Conference on Technological Strategies for Protecting Intellectual Property in the Networked Multimedia Environment, April 1993. Available at: https://www.cni.org/resources/historical-resources/technological-strategies-for-protecting-intellectual-property-in-the-networked-multimedia-environment/permission-headers-and-contract-law
David Ferraiolo and Richard Kuhn, Role-Based Access Controls, 15th National Computer Security Conference, 1992.
Key Words for Use in RFCs to Indicate Requirement Levels, BCP 14, RFC 2119, March 1997. [Online]. Available: https://www.rfc-editor.org/info/rfc2119
RFC 2396, Berners-Lee T, Fielding R, Masinter L, Uniform Resource Identifiers (URI): Generic Syntax, https://www.ietf.org/rfc/rfc2396.txt
Hinden R, Carpenter B, Masinter L, Format for Literal IPv6 Addresses in URL's, https://www.ietf.org/rfc/rfc2732.txt
IETF RFC 3198: Terminology for Policy-Based Management, November 2001. https://www.ietf.org/rfc/rfc3198.txt
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words, BCP 14, RFC 8174, May 2017. [Online]. Available: https://www.rfc-editor.org/info/rfc8174
RFC 9535, JSONPath: Query Expressions for JSON, February 2024. [Online]. Available: https://datatracker.ietf.org/doc/html/rfc9535
Mark Davis, Martin Dürst, Unicode Standard Annex #15: Unicode Normalization Forms, Unicode 5.1, https://unicode.org/reports/tr15/
Davis, Mark, Suignard, Michel, Unicode Technical Report #36: Unicode Security Considerations, https://www.unicode.org/reports/tr36/
OASIS Committee Draft 03, XACML v3.0 Administration and Delegation Profile Version 1.0. 11 March 2010, https://docs.oasis-open.org/xacml/3.0/xacml-3.0-administration-v1-spec-cd-03-en.doc
XPath and XQuery Functions and Operators 3.1, 21 March 2017, https://www.w3.org/TR/2017/REC-xpath-functions-31-20170321/
Bray, Tim, et.al. eds, Extensible Markup Language (XML) 1.0 (Fifth Edition), W3C Recommendation 26 November 2008, https://www.w3.org/TR/2008/REC-xml-20081126/
Marsh, Jonathan, et.al. eds, xml:id Version 1.0. W3C Recommendation 9 September 2005, https://www.w3.org/TR/2005/REC-xml-id-20050909/
XML Schema 1.1, parts 1 and 2. Available at: https://www.w3.org/TR/xmlschema11-1/ and https://www.w3.org/TR/xmlschema11-2/
XML Path Language (XPath) 3.1, W3C Recommendation 21 March 2017, https://www.w3.org/TR/xpath-31/
W3C XQuery, XPath, and XSLT Functions and Operators Namespace Document (XPath and XQuery Functions and Operators 3.1) 21 March 2017, https://www.w3.org/2005/xpath-functions/
XSL Transformations (XSLT) Version 1.0, W3C Recommendation 16 November 1999, https://www.w3.org/TR/xslt/
The following referenced documents are not required for the application of this document but may assist the reader with regard to a particular subject area.
Character Model for the World Wide Web: String Matching W3C Working Group Note 11 August 2021, https://www.w3.org/TR/charmod-norm/, World Wide Web Consortium.
Hinton, H, M, Lee, E, S, The Compatibility of Policies, Proceedings 2nd ACM Conference on Computer and Communications Security, Nov 1994, Fairfax, Virginia, USA.
Black, P. (2020), DADS: The On-Line Dictionary of Algorithms and Data Structures, NIST Interagency/Internal Report (NISTIR), National Institute of Standards and Technology, Gaithersburg, MD, online (Accessed December 16, 2025)
Sloman, M. Policy Driven Management for Distributed Systems. Journal of Network and Systems Management, Volume 2, part 4. Plenum Press. 1994.
eXtensible Access Control Markup Language (XACML) Version 3.0 Plus Errata 01. Edited by Erik Rissanen. OASIS Standard incorporating Approved Errata. https://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-en.html.
XACML v3.0 Related and Nested Entities Profile Version 1.0. Edited by Steven Legg. 16 February 2021. OASIS Committee Specification 02. https://docs.oasis-open.org/xacml/xacml-3.0-related-entities/v1.0/cs02/xacml-3.0-related-entities-v1.0-cs02.html. Latest stage: https://docs.oasis-open.org/xacml/xacml-3.0-related-entities/v1.0/xacml-3.0-related-entities-v1.0.html.
(This annex forms an integral part of this Specification.)
This section defines standard identifiers for commonly used definitions.
This ACAL Profile is defined using this identifier.
urn:oasis:names:tc:acal:1.0:jsonpath:schema
HTML/PDF versions are generated automatically online via Github Actions after each update pushed to the main branch of OASIS XACML TC Github repository. Go to Github Actions on the github repository, then go to the latest workflow run, and, if the run succeeded, the summary should display the links to the generated HTML/PDF documents.
Install Pandoc, Graphviz and PlantUML on your system; or simply use Docker with the following shell alias:
$ alias pandoc='docker run --rm --volume "$(pwd):/data" cdang/pandoc-plantuml'The Dockerfile (named Dockerfile) of the docker
image used in the alias above is provided in the pandoc folder next to this markdown file for your
convenience if you wish to build it yourself.
OASIS staff are currently using pandoc 3.0 from https://github.com/jgm/pandoc/releases/tag/3.0.
Git clone or get a local copy of OASIS XACML TC Github repository, open a terminal and change your working directory to the root directory of your local copy of the repository.
The generation command uses a CSS stylesheet file (-c
argument) provided by OASIS. It may be changed to one of these (or the
local version in the styles folder) to get a different
style of output:
Run the following command line to generate HTML from this markdown
file (acal-jsonpath-v1.0-csd01.md) to an output file
/tmp/acal-jsonpath-v1.0-csd01.html:
$ pandoc -f gfm+definition_lists -t html -c styles/markdown-styles-v1.7.3a.css -s --lua-filter pandoc/diagram.lua --defaults pandoc/defaults.yaml --embed-resources --metadata title=" " -o /tmp/acal-jsonpath-v1.0-csd01.html acal-jsonpath-v1.0-csd01.md Note this command generates a Table of Contents (TOC) in HTML which is located at the top of the HTML document, and which requires additional editing in order to be published in the expected OASIS style. This editing will be handled by OASIS staff during publication.
For PDF output (file /tmp/acal-jsonpath-v1.0-csd01.pdf),
the command line is the following (different -t and
-H arguments):
$ pandoc -f gfm+definition_lists -t pdf -c styles/markdown-styles-v1.7.3a.css -H pandoc/custom_latex_header_for_pandoc_pdf_output.tex -s -L pandoc/diagram.lua --defaults pandoc/defaults.yaml --metadata title=" " --embed-resources -o /tmp/acal-jsonpath-v1.0-csd01.pdf acal-jsonpath-v1.0-csd01.md (This appendix does not form an integral part of this Specification and is informational.)
The following individuals have had significant leadership positions during the development of this document, not just this version of the document, and they are gratefully acknowledged:
The following individuals have made substantial contributions to this document, not just this version of the document, and their contributions are gratefully acknowledged:
The following individuals were members of this committee during the creation of this document, not just this version of the document, and their contributions are gratefully acknowledged:
XACML TC Members:
(This appendix does not form an integral part of this Specification and is informational.)
This is the first version of this profile.
Latest revision history can be obtained from OASIS XACML TC's github repository.
________________________________________