Skip to content
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

p:set-attributes need an update due to change in document model #94

Open
xml-project opened this issue May 18, 2019 · 8 comments

Comments

Projects
None yet
4 participants
@xml-project
Copy link
Contributor

commented May 18, 2019

Currently the specs use the concept of a document element. Since we use XDM now, we have three options (I think) to update this step:

  1. We take the attributes from the first element child of the document-node.
  2. We take the attributes from all element children of the document-node.
  3. It is an error if the document on port attributes has more than one child element.

Do you see other options? Which one would you prefer?

@gimsieke

This comment has been minimized.

Copy link
Contributor

commented May 19, 2019

Do we have to say anything? If there are multiple elements below the document node and if the match pattern is /*, I think all these elements are supposed to match.

@xml-project

This comment has been minimized.

Copy link
Contributor Author

commented May 19, 2019

Sorry for being not precise: The problem is not with the document on port "source" (which is matched), but with the document on port "attributes". For this the specs say, that the attributes on the document element are copied.

@gimsieke

This comment has been minimized.

Copy link
Contributor

commented May 19, 2019

Ah, I see. Maybe replace “document element“ with “top-level element(s)”, also in other contexts.

I’d suggest: In case there are multiple attributes with the same name coming from the attributes port, the last in document order wins.

About the last sentence in the spec:

If an attribute named xml:base is added or changed, the base URI of the element must also be amended accordingly.

  1. I think in the previous statement, “must” is an obligation of the XProc processor, not the pipeline author. Do we need to state this more unambiguously?
  2. Should the result document’s base-uri property also be changed accordingly if an xml:base attribute is added?
  3. What’s the value of the result document’s base URI supposed to be if only the second top-level element of the source port is matched and its xml:base attribute then differs from the first’s?
@eriksiegel

This comment has been minimized.

Copy link
Contributor

commented May 20, 2019

Agree with:

replace “document element“ with “top-level element(s)”, also in other contexts.

The other points:

  1. Maybe, but I think that;s implicit
  2. Of course
  3. Maybe we should then act as if it was the top-level element and change the base-uri of the whole document?
@ndw

This comment has been minimized.

Copy link
Collaborator

commented May 23, 2019

In order to avoid the problem of what to do about repeated attributes, I think we should accept an element node or a document node with a single element child. I'd make it an error to pass in anything else, including a document node with multiple element children.

@gimsieke

This comment has been minimized.

Copy link
Contributor

commented May 23, 2019

Are you thinking of restricting the attributes port only?

As I said, multiple top-level elements in the source doc can be problematic, too, because you can end up with different @xml:base attributes. If @match is such that only one of the top-level elements receives a different @xml:base, the processor won’t know whether to keep the base URI or use the new one.

So either enforce single-top-level-element docs on each port, or stipulate that if an @xml:base attribute is added, it must be added to each of the top-level elements.

Everyone’s life will be easier I guess if we restrict both source and attributes to single-top-level-element documents.

(We should probably introduce shorthand terms for single-top-level-element documents and potentially-multiple-top-level-element documents…)

@ndw

This comment has been minimized.

Copy link
Collaborator

commented May 23, 2019

23 May editorial consensus: say that it's implementation dependent what base URI property is set if you end up with multiple top-level elements that have xml:base attributes.

@xml-project

This comment has been minimized.

Copy link
Contributor Author

commented Jun 14, 2019

As I was not able to attend the editorial meeting on 23 May: Could someone please spell out to me what the consensus (apart from @base-uri) was.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.