Re: namespace hiccup2

Paul

 simply trying to figure out what type of values you identify in the KRID
according to what logic and schema
and where (what domain) would that be applicable to and to solve what
problem-

I dont have an expectation as such -  but I figure anything that makes
sense would do
when I asked the question to Carl what exactly is KRID ( the KRID proposal
emanated from Carl, so I expect Carl to send replies if this proposal comes
from you, maybe you need to clarify that also)
he said he would see a top level distinction between declarative and
procedural

i then sent an email pondering a few points about that and you reply
Please start a document where you specify what is KRID and how you envision
it to work
then we can talk about it' at the moment, it is very difficult to have an
intelligent exchange about it :-)


pdm




On Sun, May 24, 2020 at 9:32 AM carl mattocks <carlmattocks@gmail.com>
wrote:

> Paola et Al
>
> Please outline your expectations for a taxonomy.
>
> Carl
>
> On Sat, May 23, 2020, 9:18 PM Paola Di Maio <paola.dimaio@gmail.com>
> wrote:
>
>> Paul-
>> Thanks for reply
>>
>> *  In the parsing of a StratML XSD I found that:  *
>>
>> This is what the question is about -
>>
>> What did you parse the text with?
>> Please share the parser and the output so that we can make better sense
>> of your observations?
>>
>> pdm
>>
>>
>>
>> On Sun, May 24, 2020 at 4:19 AM Paul Alagna <pjalagna@gmail.com> wrote:
>>
>>> namespace hiccup2
>>>
>>> <Paola> pls say how did you process the file- </
>>>
>>> I'm not sure what you meant by your question
>>> but it sounded to me like "how did you get to realize this?" So, I'll
>>> answer that one.
>>>
>>> Aside from the initial white space, the area of information for an XML /
>>> XSD document is the beginning brace character "<" up to but not including
>>> the next brace character "<"; inner split by a ">" token.
>>>
>>> IE <stuff1>stuff2|"<" this "area of information" is also known as a
>>> "fragment"
>>>
>>> The XSD standard has rules about what information items are contained in
>>> "stuff1" and "stuff2"
>>>
>>> In "stuff1" attributes are recorded in the format
>>> attributeName="attributeValue". If an attribute name is further split into:
>>> namespaceName ":" localName then further processing is called for.
>>>
>>> The XSD standard for namespaces says that a secondary XSD of that
>>> namespace exists and that a workflow (XSD fragment) for the localName will
>>> exist.
>>>
>>> This is accomplished through 3 part mechanism:
>>>
>>> 1-the namaspace XSD file is declared in the schema statement using the
>>> "xmlns:" prefix such as <schema xmlns:foo="http//foo---" (oddly without the
>>> .xsd ending )
>>>
>>> 2- the namespace required is named in the attribute name AND/OR value.
>>> like: <element xsd:ref="foo:Fullname"
>>> and
>>>
>>> 3- that an XSD record exists in the namespace XSD:
>>> IE <element name=localName-----..</element> existing in foo.xsd
>>>
>>> In the parsing of a StratML XSD I found that:
>>>
>>> The StratML.xsd calls for a stratml:Name and but the schema pointer
>>> "xmlns:stratml=" does NOT point to a valid URI.
>>>
>>> This is from the StratML.xsd itself
>>> xmlns:stratml="urn:ISO:std:iso:17469:tech:xsd:stratml_core"
>>>
>>> After a little digging I made the assumption that the usage intended was
>>> to use the StratML.xsd as the secondary namespace XSD, in addition to being
>>> the guiding XSD for stratML XML reports.  Because the
>>> <element name="Name" XSD fragment does exist in this very document, I
>>> can continue on. "I" can continue because I'm a human.
>>>
>>> Any automatic processes like the AIKR information extraction tools we
>>> are defining and building MUST follow the rules laid out by our standards
>>> and the standards we dictate.
>>>
>>> Paul
>>> Thoughts? , comments?
>>>
>>> Thanks
>>> PAUL ALAGNA
>>> PJAlagna@Gmail.com <PJAlagna@gmail.com>
>>> 732-322-5641
>>>
>>>
>>>
>>>