Forums » #117 - DFDL v1.0 Revision »
fn:name returns QName - makes no sense as prefixes not in infoset
Added by Michael Beckerle about 9 years ago
A QName as the return value of the fn:name() function implies a prefix that is defined.
The DFDL Infoset has a namespace, but does not have the concept of namespace prefixes as part of the Infoset.
So we either say what the prefix is (probably based on the [schema] element which references a schema component which if named, may have a prefix). Or we can say that the function returns a local name, not a QName, or we can drop the function, replace with dfdl:name() which returns a local name, or we could add [prefix] to the infoset.
There are many fixes possible, but QNames are not currently meaningful as values in DFDL.
Note that since we simplified the direct dispatch choice mechanisms, I am not sure the fn:name function is even needed at all anymore. perhaps we should just eliminate it?
Replies (5)
RE: fn:name returns QName - makes no sense as prefixes not in infoset - Added by Steve Hanson about 9 years ago
I think we can probably drop fn:name. We already have fn:local-name for the local part of an element's name, and fn:namespace-uri for the namespace of an element's name. As you say, there is no prefix in the data.
Resolved - RE: fn:name returns QName - makes no sense as prefixes not in infoset - Added by Michael Beckerle almost 9 years ago
Remove fn:name from the expression language.
Resolved: fn:name returns QName - makes no sense as prefixes not in infoset - Added by Steve Hanson over 8 years ago
New erratum 4.14 in experience document 1.
DONE - RE: fn:name returns QName - makes no sense as prefixes not in infoset - Added by Michael Beckerle over 8 years ago
Change in draft-gwdrp-dfdl-v1.0.4-r06.docx
DONE - RE: fn:name returns QName - makes no sense as prefixes not in infoset - Added by Steve Hanson about 8 years ago
(1-5/5)