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

should make-element default to the default namespace or ""? #9

Open
slyrus opened this issue Nov 3, 2019 · 2 comments
Open

should make-element default to the default namespace or ""? #9

slyrus opened this issue Nov 3, 2019 · 2 comments

Comments

@slyrus
Copy link

slyrus commented Nov 3, 2019

Currently, if we do:

(let ((foo (fxml.stp:make-element "foo" "http://foo.example.com")))
  (fxml.stp:append-child
   foo
   (let ((element (fxml.stp:make-element "BarElement")))
     (setf (fxml.stp:attribute-value element "firstAttribute") "works")
     element))
  (let ((doc (fxml.stp:make-document foo)))
    (fxml.stp:serialize
     doc
     (fxml:make-character-stream-sink *standard-output* :indentation 2))))

We get a namespace of xmlns="" in the BarElement definition. I was hoping to just not have an xmlns attribute, meaning that the definition of BarElement would pick up the default namespace (http://foo.example.com). In order to get that behavior I have to explicitly provide the uri. Is this the expected/intended behavior?

@ruricolist
Copy link
Owner

I'll have to do some research first to make sure this isn't what XML mandates.

@slyrus
Copy link
Author

slyrus commented Nov 5, 2019

I'd argue that XML doesn't mandate anything about how are API works. But the parallel with XML is that if we don't specify and xmlns, we pick up the current default. Whereas our API results in not specifying an xmlns yielding xmlns="". But if were to implement things as I suggested, it would mean that the actual xmlns of an element wouldn't be known until the default namespace was known, that is to say that if you make some nodes and move them around, the actual NS could change. I can see arguments for both kinds of behaviors, but the current one seems a bit unintuitive to me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants