Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Using Cursor adaptor to parse XSD schema.
Message
General information
Forum:
Visual FoxPro
Category:
XML, XSD
Miscellaneous
Thread ID:
00952399
Message ID:
00954093
Views:
24
Hi Terry,

--
Well it took you long enough:)
---

Yeah, FWIW, don't count on my being here very often and I don't get around to looking at anything other than VFP 9 reporting a lot of the time!

--
BTW, WHile I have you on the line, what is the purpose of a namespace designation like this:
xsi:schemaLocation="http://www.ABCD.org/xsd/ABCD ABCD.xsd"
ABCD.xsd is local to my java server, but the URL references a remote server.
---

This is kind of a weird feeling. The thing I want most to say in the world is "it provides the namespace!!" which I gather doesn't help very much <g>.

OK. You mentioned that you did some java programming. If so, you must understand that packages are scoped using something that looks very much like a domain, but not exactly in the same order. For example, you write statements like:
import org.w3c.dom.*;
import java.net.URL;
import oracle.xml.parser.v2.* ;
Each set of qualifiers scopes a java class so that different development groups or efforts can avoid name collision. A class oracle.xml.parser.v2.URL (if there was such a class) is distinct from java.net.URL.

The naming convention used for packages is a very good one, because people register domain names such as java.net world-wide. So whoever owns java.net can also be assured that nobody else in the world can start their package definitions with java.net. Within java.net, whoever owns java.net can further organize sets of packages of classes however they want, with impunity. They have the right to organize their own class libraries, just as you do in FoxPro when you put things into different folders for shared and application-specific use.

So... a class exists/is defined in a "namespace". The name may exist in other packages, but when we instance the class we know which one we're trying to instance, because somewhere in our code we've fully-qualified its package name.

OK so far?

[FWIW FoxPro tries to do something similar in an .APP file, I think using relative paths to the folders in the project, whether one thinks about it all the time or not <s>. (This is a sort of backhand explanation for the behavior of FULLPATH() and FILE() within an APP or EXE, which I happened to bring up in another thread yesterday <s>).]

OK, now, how this relates to XML.

The URL that you use for the schemaLocation does not make a validating parser go out and fetching the XSD for the purpose of checking your document, any more than the package definition makes your java IDE go out to w3c.org to fetch the source when it's ready to compile your code.

It scopes the tags to a particular namespace.

Just as a class name may exist in different packages, a particular node name may exist in different schemas, all referenced in a single document, and have different meanings and restrictions in those different schemas.

In FoxPro terms, you've basically done this:
USE MyEmployees ALIAS Emp IN 0
USE MyTerritories ALIAS Terr IN 0

? Emp.Description
? Terr.Description
... same field name, different meanings in two different tables. (Or the same table in two different DBCs, if we qualify them further).

It's the same with XML. Just as I've just shown in the FoxPro code above, when you qualify the local-name of a node using an alias within your document, you show which namespace each use of the tag name belongs to.

For example, within the schema itself, you might see this:
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"  [..]
The "xmlns:xs" part says that the all elements with the xs: prefix -- which functions as an alias or shorthand for the URL -- belong to the http://www.w3.org/2001/XMLSchema namespace. (You don't have to repeat this attribute for the child elements, it's inherited. But this works a little differently for attributes, don't get confused about that.)

In a different schema, the alias might have been xsd; just as in FoxPro, this is irrelevant, if the URI was the same, the namespace was the same.

Within the same schema you might see something like this:
      <xsd:element name="Items" type="xxx:Items"/>
Here, you can see that the element element <g> is defined within the http://www.w3.org/2001/XMLSchema namespace. But the type is defined in a different namespace, as shown by the xxx alias. It is a potentially-complex definition of restrictions and content that might be specific to a business.

Namespaces in XML work a little differently from FoxPro aliases, in that there is technically no "selected alias", or schema with current focus, as we have it in FoxPro. You can do something similar like this:
<schema targetNamespace="http://www.example.com/MyCompany" 
xmlns:xxx="http://www.example.com/MyCompany" 
xmlns="http://www.w3.org/2001/XMLSchema" 
elementFormDefault="unqualified" attributeFormDefault="unqualified">
[..]
... it's not exactly the same thing, but close.

Before I finish, I should say that this explanation is intimately tied to the xsi: prefix on the schemaLocation attribute. I'm explaining what that attribute does *according to its definition in a particular schema*. IOW, the designation that you show above was paired with another piece of information:
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
... so, as I hope you'll understand from this message, the xsi prefix on schemaLocation defines the namespace for schemaLocation as being http://www.w3.org/2001/XMLSchema-instance. The attribute schemaLocation *might* do something entirely different, within a different namespace <s>.


HTH,

>L<
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform