New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarify serialization in p:document-properties-map #608

Merged
merged 2 commits into from Nov 2, 2018

Conversation

Projects
None yet
3 participants
@ndw
Contributor

ndw commented Oct 31, 2018

Fix #573
Ths PR attempts to clarify how p:document-properties-document serializes the properties. This is a convenience function to make processing properties with pipeline steps easier. I think that complicated property values are going to be uncommon and perfect fidelity is not a goal of this function. But you may disagree :-)

@ndw ndw requested review from eriksiegel, xml-project and gimsieke Oct 31, 2018

@xml-project

From my point of view this is a topic for this afternoon, isn't it?

@ndw

This comment has been minimized.

Contributor

ndw commented Nov 1, 2018

Sure, we can talk about it this afternoon.

@gimsieke
  1. We didn’t specify the namespace URI for the xsi prefix yet
  2. What if a map or array contains XML nodes, in particular documents or elements, as values? Then a JSON serialization would not be useful.

Given that maps or arrays as document properties might not be that common, or if they are used, pipeline authors who are interested in these map or array values will probably prefer to invoke p:document-property() anyway, I could also live with the following alternative. It gives implementers the freedom to just omit map or array values:

It is implementation-defined whether document property values that consist of maps or arrays are included in the document properties document at all, and if they are included, how they are represented. If a property value is a map or an array, an xsi:type attribute must be given, and the xsi:type attribute value must start with map or array, respectively. This way, consumers of the document properties document can choose to invoke the p:document-property() function for the key in question in order to retrieve the property value.

@gimsieke

This comment has been minimized.

Contributor

gimsieke commented Nov 1, 2018

For xsi:type, we can link to https://www.w3.org/TR/xmlschema11-1/#xsi_type.
I see that its value must be a QName, therefore it will be hard to use something like as="map(*)" for xsi:type. Instead of xsi:type, we could use an as attribute that holds a sequence type, or we could invent xsi:type="map:any" with xmlns:map="http://www.w3.org/2005/xpath-functions/map" (similarly, array:any).
Why did we use xsi:type instead of as (sequence type) anyway?

@ndw

This comment has been minimized.

Contributor

ndw commented Nov 1, 2018

Implementation-defined is fine by me.

I proposed xsi:type because it's a document that we're producing and that's the standard way to represent types in XSD. It does present a problem for arrays and maps though. Writing XPath expressions to decompose a complicated sequence type isn't going to be fun. And I'm not sure about the consequences of inventing our own type QName. If someone runs that through a process that attempts to do any kind of validation, it's going to fall over because there won't be an XSD declaration for the type.

We could just stipulate "map='true'" or "array='true'" for maps and arrays.

@ndw

This comment has been minimized.

Contributor

ndw commented Nov 2, 2018

Right. I made it implementation defined.

@ndw ndw merged commit c4a2878 into xproc:master Nov 2, 2018

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details

@ndw ndw deleted the ndw:iss-573 branch Nov 2, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment