Problems validating, and using records with namespace prefix

, ,
1

Hi!

I actually have two separate problems that are probably not related.

  1. How do I validate an incoming xml document, when it uses namespace prefixes? I have imported and XML Schema and a created a number of Records based on that same XML Schema. Later, when I convert the incoming XML doc to a record (using nsDecl in the service), all the records are prefixed. I assume this is correct, but the Record definition does not have the prefixes. The validation fails already on the root element. Even if I get this to work, how can I actually work with the record after that. As I understand it, each submitter is free to use whichever prefix they want, as long as it is declared in the header. How is this supposed to work?

  2. A second problem is when I validate the xml document by refering directly to the webM schema, and not the Record definition (passing the node object instead of the Record). This seems to work better than validating the record, but it stops on an element requiring a gDay value. No matter what I put in there, it fails the validation. Of course, even if I get THIS to work I still have the problem of working with the Record (I need to do some transformations, among other things).

Here is a simplified version of my XML Schema:

<?xml version="1.0" encoding="UTF-8"?>

<xs:schema targetNamespace=“http://domain_name/b2b/2002/schemas” xmlns:ep=“http://domain_name/b2b/2002/schemas” xmlns:xs=“XML Schema” elementFormDefault=“qualified” attributeFormDefault=“qualified”>
<xs:element name=“SomeRoot”>
xs:complexType
xs:sequence
<xs:element name=“aDay”>
xs:simpleType
<xs:restriction base=“xs:gDay”>
<xs:pattern value=“[0-9]{2}”/>
</xs:restriction>
</xs:simpleType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>

And here is a sample XML doc:<?xml version="1.0" encoding="UTF-8"?>
<bp:SomeRoot xmlns:bp=“http://domain_name/b2b/2002/schemas” xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance” xsi:schemaLocation=“http://domain_name E:\Standards\SAMA\test.xsd”>
bp:aDay11</bp:aDay>
</bp:SomeRoot>

The xml doc validates successfuly in other tools.

2

OK, never mind the gDay thing. I see now that gDay has to be in the format —DD, and the Schema designer added the [0-9]{2} pattern. Obviously, these two will never ever be true
at the same time :slight_smile:

Still don’t understand how to use a record from such an XML doc though.

3

Do you have IS 4.6 with SP1?

4

What we’ve found is that we want the namespace to be present when using record definitions. Any references to elements in our flows use a namespace in them. So if someone uses a different prefix (or a default namespace), but declaring them in the nsDecls parameter we will match any possible prefix as long as they point to the same namespace. The schema validation is more strict than using a record definition since you lose such things as order of elements.

On a side note, try to minimize the need for record definitions if possible. We use XQL to query nodes and create a subset of the elements we want. A lot of our original looping and branching over records can be replaced by conditional XQL queries.

5

Thanks for your tips.

I’ll take your advice on limiting record definition use under consideration. However, assuming I do need to create a record definitions, do you know of any way to incorporate the prefix when I import an XML Schema. My Schema is rather large, and going through the record, adding a prefix to the elements is not something I look forward to :slight_smile:

6

mmohler, I’m rinng 4.6 w/ SP1.

Can somebody tell me which is the correct way
to interpret that gDay field? It seems as it was not as simple as I though. If I declare a field to be a gDay (implies format ‘—DD’), AND I declare a pattern [0-9]{2}, does that mean the value can be either or? I don’t know whether these two are ORed or ANDed. I know that declaring it as a string and supplying two separate patterns will OR them:

[0-9]{2}
.{3,34}
= ([0-9]{2})|(.{3,34})

I’m trying to figure out whether IS is wrong or XML Spy is wrong (XML Spy is allowing a two digit field, but not webM IS).