- From: Norman Walsh <ndw@nwalsh.com>
- Date: Thu, 22 Jan 2009 13:12:54 -0500
- To: public-xml-processing-model-wg@w3.org
- Message-ID: <m2ocxz43bt.fsf@nwalsh.com>
See http://www.w3.org/XML/XProc/2009/01/22-minutes
[1]W3C
- DRAFT -
XML Processing Model WG
Meeting 134, 22 Jan 2009
[2]Agenda
See also: [3]IRC log
Attendees
Present
Norm, Paul, Mohamed, Henry, Vojtech, Alex
Regrets
Chair
Norm
Scribe
Norm
Contents
* [4]Topics
1. [5]Accept this agenda?
2. [6]Accept minutes from the previous meeting?
3. [7]Next meeting: telcon 29 Jan 2009?
4. [8]CR comments
5. [9]004: preserving base URI
6. [10]015 p:uuid question
7. [11]022 p:http-request default method
8. [12]023 p:http-request - POST with no c:body
9. [13]035 instance name visible to custom step
10. [14]017 p:xquery and XQueries that cannot be evaluated.
11. [15]021 Replacing the document node in p:string-replace
12. [16]025 p:unescape-markup "namespace"
13. [17]Any other business?
* [18]Summary of Action Items
--------------------------------------------------------------------------
Considering which issues to discuss (apologies again for not providing
more notice; I'll try to do better next week): 004 (again) 015, 022, 023,
035.
More possibilities: 017, 021, 025, 026, 027
Accept this agenda?
-> [19]http://www.w3.org/XML/XProc/2009/01/22-agenda
Accepted.
Accept minutes from the previous meeting?
-> [20]http://www.w3.org/XML/XProc/2009/01/08-minutes
Accepted.
Next meeting: telcon 29 Jan 2009?
Paul gives regrets.
CR comments
-> Topic: Next meeting: telcon 29 Jan 2009?
-> [21]http://www.w3.org/XML/XProc/2008/11/cr-comments/
004: preserving base URI
Henry: This whole thing is hugely complicated and it's not made at all
easier by the fact that none of the relevant XML specs are really
consistent with one another.
... It's not the case that it's easy for us to say that we should do it
like everyone else, because they all do it differently.
... The Infoset says that if you assemble a document out of multiple
general entities, the base URI changes accordingly.
... But it doesn't have a serialization or any sort of base URI fixup.
... On the other end of the spectrum, XInclude (V1) said that you had to
insert xml:base attributes and change the infoset.
... In the middle, we have XSLT which will change the base URI if you add
xml:base attributes, but can't preserve them when copying.
... So the one observation that Richard made that I point to in this
email:
->
[22]http://lists.w3.org/Archives/Public/public-xml-processing-model-comments/2009Jan/0012.html
scribe: is that XML Base is a bit like character entities or namespace
declarations. They're there in order to effect the infoset, but they're
not part of the document. They're metadata.
... And therefore, there's no guarantee that they're going to be there
when you serialize.
... So it's not completely outrageous to think that you might loose base
URI information when you serialize.
Alex: It seems that if you delete the xml:base attribute, then you get
what you deserve if you really wanted to preserve the base URI.
Henry: At the moment, I'm inclined towards the position that we should
sort of follow XSLT: if you delete an xml:base attribute, it does not
change the base URI attribute of the element.
Alex: But you lose it if you serialize.
Henry: Yes. In the same way that a parser takes account of general entity
structure and the base URIs, but they won't be preserved when yous
serialize.
... What Richard eventually conceded, is that if we leave the spec the way
it is, he can still serialize between steps and carry the base URI
out-of-band.
Straw poll: Removing the xml:base attribute (a) removes the base URI
property from the infoset or (b) does not change it.
Results: Five for (b) no change, 1 abstention.
Vojtech: If I really want to remove the base URI information, then I
should ... add an xml:base attribute with the value from the parent.
Some discussion of serialization.
Henry: Are we also in agreement that we do have to update the spec
everywhere you can do something that can add or change the value of an
attribute to say that if the attribute is added/changed is the xml:base
attribute, this causes a change to the XML base property.
Norm: Anyone who disagrees?
None heard.
<scribe> ACTION: Norm to edit the spec so that we say that any change to
xml:base or adding an xml:base does change the underlying infoset
property. [recorded in
[23]http://www.w3.org/2009/01/22-xproc-minutes.html#action01]
015 p:uuid question
Vojtech: The question of whether it generates one UUID or many has been
answered: it generates one UUID.
... The remaining question is whether this step needs additional options
or parameters.
Norm: Do we know what the parameters/options are?
Some discussion of the various types of UUID.
Norm: I think the question is, do we leave other versions
implementation-defined, or do we try to add parameters/options to make it
interoperable.
Alex: I think we should provide the options.
Vojtech: In Java you can generate type 3.
... I was thinking maybe it was sufficient to do for p:uuid what we do for
p:hash
Norm: To be honest, I think for V1 we should just make the parameters that
are needed for other UUID formats implementation defined.
More discussion about the virtues of parameters instead of extension
attributes.
Vojtech: Why don't we just say that the only supported version is version
4.
Alex: I guess I could live with implementation defined.
Proposal: Implementations must support version=4, support for other
versions (and how options/parameters are provided for those versions) is
implementation-defined.
Accepted.
022 p:http-request default method
Norm: If you don't specify a method on p:http-request, do we work it out
dynamically or do we make method required?
Alex: I think we should make it a required attribute.
Norm: That's what I thought too, in email following up.
Proposal: The method is required, it is an error to attempt to use
p:http-request without a specified method.
Accepted.
023 p:http-request - POST with no c:body
Vojtech: I think that's clear now, you can do a post a body.
Norm: Is there any distinction between no c:body and an empty c:body?
Alex: I think if you specify an empty body, you get a content-length: 0,
and if you don't specify a body, you don't get any entity body.
Proposal: Yes, you can have a POST with no c:body element.
Accepted.
035 instance name visible to custom step
Norm: I think James is asking for the ability to get the step name without
passing it as a separate option. Looks like creeping featurism to me: not
in V1?
Proposal: Not in V1.
Accepted.
017 p:xquery and XQueries that cannot be evaluated.
Vojtech: I thought that in the XQuery step we should have an error for
reporting bad XQuery.
Norm: A particular error code for "couldn't understand the query"?
Vojtech: Yes, I think we could put all the possible errors in one error
code.
Alex: Could we add an error for "unable to process input", we could use it
for XSLT, XQuery, XML Formatter. I could use it for a SPARQL step if I had
one, etc.
... These could apply to the validator steps as well.
Proposal: A generic error for "unable to process input/input format
wrong/etc." that all steps (including custom steps) can throw when
appropriate.
Accepted.
021 Replacing the document node in p:string-replace
Vojtech: I was wondering what happens if you replace the document element
with an empty string in p:string-replace.
... Does this call XD0001?
... One of the answers was 'yes'.
Norm: Yep, that works for me.
Vojtech: I was trying to write a test for this.
Norm: We don't require processors to produce exactly the right errors, but
it's still good to be clear.
Proposal: Close without action.
Accepted.
025 p:unescape-markup "namespace"
Vojtech: You can have a wrapper element which if you unesacpe the content
then you get five elements inside. The text about unescape-markup talks
about a single document element.
... I think that phrasing should be changed so that it covers the case
where unescaping gives five elements (or no elements) in the wrapper.
... I think it should be applied to each of the elements in the wrapper.
Alex: The way I look at this is, when you provide the default namespace,
it's like you're wrapping the whole thing in a pseudo-element that you can
throw away.
... that's effectively the behavior.
Norm: It sounds like this is mostly editorial, handling the case where
there are multiple or no elements.
Vojtech: Issue 080 is related: if you specify a namespace but the
unescaped content already has a default namespace.
... Or if the element declares other namespaces. Are they effected?
Alex: If you take the escaped content, treat it as if it was wrapped in an
element with a default namespace declaration, and then take it's children.
That's what should happen.
Norm: I think the practical upshot is that the answer is that if there are
default namespace bindings in the content, those bindings "win" and it has
no effect on any other namespace declarations.
Vojtech: The spec currently gives the impression that it overrides the
defalut.
Norm: I agree, the spec is confusing.
Proposal: Close 025 with no action, close 080 with an action to the editor
to clarify the spec so that any specified namespace clearly does not
override any explicit declarations in the escaped content.
Vojtech: Part of my question in 025 was about the case where you have no
root elements or more than one.
Norm: Right.
Proposal: Close 025 with an action to the editor to clarify the case where
unescaping produces no elements or more than one element, close 080 with
an action to the editor to clarify the spec so that any specified
namespace clearly does not override any explicit declarations in the
escaped content.
Accepted.
<scribe> ACTION: Norm to edit the spec to fix 025 and 080. [recorded in
[24]http://www.w3.org/2009/01/22-xproc-minutes.html#action02]
Any other business?
None heard.
Adjourned.
Summary of Action Items
[NEW] ACTION: Norm to edit the spec so that we say that any change to
xml:base or adding an xml:base does change the underlying infoset
property. [recorded in
[25]http://www.w3.org/2009/01/22-xproc-minutes.html#action01]
[NEW] ACTION: Norm to edit the spec to fix 025 and 080. [recorded in
[26]http://www.w3.org/2009/01/22-xproc-minutes.html#action02]
[End of minutes]
--------------------------------------------------------------------------
Minutes formatted by David Booth's [27]scribe.perl version 1.133 ([28]CVS
log)
$Date: 2009/01/22 18:11:32 $
References
Visible links
1. http://www.w3.org/
2. http://www.w3.org/XML/XProc/2009/01/22-agenda
3. http://www.w3.org/2009/01/22-xproc-irc
4. http://www.w3.org/XML/XProc/2009/01/22-minutes.html#agenda
5. http://www.w3.org/XML/XProc/2009/01/22-minutes.html#item01
6. http://www.w3.org/XML/XProc/2009/01/22-minutes.html#item02
7. http://www.w3.org/XML/XProc/2009/01/22-minutes.html#item03
8. http://www.w3.org/XML/XProc/2009/01/22-minutes.html#item04
9. http://www.w3.org/XML/XProc/2009/01/22-minutes.html#item05
10. http://www.w3.org/XML/XProc/2009/01/22-minutes.html#item06
11. http://www.w3.org/XML/XProc/2009/01/22-minutes.html#item07
12. http://www.w3.org/XML/XProc/2009/01/22-minutes.html#item08
13. http://www.w3.org/XML/XProc/2009/01/22-minutes.html#item09
14. http://www.w3.org/XML/XProc/2009/01/22-minutes.html#item10
15. http://www.w3.org/XML/XProc/2009/01/22-minutes.html#item11
16. http://www.w3.org/XML/XProc/2009/01/22-minutes.html#item12
17. http://www.w3.org/XML/XProc/2009/01/22-minutes.html#item13
18. http://www.w3.org/XML/XProc/2009/01/22-minutes.html#ActionSummary
19. http://www.w3.org/XML/XProc/2009/01/22-agenda
20. http://www.w3.org/XML/XProc/2009/01/08-minutes
21. http://www.w3.org/XML/XProc/2008/11/cr-comments/
22. http://lists.w3.org/Archives/Public/public-xml-processing-model-comments/2009Jan/0012.html
23. http://www.w3.org/2009/01/22-xproc-minutes.html#action01
24. http://www.w3.org/2009/01/22-xproc-minutes.html#action02
25. http://www.w3.org/2009/01/22-xproc-minutes.html#action01
26. http://www.w3.org/2009/01/22-xproc-minutes.html#action02
27. http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
28. http://dev.w3.org/cvsweb/2002/scribe/
Received on Thursday, 22 January 2009 18:13:38 UTC